[PATCH v2 12/16] drm/sun4i: Add support for H3 HDMI PHY variant

2018-02-28 Thread Jernej Skrabec
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3
HDMI PHY is completely custom PHY.

However, they still have many things in common like clock and reset
setup, setting sync polarity and more.

Add support for H3 HDMI PHY variant.

While documentation exists for this PHY variant, it doesn't go in great
details. Because of that, almost all settings are copied from BSP linux
4.4. Interestingly, those settings are slightly different to those found
in a older BSP with Linux 3.4. For now, no user visible difference was
found between them.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |   6 +
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 264 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 132 +++
 4 files changed, 400 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1610e748119b..330843ce4280 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -12,6 +12,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_tmds_clk.o
 
 sun8i-drm-hdmi-y   += sun8i_dw_hdmi.o
 sun8i-drm-hdmi-y   += sun8i_hdmi_phy.o
+sun8i-drm-hdmi-y   += sun8i_hdmi_phy_clk.o
 
 sun8i-mixer-y  += sun8i_mixer.o sun8i_ui_layer.o \
   sun8i_vi_layer.o sun8i_ui_scaler.o \
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 49161326ea5a..79154f0f674a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -146,6 +146,7 @@
 struct sun8i_hdmi_phy;
 
 struct sun8i_hdmi_phy_variant {
+   bool has_phy_clk;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -157,6 +158,9 @@ struct sun8i_hdmi_phy_variant {
 struct sun8i_hdmi_phy {
struct clk  *clk_bus;
struct clk  *clk_mod;
+   struct clk  *clk_phy;
+   struct clk  *clk_pll0;
+   unsigned intrcal;
struct regmap   *regs;
struct reset_control*rst_phy;
struct sun8i_hdmi_phy_variant   *variant;
@@ -184,4 +188,6 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
 void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
 const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
 
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+
 #endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c 
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 16889bc0c62d..5a52fc489a9d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2018 Jernej Skrabec 
  */
 
+#include 
 #include 
 
 #include "sun8i_dw_hdmi.h"
@@ -73,7 +74,148 @@ static int sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
 
return 0;
-};
+}
+
+static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
+   struct sun8i_hdmi_phy *phy,
+   unsigned int clk_rate)
+{
+   u32 pll_cfg1_init;
+   u32 pll_cfg2_init;
+   u32 ana_cfg1_end;
+   u32 ana_cfg2_init;
+   u32 ana_cfg3_init;
+   u32 b_offset = 0;
+   u32 val;
+
+   /* bandwidth / frequency independent settings */
+
+   pll_cfg1_init = SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN |
+   SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN |
+   SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(7) |
+   SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(1) |
+   SUN8I_HDMI_PHY_PLL_CFG1_PLLDBEN |
+   SUN8I_HDMI_PHY_PLL_CFG1_CS |
+   SUN8I_HDMI_PHY_PLL_CFG1_CP_S(2) |
+   SUN8I_HDMI_PHY_PLL_CFG1_CNT_INT(63) |
+   SUN8I_HDMI_PHY_PLL_CFG1_BWS;
+
+   pll_cfg2_init = SUN8I_HDMI_PHY_PLL_CFG2_SV_H |
+   SUN8I_HDMI_PHY_PLL_CFG2_VCOGAIN_EN |
+   SUN8I_HDMI_PHY_PLL_CFG2_SDIV2;
+
+   ana_cfg1_end = SUN8I_HDMI_PHY_ANA_CFG1_REG_SVBH(1) |
+  SUN8I_HDMI_PHY_ANA_CFG1_AMP_OPT |
+  SUN8I_HDMI_PHY_ANA_CFG1_EMP_OPT |
+  SUN8I_HDMI_PHY_ANA_CFG1_AMPCK_OPT |
+  SUN8I_HDMI_PHY_ANA_CFG1_EMPCK_OPT |
+  SUN8I_HDMI_PHY_ANA_CFG1_ENRCAL |
+  SUN8I_HDMI_PHY_ANA_CFG1_ENCALOG |
+  SUN8I_HDMI_PHY_ANA_CFG1_REG_SCKTMDS |
+  SUN8I_HDMI_PHY_ANA_CFG1_TMDSCLK_EN |
+  SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK |
+

[PATCH v2 00/16] Implement H3/H5 HDMI driver

2018-02-28 Thread Jernej Skrabec
This series implements H3/H5 HDMI driver. It was tested on OrangePi 2 (H3),
OrangePi Plus2e (H3) and OrangePi PC2 (H5) with many resolutions and it
works well. Bug, which prevented correct operation for some resolutions,
is also fixed.

Code is based on linux-next, next-20180226 tag.

Best regards,
Jernej

Changes from v1:
- Fixed build warning on arm64
- Fixed condition in determine_rate function in HDMI PHY clock driver
- Added defines for polarity settings in HDMI PHY
- Added patch to skip LVDS code path altogether if TCON doesn't support it.
- round_rate for NM PLLs now rounds to minimal rate if requested rate is
  lower.
- set_rate for NM PLLs doesn't fail if requested rate is lower than minimal
  (round_rate is called before which already guarantees that rate is not
   lower than minimal).

Jernej Skrabec (16):
  clk: sunxi-ng: Add check for minimal rate to NM PLLs
  clk: sunxi-ng: h3: h5: Add minimal rate for video PLL
  clk: sunxi-ng: h3: h5: Allow some clocks to set parent rate
  clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO
  dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
  drm/sun4i: Don't process LVDS if TCON doesn't support it
  drm/sun4i: Add support for H3 display engine
  drm/sun4i: Add support for H3 mixer 0
  drm/sun4i: Fix polarity configuration for DW HDMI PHY
  drm/sun4i: Add support for variants to DW HDMI PHY
  drm/sun4i: Move and expand DW HDMI PHY register macros
  drm/sun4i: Add support for H3 HDMI PHY variant
  drm/sun4i: Allow building on arm64
  ARM: dts: sunxi: h3/h5: Add HDMI pipeline
  ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
  ARM64: dts: sun50i: h5: Enable HDMI output on H5 boards

 .../bindings/display/sunxi/sun4i-drm.txt   |   6 +
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  25 ++
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts  |  25 ++
 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts |  25 ++
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts   |  25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   |  25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts|  24 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts |  25 ++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 108 ++
 .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  |  25 ++
 .../dts/allwinner/sun50i-h5-orangepi-prime.dts |  25 ++
 .../allwinner/sun50i-h5-orangepi-zero-plus2.dts|  25 ++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c|  32 +-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h|   4 +-
 drivers/clk/sunxi-ng/ccu_nm.c  |  11 +-
 drivers/clk/sunxi-ng/ccu_nm.h  |  27 ++
 drivers/gpu/drm/sun4i/Kconfig  |   2 +-
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_drv.c  |   1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 120 +++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  | 157 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 369 ++---
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 132 
 drivers/gpu/drm/sun4i/sun8i_mixer.c|  12 +
 include/dt-bindings/clock/sun8i-h3-ccu.h   |   2 +
 26 files changed, 1129 insertions(+), 129 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c

-- 
2.16.2

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


Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

2018-02-28 Thread Claudiu Beznea


On 27.02.2018 12:54, Daniel Thompson wrote:
> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
>> On 26.02.2018 11:57, Jani Nikula wrote:
>>> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
 On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> were adapted to this change.
>
> Signed-off-by: Claudiu Beznea 
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>  drivers/bus/ts-nbus.c|  2 +-
>  drivers/clk/clk-pwm.c|  3 ++-
>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>  drivers/hwmon/pwm-fan.c  |  2 +-
>  drivers/input/misc/max77693-haptic.c |  2 +-
>  drivers/input/misc/max8997_haptic.c  |  6 +-
>  drivers/leds/leds-pwm.c  |  5 -
>  drivers/media/rc/ir-rx51.c   |  5 -
>  drivers/media/rc/pwm-ir-tx.c |  5 -
>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>  drivers/video/backlight/lp8788_bl.c  |  5 -
>  drivers/video/backlight/pwm_bl.c | 11 +--
>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>  include/linux/pwm.h  |  6 --
>  16 files changed, 70 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> b/drivers/video/backlight/lm3630a_bl.c
> index 2030a6b77a09..696fa25dafd2 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
> *pchip, int br, int br_max)
>  {
>   unsigned int period = pchip->pdata->pwm_period;
>   unsigned int duty = br * period / br_max;
> + struct pwm_caps caps = { };
>  
> - pwm_config(pchip->pwmd, duty, period);
> + pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, &caps);
> + pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));

 Well... I admit I've only really looked at the patches that impact 
 backlight but dispersing this really odd looking bit twiddling 
 throughout the kernel doesn't strike me a great API design.

 IMHO callers should not be required to find the first set bit in
 some specially crafted set of capability bits simply to get sane 
 default behaviour.
>>>
>>> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
>>> error prone.
>>
>> Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be OK
>> from your side?
>>
>> Or, what about using a function like pwm_mode_first() to get the first 
>> supported
>> mode by PWM channel?
>>
>> Or, would you prefer to solve this inside pwm_config() function, let's say, 
>> in
>> case an invalid mode is passed as argument, to let pwm_config() to choose the
>> first available PWM mode for PWM channel passed as argument?
> 
> What is it that actually needs solving?
> 
> If a driver requests normal mode and the PWM driver cannot support it
> why not just return an error an move on.
Because, simply, I wasn't aware of what these PWM client drivers needs for.

> 
> Put another way, what is the use case for secretly adopting a mode the
> caller didn't want? Under what circumstances is this a good thing?
No one... But I wasn't aware of what the PWM clients needs for from their PWM
controllers. At this moment having BIT(ffs(caps.modes)) instead of
PWM_MODE(NORMAL) is mostly the same since all the driver that has not explicitly
registered PWM caps will use PWM normal mode.

I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK from
your side.

Thank you,
Claudiu Beznea
> 
> 
> Daniel.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

2018-02-28 Thread Chanwoo Choi
Hi,

On 2018년 02월 27일 21:05, Andrzej Hajda wrote:
> On 27.02.2018 12:08, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
>>> From: Maciej Purski 
>>>
>>> Currently MHL chip must be turned on permanently to detect MHL cable. It
>>> duplicates micro-USB controller's (MUIC) functionality and consumes
>>> unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
>>> only if it detects MHL cable.
>>>
>>> Signed-off-by: Maciej Purski 
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> v5: updated extcon API
>>>
>>> This is rework of the patch by Maciej with following changes:
>>> - use micro-USB port bindings to get extcon, instead of extcon property,
>>> - fixed remove sequence,
>>> - fixed extcon get state logic.
>>>
>>> Code finding extcon node is hacky IMO, I guess ultimately it should be done
>>> via some framework (maybe even extcon), or at least via helper, I hope it
>>> can stay as is until the proper solution will be merged.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/bridge/sil-sii8620.c | 97 
>>> ++--
>>>  1 file changed, 94 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> index 9e785b8e0ea2..62b0adabcac2 100644
>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> @@ -17,6 +17,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -25,6 +26,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -81,6 +83,10 @@ struct sii8620 {
>>> struct edid *edid;
>>> unsigned int gen2_write_burst:1;
>>> enum sii8620_mt_state mt_state;
>>> +   struct extcon_dev *extcon;
>>> +   struct notifier_block extcon_nb;
>>> +   struct work_struct extcon_wq;
>>> +   int cable_state;
>>> struct list_head mt_queue;
>>> struct {
>>> int r_size;
>>> @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct 
>>> sii8620 *ctx)
>>> ctx->rc_dev = rc_dev;
>>>  }
>>>  
>>> +static void sii8620_cable_out(struct sii8620 *ctx)
>>> +{
>>> +   disable_irq(to_i2c_client(ctx->dev)->irq);
>>> +   sii8620_hw_off(ctx);
>>> +}
>>> +
>>> +static void sii8620_extcon_work(struct work_struct *work)
>>> +{
>>> +   struct sii8620 *ctx =
>>> +   container_of(work, struct sii8620, extcon_wq);
>>> +   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
>>> +
>>> +   if (state == ctx->cable_state)
>>> +   return;
>>> +
>>> +   ctx->cable_state = state;
>>> +
>>> +   if (state > 0)
>>> +   sii8620_cable_in(ctx);
>>> +   else
>>> +   sii8620_cable_out(ctx);
>>> +}
>>> +
>>> +static int sii8620_extcon_notifier(struct notifier_block *self,
>>> +   unsigned long event, void *ptr)
>>> +{
>>> +   struct sii8620 *ctx =
>>> +   container_of(self, struct sii8620, extcon_nb);
>>> +
>>> +   schedule_work(&ctx->extcon_wq);
>>> +
>>> +   return NOTIFY_DONE;
>>> +}
>>> +
>>> +static int sii8620_extcon_init(struct sii8620 *ctx)
>>> +{
>>> +   struct extcon_dev *edev;
>>> +   struct device_node *musb, *muic;
>>> +   int ret;
>>> +
>>> +   /* get micro-USB connector node */
>>> +   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
>>> +   /* next get micro-USB Interface Controller node */
>>> +   muic = of_get_next_parent(musb);
>>> +
>>> +   if (!muic) {
>>> +   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
>>> mode\n");
>>> +   return 0;
>>> +   }
>>> +
>>> +   edev = extcon_find_edev_by_node(muic);
>>> +   of_node_put(muic);
>>> +   if (IS_ERR(edev)) {
>>> +   if (PTR_ERR(edev) == -EPROBE_DEFER)
>>> +   return -EPROBE_DEFER;
>>> +   dev_err(ctx->dev, "Invalid or missing extcon\n");
>>> +   return PTR_ERR(edev);
>>> +   }
>>> +
>>> +   ctx->extcon = edev;
>>> +   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
>>> +   INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
>>> +   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
>> You better to use devm_extcon_register_notifier().
> 
> With devm version I risk that in case of device unbind notification will
> be called after .remove callback, it seems to me quite dangerous. Or am
> I missing something?

If you use the cancel_work_sync() in remove() instead of flush_work(),
you can use the 'devm_extcon_*'.

> 
> Regards
> Andrzej
> 
>>
>>> +   if (ret) {
>>> +   dev_err(ctx->dev, "failed to register notifier for MHL\n");
>>> +   return ret;
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
>>>  {
>>> return container_of(bridge, struct sii8620, bridge);
>>> @@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
>>> if (ret)
>>> return ret;
>>>  
>>> +   r

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

2018-02-28 Thread Shuah Khan
On 02/26/2018 06:48 PM, Laura Abbott wrote:
> On 02/26/2018 09:07 AM, Shuah Khan wrote:
>> On 02/19/2018 11:33 AM, Daniel Vetter wrote:
>>> On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
 On 02/19/2018 07:31 AM, Daniel Vetter wrote:
> On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
>> Ion is designed to be a framework used by other clients who perform
>> operations on the buffer. Use the DRM vgem client as a simple consumer.
>> In conjunction with the dma-buf sync ioctls, this tests the full 
>> attach/map
>> path for the system heap.
>>
>> Signed-off-by: Laura Abbott 
>> ---
>>    tools/testing/selftests/android/ion/Makefile  |   3 +-
>>    tools/testing/selftests/android/ion/config    |   1 +
>>    tools/testing/selftests/android/ion/ionmap_test.c | 136 
>> ++
>>    3 files changed, 139 insertions(+), 1 deletion(-)
>>    create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c
>>
>> diff --git a/tools/testing/selftests/android/ion/Makefile 
>> b/tools/testing/selftests/android/ion/Makefile
>> index 96e0c448b39d..d23b6d537d8b 100644
>> --- a/tools/testing/selftests/android/ion/Makefile
>> +++ b/tools/testing/selftests/android/ion/Makefile
>> @@ -2,7 +2,7 @@
>>    INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
>>    CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
>> -TEST_GEN_FILES := ionapp_export ionapp_import
>> +TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
>>    all: $(TEST_GEN_FILES)
>> @@ -14,3 +14,4 @@ include ../../lib.mk
>>    $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
>>    $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
>> +$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
>> diff --git a/tools/testing/selftests/android/ion/config 
>> b/tools/testing/selftests/android/ion/config
>> index 19db6ca9aa2b..b4ad748a9dd9 100644
>> --- a/tools/testing/selftests/android/ion/config
>> +++ b/tools/testing/selftests/android/ion/config
>> @@ -2,3 +2,4 @@ CONFIG_ANDROID=y
>>    CONFIG_STAGING=y
>>    CONFIG_ION=y
>>    CONFIG_ION_SYSTEM_HEAP=y
>> +CONFIG_DRM_VGEM=y
>> diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
>> b/tools/testing/selftests/android/ion/ionmap_test.c
>> new file mode 100644
>> index ..dab36b06b37d
>> --- /dev/null
>> +++ b/tools/testing/selftests/android/ion/ionmap_test.c
>> @@ -0,0 +1,136 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +
>> +#include "ion.h"
>> +#include "ionutils.h"
>> +
>> +int check_vgem(int fd)
>> +{
>> +    drm_version_t version = { 0 };
>> +    char name[5];
>> +    int ret;
>> +
>> +    version.name_len = 4;
>> +    version.name = name;
>> +
>> +    ret = ioctl(fd, DRM_IOCTL_VERSION, &version);
>> +    if (ret)
>> +    return 1;
>> +
>> +    return strcmp(name, "vgem");
>> +}
>> +
>> +int open_vgem(void)
>> +{
>> +    int i, fd;
>> +    const char *drmstr = "/dev/dri/card";
>> +
>> +    fd = -1;
>> +    for (i = 0; i < 16; i++) {
>> +    char name[80];
>> +
>> +    sprintf(name, "%s%u", drmstr, i);
>> +
>> +    fd = open(name, O_RDWR);
>> +    if (fd < 0)
>> +    continue;
>> +
>> +    if (check_vgem(fd)) {
>> +    close(fd);
>> +    continue;
>> +    } else {
>> +    break;
>> +    }
>> +
>> +    }
>> +    return fd;
>> +}
>> +
>> +int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
>> +{
>> +    struct drm_prime_handle import_handle = { 0 };
>> +    int ret;
>> +
>> +    import_handle.fd = dma_buf_fd;
>> +    import_handle.flags = 0;
>> +    import_handle.handle = 0;
>> +
>> +    ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, &import_handle);
>> +    if (ret == 0)
>> +    *handle = import_handle.handle;
>> +    return ret;
>> +}
>> +
>> +void close_handle(int vgem_fd, uint32_t handle)
>> +{
>> +    struct drm_gem_close close = { 0 };
>> +
>> +    close.handle = handle;
>> +    ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, &close);
>> +}
>> +
>> +int main()
>> +{
>> +    int ret, vgem_fd;
>> +    struct ion_buffer_info info;
>> +    uint32_t handle = 0;
>> +    struct dma_buf_sync sync = { 0 };
>> +
>> +    info.heap_type = ION_HEAP_TYPE_SYSTEM;
>> +    info.heap_size = 4096;
>> +    info.flag_type = ION_FLAG_CACHED;
>> +
>> +    ret = ion_ex

[PATCH v2 03/16] clk: sunxi-ng: h3: h5: Allow some clocks to set parent rate

2018-02-28 Thread Jernej Skrabec
Some units have to be able to set it's own clock precisely to work
correctly. Allow them to do so by adding CLK_SET_RATE_PARENT flag.

Add this flag to DE, TCON and HDMI clocks.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index b9f39078c0b2..77ed0b0ba681 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -452,11 +452,13 @@ static SUNXI_CCU_GATE(dram_ts_clk,"dram-ts",  
"dram",
 
 static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
-0x104, 0, 4, 24, 3, BIT(31), 0);
+0x104, 0, 4, 24, 3, BIT(31),
+CLK_SET_RATE_PARENT);
 
 static const char * const tcon_parents[] = { "pll-video" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
-0x118, 0, 4, 24, 3, BIT(31), 0);
+0x118, 0, 4, 24, 3, BIT(31),
+CLK_SET_RATE_PARENT);
 
 static const char * const tve_parents[] = { "pll-de", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tve_clk, "tve", tve_parents,
@@ -487,7 +489,8 @@ static SUNXI_CCU_GATE(avs_clk,  "avs",  
"osc24M",
 
 static const char * const hdmi_parents[] = { "pll-video" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
-0x150, 0, 4, 24, 2, BIT(31), 0);
+0x150, 0, 4, 24, 2, BIT(31),
+CLK_SET_RATE_PARENT);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
  0x154, BIT(31), 0);
-- 
2.16.2

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


[PATCH v2 14/16] ARM: dts: sunxi: h3/h5: Add HDMI pipeline

2018-02-28 Thread Jernej Skrabec
This commit adds all entries needed for HDMI to function properly.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 108 +
 1 file changed, 108 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 7741166d34d8..1be1a02d6df2 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -105,6 +105,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   allwinner,pipelines = <&mixer0>;
+   status = "disabled";
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -123,6 +129,29 @@
#reset-cells = <1>;
};
 
+   mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-h3-de2-mixer-0";
+   reg = <0x0110 0x10>;
+   clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+   clock-names = "bus",
+ "mod";
+   resets = <&display_clocks RST_MIXER0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint {
+   remote-endpoint = 
<&tcon0_in_mixer0>;
+   };
+   };
+   };
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-h3-system-controller",
"syscon";
@@ -138,6 +167,41 @@
#dma-cells = <1>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-h3-tcon-tv",
+"allwinner,sun8i-a83t-tcon-tv";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+   clock-names = "ahb", "tcon-ch1";
+   resets = <&ccu RST_BUS_TCON0>;
+   reset-names = "lcd";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint {
+   remote-endpoint = 
<&mixer0_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   tcon0_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<&hdmi_in_tcon0>;
+   };
+   };
+   };
+   };
+
mmc0: mmc@1c0f000 {
/* compatible and clocks are in per SoC .dtsi file */
reg = <0x01c0f000 0x1000>;
@@ -682,6 +746,50 @@
interrupts = ;
};
 
+   hdmi: hdmi@1ee {
+   compatible = "allwinner,sun8i-h3-dw-hdmi",
+"allwinner,sun8i-a83t-dw-hdmi";
+   reg = <0x01ee 0x1>;
+   reg-io-width = <1>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
+<&ccu CLK_HDMI>;
+   clock-names = "iahb", "isfr", "tmds";
+   resets = <&ccu RST_BUS_HDMI1>;
+   reset-names = "ctrl";
+   phys = <&hdmi_phy>;
+   phy-names = "hdmi-phy";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint {
+   remote-endpoint = 
<&tcon0_out_hdmi>;

[PATCH v2 07/16] drm/sun4i: Add support for H3 display engine

2018-02-28 Thread Jernej Skrabec
H3 display engine has two mixers which are connected to HDMI and TV
output.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 3957c2ff6870..a0f43b81c64c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -359,6 +359,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun7i-a20-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ .compatible = "allwinner,sun8i-a83t-display-engine" },
+   { .compatible = "allwinner,sun8i-h3-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
 };
-- 
2.16.2

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


[PATCH v2 09/16] drm/sun4i: Fix polarity configuration for DW HDMI PHY

2018-02-28 Thread Jernej Skrabec
Current polarity configuration code is cleary wrong since it compares
same flag two times. However, even if flag name is fixed, it won't work
well for resolutions which have one polarity positive and another
negative.

Fix that by properly set each bit according to each polarity. Since
those two bits are not described in any documentation, relationships
were obtained by experimentation.

Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c 
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e5bfcdd43ec9..9d2f11ca3538 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -10,7 +10,8 @@
 #define SUN8I_HDMI_PHY_DBG_CTRL_REG0x
 #define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCKBIT(0)
 #define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK   GENMASK(15, 8)
-#define SUN8I_HDMI_PHY_DBG_CTRL_POL(val)   (val << 8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC BIT(8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC BIT(9)
 #define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK  GENMASK(23, 16)
 #define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16)
 
@@ -35,14 +36,14 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void 
*data,
struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
u32 val = 0;
 
-   if ((mode->flags & DRM_MODE_FLAG_NHSYNC) &&
-   (mode->flags & DRM_MODE_FLAG_NHSYNC)) {
-   val = 0x03;
-   }
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
+
+   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
 
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
-  SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK,
-  SUN8I_HDMI_PHY_DBG_CTRL_POL(val));
+  SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
 
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
   SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
-- 
2.16.2

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


[PATCH v2 16/16] ARM64: dts: sun50i: h5: Enable HDMI output on H5 boards

2018-02-28 Thread Jernej Skrabec
Enable HDMI output on all boards with HDMI connector.

Signed-off-by: Jernej Skrabec 
---
 .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  | 25 ++
 .../dts/allwinner/sun50i-h5-orangepi-prime.dts | 25 ++
 .../allwinner/sun50i-h5-orangepi-zero-plus2.dts| 25 ++
 3 files changed, 75 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
index 58505fbc2667..98862c7c7258 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -67,6 +67,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -121,6 +132,10 @@
status = "okay";
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -153,6 +168,16 @@
};
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
index 803566608ed8..b75ca4d7d001 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
@@ -62,6 +62,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -128,6 +139,10 @@
status = "okay";
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -160,6 +175,16 @@
};
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index eda24d813282..53c8c11620e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
reg_vcc3v3: vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -73,6 +84,20 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &mmc0 {
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
-- 
2.16.2

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


[PATCH v2 15/16] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-28 Thread Jernej Skrabec
Enable HDMI output on all boards which have HDMI connector.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 ++
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts  | 25 ++
 arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 ++
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts   | 25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  | 25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 24 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 ++
 8 files changed, 199 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index 9c1bc472fb1c..30540dc8e0c5 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -100,6 +111,10 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -129,6 +144,16 @@
};
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts 
b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
index 870aabcbb2d8..cf1f970b0c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -100,6 +111,10 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -108,6 +123,16 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
index d0d41eb86cb4..b20a710da7bc 100644
--- a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -23,6 +23,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -120,6 +131,10 @@
status = "okay";
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -143,6 +158,16 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index c77fbca4f227..9412668bb888 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -49,6 +49,21 @@
aliases {
ethernet0 = &emac;
};
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+};
+
+&de {
+   status = "okay";
 };
 
 &ehci1 {
@@ -66,6 +81,16 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-28 Thread Julian Calaby
Hi Maxime,

On Tue, Feb 27, 2018 at 6:07 PM, Maxime Ripard
 wrote:
> On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
>> Hi Jernej,
>>
>> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec  
>> wrote:
>> > Hi,
>> >
>> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng 
>> > napisal(a):
>> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
>> >  写到:
>> >> >Hi Julian,
>> >> >
>> >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
>> >> >
>> >> >napisal(a):
>> >> >> Hi Jernej,
>> >> >>
>> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>> >> >
>> >> >
>> >> >
>> >> >wrote:
>> >> >> > Enable HDMI output on all boards which have HDMI connector.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec 
>> >> >> > ---
>> >> >> >
>> >> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
>> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>> >> >> >
>> >> >> >   | 25 ++
>> >> >> >
>> >> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
>> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> >> >> >
>> >> >> >   | 25 ++
>> >> >
>> >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
>> >> >
>> >> >> > | 25 ++
>> >> >> >
>> >> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
>> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> >> >> >
>> >> >> >   | 24 +
>> >> >
>> >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>> >> >
>> >> >> >| 25 ++ 8 files changed, 199
>> >> >
>> >> >insertions(+)
>> >> >
>> >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
>> >> >> terms of HDMI support, the difference is that the H2+ can't output
>> >> >
>> >> >4k.
>> >> >
>> >> >> If this code is compatible with the H2+, could you please add the
>> >> >> necessary bits and pieces to the h2-plus DTSs too?
>> >> >
>> >> >There are only 3 H2+ boards in kernel and none of them has HDMI
>> >> >connector, so
>> >>
>> >> BPi M2 Zero has miniHDMI connector.
>> >
>> > Ah, sorry, I missed that one. Since I don't have it (or any other board 
>> > with
>> > H2+) I'm not really comfortable including such patch. If anyone will test 
>> > it,
>> > I can include it in next revision.
>>
>> I have one of those (this is why I'm interested in this patchset) so
>> I'm willing to test, however I can't guarantee I'll get to it quickly.
>
> Then I guess the best way forward will be to keep the current patch as
> is, and you'll send a patch whenever you have the time to test it.

Fair enough, I'll do that then. =)

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 08/16] drm/sun4i: Add support for H3 mixer 0

2018-02-28 Thread Jernej Skrabec
This mixer supports 1 VI plane, 3 UI plane and HW scaling on all planes.

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

diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 9b0256d31a61..126899d6f0d3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -492,6 +492,14 @@ static const struct sun8i_mixer_cfg sun8i_a83t_mixer1_cfg 
= {
.vi_num = 1,
 };
 
+static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
+   .ccsc   = 0,
+   .mod_rate   = 43200,
+   .scaler_mask= 0xf,
+   .ui_num = 3,
+   .vi_num = 1,
+};
+
 static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -509,6 +517,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-a83t-de2-mixer-1",
.data = &sun8i_a83t_mixer1_cfg,
},
+   {
+   .compatible = "allwinner,sun8i-h3-de2-mixer-0",
+   .data = &sun8i_h3_mixer0_cfg,
+   },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
-- 
2.16.2

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


Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

2018-02-28 Thread Chanwoo Choi
Hi,

On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
> From: Maciej Purski 
> 
> Currently MHL chip must be turned on permanently to detect MHL cable. It
> duplicates micro-USB controller's (MUIC) functionality and consumes
> unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
> only if it detects MHL cable.
> 
> Signed-off-by: Maciej Purski 
> Signed-off-by: Andrzej Hajda 
> ---
> v5: updated extcon API
> 
> This is rework of the patch by Maciej with following changes:
> - use micro-USB port bindings to get extcon, instead of extcon property,
> - fixed remove sequence,
> - fixed extcon get state logic.
> 
> Code finding extcon node is hacky IMO, I guess ultimately it should be done
> via some framework (maybe even extcon), or at least via helper, I hope it
> can stay as is until the proper solution will be merged.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/sil-sii8620.c | 97 
> ++--
>  1 file changed, 94 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 9e785b8e0ea2..62b0adabcac2 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -17,6 +17,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -25,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -81,6 +83,10 @@ struct sii8620 {
>   struct edid *edid;
>   unsigned int gen2_write_burst:1;
>   enum sii8620_mt_state mt_state;
> + struct extcon_dev *extcon;
> + struct notifier_block extcon_nb;
> + struct work_struct extcon_wq;
> + int cable_state;
>   struct list_head mt_queue;
>   struct {
>   int r_size;
> @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
> *ctx)
>   ctx->rc_dev = rc_dev;
>  }
>  
> +static void sii8620_cable_out(struct sii8620 *ctx)
> +{
> + disable_irq(to_i2c_client(ctx->dev)->irq);
> + sii8620_hw_off(ctx);
> +}
> +
> +static void sii8620_extcon_work(struct work_struct *work)
> +{
> + struct sii8620 *ctx =
> + container_of(work, struct sii8620, extcon_wq);
> + int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
> +
> + if (state == ctx->cable_state)
> + return;
> +
> + ctx->cable_state = state;
> +
> + if (state > 0)
> + sii8620_cable_in(ctx);
> + else
> + sii8620_cable_out(ctx);
> +}
> +
> +static int sii8620_extcon_notifier(struct notifier_block *self,
> + unsigned long event, void *ptr)
> +{
> + struct sii8620 *ctx =
> + container_of(self, struct sii8620, extcon_nb);
> +
> + schedule_work(&ctx->extcon_wq);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int sii8620_extcon_init(struct sii8620 *ctx)
> +{
> + struct extcon_dev *edev;
> + struct device_node *musb, *muic;
> + int ret;
> +
> + /* get micro-USB connector node */
> + musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
> + /* next get micro-USB Interface Controller node */
> + muic = of_get_next_parent(musb);
> +
> + if (!muic) {
> + dev_info(ctx->dev, "no extcon found, switching to 'always on' 
> mode\n");
> + return 0;
> + }
> +
> + edev = extcon_find_edev_by_node(muic);
> + of_node_put(muic);
> + if (IS_ERR(edev)) {
> + if (PTR_ERR(edev) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(ctx->dev, "Invalid or missing extcon\n");
> + return PTR_ERR(edev);
> + }
> +
> + ctx->extcon = edev;
> + ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
> + INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
> + ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);

You better to use devm_extcon_register_notifier().

> + if (ret) {
> + dev_err(ctx->dev, "failed to register notifier for MHL\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
>  {
>   return container_of(bridge, struct sii8620, bridge);
> @@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
>   if (ret)
>   return ret;
>  
> + ret = sii8620_extcon_init(ctx);
> + if (ret < 0) {
> + dev_err(ctx->dev, "failed to initialize EXTCON\n");
> + return ret;
> + }
> +
>   i2c_set_clientdata(client, ctx);
>  
>   ctx->bridge.funcs = &sii8620_bridge_funcs;
>   ctx->bridge.of_node = dev->of_node;
>   drm_bridge_add(&ctx->bridge);
>  
> - sii8620_cable_in(ctx);
> + if (!ctx->extcon)
> + sii8620_cable_in(ctx);
>  
>   return 0;
>  }
> @@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
>  {
>   struct sii8620

[PATCH v2 04/16] clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO

2018-02-28 Thread Jernej Skrabec
CLK_PLL_VIDEO needs to be referenced in HDMI DT entry as a possible
PHY clock parent.

Export it so it can be used later in DT.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h  | 4 +++-
 include/dt-bindings/clock/sun8i-h3-ccu.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
index 1b4baea37d81..73d7392c968c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
@@ -26,7 +26,9 @@
 #define CLK_PLL_AUDIO_2X   3
 #define CLK_PLL_AUDIO_4X   4
 #define CLK_PLL_AUDIO_8X   5
-#define CLK_PLL_VIDEO  6
+
+/* PLL_VIDEO is exported */
+
 #define CLK_PLL_VE 7
 #define CLK_PLL_DDR8
 
diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h 
b/include/dt-bindings/clock/sun8i-h3-ccu.h
index e139fe5c62ec..c5f7e9a70968 100644
--- a/include/dt-bindings/clock/sun8i-h3-ccu.h
+++ b/include/dt-bindings/clock/sun8i-h3-ccu.h
@@ -43,6 +43,8 @@
 #ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_
 #define _DT_BINDINGS_CLK_SUN8I_H3_H_
 
+#define CLK_PLL_VIDEO  6
+
 #define CLK_PLL_PERIPH09
 
 #define CLK_CPUX   14
-- 
2.16.2

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


Re: [PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

2018-02-28 Thread Chanwoo Choi
Hi,

On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
> Since extcon property is not allowed in DT, extcon subsystem requires
> another way to get extcon device. Lets try the simplest approach - get
> edev by of_node.
> 
> Signed-off-by: Andrzej Hajda 
> Acked-by: Chanwoo Choi 
> ---
> v5: function renamed to extcon_find_edev_by_node (Andy)
> v2: changed label to follow local convention (Chanwoo)
> ---
>  drivers/extcon/extcon.c | 44 ++--
>  include/linux/extcon.h  |  6 ++
>  2 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index cb38c2747684..47a5ca9eb86d 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
>  EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>  
>  #ifdef CONFIG_OF
> +
> +/*
> + * extcon_find_edev_by_node - Find the extcon device from devicetree.
> + * @node : OF node identyfying edev

s/identyfying/identifying

> + *
> + * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
> + */
> +struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
> +{
> + struct extcon_dev *edev;
> +
> + mutex_lock(&extcon_dev_list_lock);
> + list_for_each_entry(edev, &extcon_dev_list, entry)
> + if (edev->dev.parent && edev->dev.parent->of_node == node)
> + goto out;
> + edev = ERR_PTR(-EPROBE_DEFER);
> +out:
> + mutex_unlock(&extcon_dev_list_lock);
> +
> + return edev;
> +}
> +
>  /*
>   * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
>   * @dev  : the instance to the given device
> @@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
> device *dev, int index)
>   return ERR_PTR(-ENODEV);
>   }
>  
> - mutex_lock(&extcon_dev_list_lock);
> - list_for_each_entry(edev, &extcon_dev_list, entry) {
> - if (edev->dev.parent && edev->dev.parent->of_node == node) {
> - mutex_unlock(&extcon_dev_list_lock);
> - of_node_put(node);
> - return edev;
> - }
> - }
> - mutex_unlock(&extcon_dev_list_lock);
> + edev = extcon_find_edev_by_node(node);
>   of_node_put(node);
>  
> - return ERR_PTR(-EPROBE_DEFER);
> + return edev;
>  }
> +
>  #else
> +
> +struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +
>  struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
>  {
>   return ERR_PTR(-ENOSYS);
>  }
> +
>  #endif /* CONFIG_OF */
> +
> +EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
>  EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
>  
>  /**
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 6d94e82c8ad9..7f033b1ea568 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
> device *dev,
>   * Following APIs get the extcon_dev from devicetree or by through extcon 
> name.
>   */
>  extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
> +extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
>  extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
>int index);
>  
> @@ -283,6 +284,11 @@ static inline struct extcon_dev 
> *extcon_get_extcon_dev(const char *extcon_name)
>   return ERR_PTR(-ENODEV);
>  }
>  
> +static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
> *node)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +
>  static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device 
> *dev,
>   int index)
>  {
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 02/16] clk: sunxi-ng: h3: h5: Add minimal rate for video PLL

2018-02-28 Thread Jernej Skrabec
Although user manuals for H3 and H5 SoCs state that minimal rate
supported by video PLL is around 30 MHz, it seems that in reality
minimal rate is around 192 MHz.

Experiments showed that any rate below 96 MHz doesn't produce any video
output at all. Even at this frequency, stable output depends on right
factors. For example, when N = 4 and M = 1, output is stable and when N
= 8 and M = 2, it's not.

BSP clock driver suggest that minimum stable frequency is 192 MHz. That
would also be in line with A64 SoC, which has similar periphery.

Set minimal video PLL rate for H3/H5 to 192 MHz.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 29bc0566b776..b9f39078c0b2 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -69,17 +69,18 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-   "osc24M", 0x0010,
-   8, 7,   /* N */
-   0, 4,   /* M */
-   BIT(24),/* frac enable */
-   BIT(25),/* frac select */
-   27000,  /* frac rate 0 */
-   29700,  /* frac rate 1 */
-   BIT(31),/* gate */
-   BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video_clk, "pll-video",
+   "osc24M", 0x0010,
+   19200,  /* Minimum rate */
+   8, 7,   /* N */
+   0, 4,   /* M */
+   BIT(24),/* frac enable */
+   BIT(25),/* frac select */
+   27000,  /* frac rate 0 */
+   29700,  /* frac rate 1 */
+   BIT(31),/* gate */
+   BIT(28),/* lock */
+   CLK_SET_RATE_UNGATE);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x0018,
-- 
2.16.2

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


Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

2018-02-28 Thread Claudiu Beznea


On 27.02.2018 17:38, Daniel Thompson wrote:
> On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
>> On 27.02.2018 12:54, Daniel Thompson wrote:
>>> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
 On 26.02.2018 11:57, Jani Nikula wrote:
> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
>> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>>> Add PWM mode to pwm_config() function. The drivers which uses 
>>> pwm_config()
>>> were adapted to this change.
>>>
>>> Signed-off-by: Claudiu Beznea 
>>> ---
>>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>>>  drivers/bus/ts-nbus.c|  2 +-
>>>  drivers/clk/clk-pwm.c|  3 ++-
>>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>>>  drivers/hwmon/pwm-fan.c  |  2 +-
>>>  drivers/input/misc/max77693-haptic.c |  2 +-
>>>  drivers/input/misc/max8997_haptic.c  |  6 +-
>>>  drivers/leds/leds-pwm.c  |  5 -
>>>  drivers/media/rc/ir-rx51.c   |  5 -
>>>  drivers/media/rc/pwm-ir-tx.c |  5 -
>>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>>>  drivers/video/backlight/lp8788_bl.c  |  5 -
>>>  drivers/video/backlight/pwm_bl.c | 11 +--
>>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>>>  include/linux/pwm.h  |  6 --
>>>  16 files changed, 70 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/video/backlight/lm3630a_bl.c 
>>> b/drivers/video/backlight/lm3630a_bl.c
>>> index 2030a6b77a09..696fa25dafd2 100644
>>> --- a/drivers/video/backlight/lm3630a_bl.c
>>> +++ b/drivers/video/backlight/lm3630a_bl.c
>>> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
>>> *pchip, int br, int br_max)
>>>  {
>>> unsigned int period = pchip->pdata->pwm_period;
>>> unsigned int duty = br * period / br_max;
>>> +   struct pwm_caps caps = { };
>>>  
>>> -   pwm_config(pchip->pwmd, duty, period);
>>> +   pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, &caps);
>>> +   pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
>>
>> Well... I admit I've only really looked at the patches that impact 
>> backlight but dispersing this really odd looking bit twiddling 
>> throughout the kernel doesn't strike me a great API design.
>>
>> IMHO callers should not be required to find the first set bit in
>> some specially crafted set of capability bits simply to get sane 
>> default behaviour.
>
> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> error prone.

 Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be 
 OK
 from your side?

 Or, what about using a function like pwm_mode_first() to get the first 
 supported
 mode by PWM channel?

 Or, would you prefer to solve this inside pwm_config() function, let's 
 say, in
 case an invalid mode is passed as argument, to let pwm_config() to choose 
 the
 first available PWM mode for PWM channel passed as argument?
>>>
>>> What is it that actually needs solving?
>>>
>>> If a driver requests normal mode and the PWM driver cannot support it
>>> why not just return an error an move on.
>> Because, simply, I wasn't aware of what these PWM client drivers needs for.
> 
> I'm afraid you have confused me here.
> 
> Didn't you just *add* the whole concept of PWM caps with your patches?
> How could any existing call site expect anything except normal mode.
> Until now there has been no possiblity to request anything else.
Agree. And agree I was confusing in previous email, sorry about that. And
agree that there was nothing before and everything should work with PWM
normal mode.

When I choose to have BIT(ffs(caps.modes)) instead of PWM_MODE(NORMAL) I
was thinking at having these pwm_config() calls working all the time having
in mind that in future the PWM controllers that these drivers use, might
change in terms of PWM supported modes.

Thank you,
Claudiu Beznea

> 
> 
>>> Put another way, what is the use case for secretly adopting a mode the
>>> caller didn't want? Under what circumstances is this a good thing?
>> No one... But I wasn't aware of what the PWM clients needs for from their PWM
>> controllers. At this moment having BIT(ffs(caps.modes)) instead of
>> PWM_MODE(NORMAL) is mostly the same since all the driver that has not 
>> explicitly
>> registered PWM caps will use PWM normal mode.
>>
>> I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK 
>> from
>> your side.
>>
>> Thank you,
>> Claudiu Beznea
>>>
>>>
>>> Daniel.
>>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis

[PATCH v2 10/16] drm/sun4i: Add support for variants to DW HDMI PHY

2018-02-28 Thread Jernej Skrabec
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While
some things like clock and reset setup are the same, PHY configuration
differs a lot.

Split out code which is PHY specific to separate functions and create
a structure which holds pointers to those functions.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  | 20 ++--
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 89 +++---
 2 files changed, 76 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d8d0684fc8aa..1e9eb6072615 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -12,11 +12,23 @@
 #include 
 #include 
 
+struct sun8i_hdmi_phy;
+
+struct sun8i_hdmi_phy_variant {
+   void (*phy_init)(struct sun8i_hdmi_phy *phy);
+   void (*phy_disable)(struct dw_hdmi *hdmi,
+   struct sun8i_hdmi_phy *phy);
+   int  (*phy_config)(struct dw_hdmi *hdmi,
+  struct sun8i_hdmi_phy *phy,
+  unsigned int clk_rate);
+};
+
 struct sun8i_hdmi_phy {
-   struct clk  *clk_bus;
-   struct clk  *clk_mod;
-   struct regmap   *regs;
-   struct reset_control*rst_phy;
+   struct clk  *clk_bus;
+   struct clk  *clk_mod;
+   struct regmap   *regs;
+   struct reset_control*rst_phy;
+   struct sun8i_hdmi_phy_variant   *variant;
 };
 
 struct sun8i_dw_hdmi {
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c 
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 9d2f11ca3538..17aada64bafd 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -30,21 +30,10 @@
  */
 #define I2C_ADDR   0x69
 
-static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
-struct drm_display_mode *mode)
+static int sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
+ struct sun8i_hdmi_phy *phy,
+ unsigned int clk_rate)
 {
-   struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
-   u32 val = 0;
-
-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
-   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
-
-   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
-   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
-
-   regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
-  SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
-
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
   SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
   SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
@@ -64,21 +53,21 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void 
*data,
 * release any documentation, explanation of this values can
 * be found in i.MX 6Dual/6Quad Reference Manual.
 */
-   if (mode->crtc_clock <= 27000) {
+   if (clk_rate <= 2700) {
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
-   } else if (mode->crtc_clock <= 74250) {
+   } else if (clk_rate <= 7425) {
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
dw_hdmi_phy_i2c_write(hdmi, 0x02b5, 0x0e);
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
-   } else if (mode->crtc_clock <= 148500) {
+   } else if (clk_rate <= 14850) {
dw_hdmi_phy_i2c_write(hdmi, 0x04a0, 0x06);
dw_hdmi_phy_i2c_write(hdmi, 0x000a, 0x15);
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
@@ -103,10 +92,27 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, 
void *data,
return 0;
 };
 
-static void sun8i_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
+struct drm_display_mode *mode)
 {
struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
+   u32 val = 0;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC;
 
+   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+   val |= SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC;
+
+   regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
+  SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
+
+   re

[PATCH v2 13/16] drm/sun4i: Allow building on arm64

2018-02-28 Thread Jernej Skrabec
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which
is compatible to 32-bit SoCs, so allow building DRM driver for
arm64 architecture.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 7327da3bc94f..eee6bc0eaf97 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -1,6 +1,6 @@
 config DRM_SUN4I
tristate "DRM Support for Allwinner A10 Display Engine"
-   depends on DRM && ARM && COMMON_CLK
+   depends on DRM && (ARM || ARM64) && COMMON_CLK
depends on ARCH_SUNXI || COMPILE_TEST
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
-- 
2.16.2

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


[PATCH v2 11/16] drm/sun4i: Move and expand DW HDMI PHY register macros

2018-02-28 Thread Jernej Skrabec
DW HDMI PHY macros are moved to header file and expanded with the
registers present on newer SoCs like H3 and H5.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  | 131 +
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c |  17 -
 2 files changed, 131 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 1e9eb6072615..49161326ea5a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -12,6 +12,137 @@
 #include 
 #include 
 
+#define SUN8I_HDMI_PHY_DBG_CTRL_REG0x
+#define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCKBIT(0)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK   GENMASK(15, 8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC BIT(8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC BIT(9)
+#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK  GENMASK(23, 16)
+#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16)
+
+#define SUN8I_HDMI_PHY_REXT_CTRL_REG   0x0004
+#define SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN   BIT(31)
+
+#define SUN8I_HDMI_PHY_READ_EN_REG 0x0010
+#define SUN8I_HDMI_PHY_READ_EN_MAGIC   0x54524545
+
+#define SUN8I_HDMI_PHY_UNSCRAMBLE_REG  0x0014
+#define SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC0x42494E47
+
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG0x0020
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SWIBIT(31)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWEND  BIT(30)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWENC  BIT(29)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_CALSW  BIT(28)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVRCAL(x)  ((x) << 26)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVBH(x)((x) << 24)
+#define SUN8I_HDMI_PHY_ANA_CFG1_AMP_OPTBIT(23)
+#define SUN8I_HDMI_PHY_ANA_CFG1_EMP_OPTBIT(22)
+#define SUN8I_HDMI_PHY_ANA_CFG1_AMPCK_OPT  BIT(21)
+#define SUN8I_HDMI_PHY_ANA_CFG1_EMPCK_OPT  BIT(20)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENRCAL BIT(19)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENCALOGBIT(18)
+#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SCKTMDSBIT(17)
+#define SUN8I_HDMI_PHY_ANA_CFG1_TMDSCLK_EN BIT(16)
+#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK  GENMASK(15, 12)
+#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_ALL   (0xf << 12)
+#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDSCLK BIT(11)
+#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS2   BIT(10)
+#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS1   BIT(9)
+#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS0   BIT(8)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDSCLK  BIT(7)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS2BIT(6)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS1BIT(5)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS0BIT(4)
+#define SUN8I_HDMI_PHY_ANA_CFG1_CKEN   BIT(3)
+#define SUN8I_HDMI_PHY_ANA_CFG1_LDOEN  BIT(2)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENVBS  BIT(1)
+#define SUN8I_HDMI_PHY_ANA_CFG1_ENBI   BIT(0)
+
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG0x0024
+#define SUN8I_HDMI_PHY_ANA_CFG2_M_EN   BIT(31)
+#define SUN8I_HDMI_PHY_ANA_CFG2_PLLDBENBIT(30)
+#define SUN8I_HDMI_PHY_ANA_CFG2_SENBIT(29)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDPD  BIT(28)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDEN  BIT(27)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLRCK  BIT(26)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLR(x) ((x) << 23)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENCK  BIT(22)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENBIT(21)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CD(x)  ((x) << 19)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CKSS(x)((x) << 17)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSWCKBIT(16)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSW  BIT(15)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CSMPS(x)   ((x) << 13)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_SLV(x) ((x) << 10)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOSTCK(x) ((x) << 8)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOST(x)   ((x) << 6)
+#define SUN8I_HDMI_PHY_ANA_CFG2_REG_RESDI(x)   ((x) << 0)
+
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG0x0028
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOWCK(x)  ((x) << 30)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOW(x)((x) << 28)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_WIRE(x)((x) << 18)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMPCK(x)   ((x) << 14)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMPCK(x)   ((x) << 11)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMP(x) ((x) << 7)
+#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMP(x) ((x) << 4)
+#define SUN8I_HDMI_PHY_ANA_CFG3_SDAPD  BIT(3)
+#define SUN8I_HDMI_PHY_ANA_CFG3_SDAEN  BIT(2)
+#define SUN8I_HDMI_PHY_ANA_CFG3_SCLPD  BIT(1)
+#define SUN8I_HDMI_PHY_ANA_CFG3_SCLEN  BIT(0)
+
+#define SUN8I_HDMI_PHY_PLL_CFG1_REG0x002c
+#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD1BIT(31)
+#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD BIT(30)
+#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN 

[PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it

2018-02-28 Thread Jernej Skrabec
TCON checks for LVDS properties even if it doesn't support it. Add a
check to skip that part of the code if TCON doesn't support channel 0.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 120 +++--
 1 file changed, 63 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0d6c5ed44795..3fae4f6e695a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -850,7 +850,7 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
struct sunxi_engine *engine;
struct device_node *remote;
struct sun4i_tcon *tcon;
-   bool has_lvds_rst, has_lvds_alt, can_lvds;
+   bool has_lvds_rst, has_lvds_alt, can_lvds = false;
int ret;
 
engine = sun4i_tcon_find_engine(drv, dev->of_node);
@@ -881,52 +881,56 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   /*
-* This can only be made optional since we've had DT nodes
-* without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and print a
-* warning.
-*/
-   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
-   if (IS_ERR(tcon->lvds_rst)) {
-   dev_err(dev, "Couldn't get our reset line\n");
-   return PTR_ERR(tcon->lvds_rst);
-   } else if (tcon->lvds_rst) {
-   has_lvds_rst = true;
-   reset_control_reset(tcon->lvds_rst);
-   } else {
-   has_lvds_rst = false;
-   }
+   if (tcon->quirks->has_channel_0) {
+   /*
+* This can only be made optional since we've had DT nodes
+* without the LVDS reset properties.
+*
+* If the property is missing, just disable LVDS, and print a
+* warning.
+*/
+   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
+   if (IS_ERR(tcon->lvds_rst)) {
+   dev_err(dev, "Couldn't get our reset line\n");
+   return PTR_ERR(tcon->lvds_rst);
+   } else if (tcon->lvds_rst) {
+   has_lvds_rst = true;
+   reset_control_reset(tcon->lvds_rst);
+   } else {
+   has_lvds_rst = false;
+   }
 
-   /*
-* This can only be made optional since we've had DT nodes
-* without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and print a
-* warning.
-*/
-   if (tcon->quirks->has_lvds_alt) {
-   tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
-   if (IS_ERR(tcon->lvds_pll)) {
-   if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
-   has_lvds_alt = false;
+   /*
+* This can only be made optional since we've had DT nodes
+* without the LVDS reset properties.
+*
+* If the property is missing, just disable LVDS, and print a
+* warning.
+*/
+   if (tcon->quirks->has_lvds_alt) {
+   tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
+   if (IS_ERR(tcon->lvds_pll)) {
+   if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
+   has_lvds_alt = false;
+   } else {
+   dev_err(dev,
+   "Couldn't get the LVDS PLL\n");
+   return PTR_ERR(tcon->lvds_pll);
+   }
} else {
-   dev_err(dev, "Couldn't get the LVDS PLL\n");
-   return PTR_ERR(tcon->lvds_pll);
+   has_lvds_alt = true;
}
-   } else {
-   has_lvds_alt = true;
}
-   }
 
-   if (!has_lvds_rst || (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
-   dev_warn(dev,
-"Missing LVDS properties, Please upgrade your DT\n");
-   dev_warn(dev, "LVDS output disabled\n");
-   can_lvds = false;
-   } else {
-   can_lvds = true;
+   if (!has_lvds_rst ||
+   (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
+   dev_warn(dev,
+"Missing LVDS properties, Please upgrade your 
DT\n");
+   dev_warn(dev, "LVDS output disabled\n");
+   can_lvds = false;
+   } else {
+   can_lvds = true;
+

[PATCH v2 05/16] dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline

2018-02-28 Thread Jernej Skrabec
Add missing compatibles for H3 HDMI pipeline. These compatibles can also
be used with H5 SoC.

Signed-off-by: Jernej Skrabec 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index b995bfee734a..8bdef4920edc 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -102,6 +102,7 @@ DWC HDMI PHY
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun8i-a83t-hdmi-phy
+* allwinner,sun8i-h3-hdmi-phy
   - reg: base address and size of memory-mapped region
   - clocks: phandles to the clocks feeding the HDMI PHY
 * bus: the HDMI PHY interface clock
@@ -110,6 +111,9 @@ Required properties:
   - resets: phandle to the reset controller driving the PHY
   - reset-names: must be "phy"
 
+H3 HDMI PHY requires additional clock:
+  - pll-0: parent of phy clock
+
 TV Encoder
 --
 
@@ -275,6 +279,7 @@ Required properties:
   - compatible: value must be one of:
 * allwinner,sun8i-a83t-de2-mixer-0
 * allwinner,sun8i-a83t-de2-mixer-1
+* allwinner,sun8i-h3-de2-mixer-0
 * allwinner,sun8i-v3s-de2-mixer
   - reg: base address and size of the memory-mapped region.
   - clocks: phandles to the clocks feeding the mixer
@@ -305,6 +310,7 @@ Required properties:
 * allwinner,sun7i-a20-display-engine
 * allwinner,sun8i-a33-display-engine
 * allwinner,sun8i-a83t-display-engine
+* allwinner,sun8i-h3-display-engine
 * allwinner,sun8i-v3s-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
-- 
2.16.2

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


[PATCH v2 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-28 Thread Jernej Skrabec
Some NM PLLs doesn't work well when their output clock rate is set below
certain rate.

Add support for that constrain.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu_nm.c | 11 +++
 drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
index a16de092bf94..7fc743c78c1b 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -20,7 +20,7 @@ struct _ccu_nm {
 };
 
 static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
-struct _ccu_nm *nm)
+unsigned long min_rate, struct _ccu_nm *nm)
 {
unsigned long best_rate = 0;
unsigned long best_n = 0, best_m = 0;
@@ -30,7 +30,7 @@ static void ccu_nm_find_best(unsigned long parent, unsigned 
long rate,
for (_m = nm->min_m; _m <= nm->max_m; _m++) {
unsigned long tmp_rate = parent * _n  / _m;
 
-   if (tmp_rate > rate)
+   if (tmp_rate > rate || tmp_rate < min_rate)
continue;
 
if ((rate - tmp_rate) < (rate - best_rate)) {
@@ -117,6 +117,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
long rate,
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate *= nm->fixed_post_div;
 
+   if (rate < nm->min_rate)
+   rate = nm->min_rate;
+
if (ccu_frac_helper_has_rate(&nm->common, &nm->frac, rate)) {
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate /= nm->fixed_post_div;
@@ -134,7 +137,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
long rate,
_nm.min_m = 1;
_nm.max_m = nm->m.max ?: 1 << nm->m.width;
 
-   ccu_nm_find_best(*parent_rate, rate, &_nm);
+   ccu_nm_find_best(*parent_rate, rate, nm->min_rate, &_nm);
rate = *parent_rate * _nm.n / _nm.m;
 
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
@@ -186,7 +189,7 @@ static int ccu_nm_set_rate(struct clk_hw *hw, unsigned long 
rate,
   &_nm.m, &_nm.n);
} else {
ccu_sdm_helper_disable(&nm->common, &nm->sdm);
-   ccu_nm_find_best(parent_rate, rate, &_nm);
+   ccu_nm_find_best(parent_rate, rate, nm->min_rate, &_nm);
}
 
spin_lock_irqsave(nm->common.lock, flags);
diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
index eba586b4c7d0..1d8b459c50b7 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.h
+++ b/drivers/clk/sunxi-ng/ccu_nm.h
@@ -37,6 +37,7 @@ struct ccu_nm {
struct ccu_sdm_internal sdm;
 
unsigned intfixed_post_div;
+   unsigned intmin_rate;
 
struct ccu_common   common;
 };
@@ -88,6 +89,32 @@ struct ccu_nm {
},  \
}
 
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(_struct, _name, _parent,  \
+_reg, _min_rate,   \
+_nshift, _nwidth,  \
+_mshift, _mwidth,  \
+_frac_en, _frac_sel,   \
+_frac_rate_0, _frac_rate_1,\
+_gate, _lock, _flags)  \
+   struct ccu_nm _struct = {   \
+   .enable = _gate,\
+   .lock   = _lock,\
+   .n  = _SUNXI_CCU_MULT(_nshift, _nwidth),\
+   .m  = _SUNXI_CCU_DIV(_mshift, _mwidth), \
+   .frac   = _SUNXI_CCU_FRAC(_frac_en, _frac_sel,  \
+ _frac_rate_0, \
+ _frac_rate_1),\
+   .min_rate   = _min_rate,\
+   .common = { \
+   .reg= _reg, \
+   .features   = CCU_FEATURE_FRACTIONAL,   \
+   .hw.init= CLK_HW_INIT(_name,\
+ _parent,  \
+ &ccu_nm_ops,  \
+ _flags),  \
+   },  \
+   }
+
 #define SUNXI_CCU_NM_WITH_GATE_LOCK(_struct, _name, _parent, _reg, \
_nshift, _nwidth,

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

2018-02-28 Thread Christian König

Am 28.02.2018 um 07:44 schrieb Monk Liu:

under below scenario the obj->fence would refer to a wild pointer:

1,call reservation_object_reserved_shared
2,call reservation_object_add_shared_fence
3,call reservation_object_reserved_shared
4,call reservation_object_add_shared_fence

in step 1, staged is allocated,

in step 2, code path will go reservation_object_add_shared_replace()
and obj->fence would be assigned as staged (through RCU_INIT_POINTER)

in step 3, obj->staged will be freed(by simple kfree),
which make obj->fence point to a wild pointer...



Well that explanation is still nonsense. See 
reservation_object_add_shared_fence:

    obj->staged = NULL;


Among the first things reservation_object_add_shared_fence() does is it 
sets obj->staged to NULL.


So step 3 will not free anything and we never have a wild pointer.

Regards,
Christian.



in step 4, code path will go reservation_object_add_shared_inplace()
and inside it the @fobj (which equals to @obj->staged, set by above steps)
is already a wild pointer

should remov the kfree on staged in reservation_object_reserve_shared()

Change-Id: If7c01f1b4be3d3d8a81efa90216841f79ab1fc1c
Signed-off-by: Monk Liu 
---
  drivers/dma-buf/reservation.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 375de41..b473ccc 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -74,12 +74,9 @@ int reservation_object_reserve_shared(struct 
reservation_object *obj)
old = reservation_object_get_list(obj);
  
  	if (old && old->shared_max) {

-   if (old->shared_count < old->shared_max) {
-   /* perform an in-place update */
-   kfree(obj->staged);
-   obj->staged = NULL;
+   if (old->shared_count < old->shared_max)
return 0;
-   } else
+   else
max = old->shared_max * 2;
} else
max = 4;


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


Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

2018-02-28 Thread Tomi Valkeinen
On 13/02/18 14:00, Laurent Pinchart wrote:
> Hello,
> 
> Most of this series has previously been posted as part of "[PATCH 00/48]
> omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> Miscellaneous fixes and cleanups" posted and merged a few days ago, it
> completes the rework of the omapdrm and omapdss drivers to replace most
> global variables with dynamically-allocated objects. The actual merge of
> the omapdrm and omapdss drivers has been left out for now as it still
> suffers from unresolved issues.
> 
> As with the previous series I have other pending patches based on top of this,
> as passing driver objects around explicitly helps not relying on more global
> variables that would hinder the effort to move to the DRM bridge and DRM panel
> APIs.
> 
> Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen
> significant changes and I have thus dropped the Reviewed-by tag from
> Sebastian. All other patches have been rebased and reordered, thus sometimes
> modified to resolve conflicts, but have otherwise seen only minor changes.
> 
> The series is based on top of the omapdrm-next branch from
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git.
> 
> Tomi, as the series has been stripped of its controversial patches, I think
> it's now ready to be merged (pending review of the patches mentioned above of
> course). I have tested it on both a Panda board and an AM57xx EVM without any
> issues (and this time I made sure to try with the drivers compiled as
> modules).

Thanks, I have pushed this to my omapdrm-next.

 Tomi

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


Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-02-28 Thread Sharma, Shashank

for I915: Acked-by: Shashank Sharma 

Regards
Shashank
On 2/27/2018 6:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Cc: Shashank Sharma 
Cc: Stefan Agner 
Cc: Thierry Reding 
Cc: Boris Brezillon 
Cc: Philipp Zabel 
Cc: Laurent Pinchart 
Cc: Manfred Schlaegl 
Cc: Marek Vasut 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Alison Wang 
Cc: Eric Anholt 
Cc: Linus Walleij 
Cc: linux-renesas-...@vger.kernel.org
Cc: Maxime Ripard 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |   2 +-
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
  drivers/gpu/drm/bridge/sii902x.c   |   2 +-
  drivers/gpu/drm/bridge/tc358767.c  |   2 +-
  drivers/gpu/drm/drm_connector.c|  12 +-
  drivers/gpu/drm/drm_fb_helper.c|   2 +-
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-
  drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
  drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
  drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
  drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
  drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
  drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
  drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
  drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
  drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
  drivers/gpu/drm/imx/parallel-display.c |   2 +-
  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
  drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
  drivers/gpu/drm/panel/panel-lvds.c |   4 +-
  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
  drivers/gpu/drm/panel/panel-simple.c   |   4 +-
  drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
  drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
  drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
  drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
  include/drm/drm_connector.h| 123 -
  36 files changed, 125 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 74d2efaec52f..1ba72dc2a85b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
  
-	connector->display_info.subpixel_order = subpixel_order;

+   connector->static_display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
  
  	if (has_aux)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 120dd3b26fc2..7e9f7f1ab1b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -639,7 +639,7 @@ static int dce_virtual_connector_encoder_init(struct 
amdgpu_device *adev,
drm_connector_init(adev->ddev, connector, &dce_virtual_connector_funcs,
   DRM_MODE_CONNECTOR_VIRTUAL);
drm_connector_helper_add(connector, 
&dce_virtual_connector_helper_funcs);
-   connector->display_info.subpixel_order = SubPixelHorizontalRGB;
+   connector->static_display_info.subpixel_order = SubPixelHorizontalRGB;
connector->interlace_allowed = false;
connector->doublescan_allowed = false;
  

Re: [PATCH 02/24] drm/omap: cleanup fbdev init/free

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 13:38, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday, 12 February 2018 11:44:32 EET Tomi Valkeinen wrote:
>> omap_fbdev_init() and omap_fbdev_free() use priv->fbdev directly.
>> However, omap_fbdev_init() returns the fbdev, and omap_drv.c also
>> assigns the return value to priv->fbdev. This is slightly confusing.
>>
>> Clean this up by removing the omap_fbdev_init() return value, as we
>> don't care whether fbdev init succeeded or not. Also change omap_drv.c
>> to call omap_fbdev_init() always, and omap_fbdev_init() does the check
>> if fbdev was initialized.
> 
> I assume you mean omap_fbdev_free() for the last two occurrences (and on a 

Right, true.

> side note I wonder whether we should rename it to omap_fbdev_cleanup() or 
> omap_fbdev_fini() for symmetry with omap_fbdev_init()).

Yep, I think that makes sense.

>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_drv.c   |  9 -
>>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 10 +-
>>  drivers/gpu/drm/omapdrm/omap_fbdev.h |  5 ++---
>>  3 files changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>> b/drivers/gpu/drm/omapdrm/omap_drv.c index dd68b2556f5b..485684c637ff
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -584,7 +584,7 @@ static int pdev_probe(struct platform_device *pdev)
>>  for (i = 0; i < priv->num_crtcs; i++)
>>  drm_crtc_vblank_off(priv->crtcs[i]);
>>
>> -priv->fbdev = omap_fbdev_init(ddev);
>> +omap_fbdev_init(ddev);
>>
>>  drm_kms_helper_poll_init(ddev);
>>  omap_modeset_enable_external_hpd();
>> @@ -602,8 +602,8 @@ static int pdev_probe(struct platform_device *pdev)
>>  err_cleanup_helpers:
>>  omap_modeset_disable_external_hpd();
>>  drm_kms_helper_poll_fini(ddev);
>> -if (priv->fbdev)
>> -omap_fbdev_free(ddev);
>> +
>> +omap_fbdev_free(ddev);
>>  err_cleanup_modeset:
>>  drm_mode_config_cleanup(ddev);
>>  omap_drm_irq_uninstall(ddev);
>> @@ -632,8 +632,7 @@ static int pdev_remove(struct platform_device *pdev)
>>  omap_modeset_disable_external_hpd();
>>  drm_kms_helper_poll_fini(ddev);
>>
>> -if (priv->fbdev)
>> -omap_fbdev_free(ddev);
>> +omap_fbdev_free(ddev);
>>
>>  drm_atomic_helper_shutdown(ddev);
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 632ebcf2165f..30ce3d562414
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
>> @@ -242,7 +242,7 @@ static struct drm_fb_helper *get_fb(struct fb_info *fbi)
>> }
>>
>>  /* initialize fbdev helper */
>> -struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
>> +void omap_fbdev_init(struct drm_device *dev)
>>  {
>>  struct omap_drm_private *priv = dev->dev_private;
>>  struct omap_fbdev *fbdev = NULL;
>> @@ -275,7 +275,7 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
>> *dev)
>>
>>  priv->fbdev = helper;
>>
>> -return helper;
>> +return;
>>
>>  fini:
>>  drm_fb_helper_fini(helper);
>> @@ -283,9 +283,6 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
>> *dev) kfree(fbdev);
>>
>>  dev_warn(dev->dev, "omap_fbdev_init failed\n");
> 
> While at it I'd remove the error message when drm_fb_helper_init() fails, it 
> duplicates this one.

Ok.

>> -/* well, limp along without an fbdev.. maybe X11 will work? */
>> -
>> -return NULL;
>>  }
>>
>>  void omap_fbdev_free(struct drm_device *dev)
>> @@ -296,6 +293,9 @@ void omap_fbdev_free(struct drm_device *dev)
>>
>>  DBG();
>>
>> +if (!priv->fbdev)
>> +return;
>> +
> 
> I'd either write this as if (!helper) and replace the other occurrences of 
> priv->fbdev below, or replace helper with priv->fbdev in the whole function.

Ok.

 Tomi

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


Re: [RFC][PATCH 05/11] drm/edid: Clear display info fully

2018-02-28 Thread Sharma, Shashank

Regards

Shashank


On 2/27/2018 6:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Now that we have split the display info into static and dynamic parts,
we can just zero out the entire dynamic part with memset(). Previously
we were just clearing parts of it, leaving stale data in other parts
(eg. HDMI SCDC capabilities).

Also when the edid is NULL drm_add_edid_modes() bails out early skipping
the call to drm_add_display_info(). Thus we would again leave stale
data behind. To avoid that let's clear out the display info at the
very start of drm_add_edid_modes().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_connector.c |  3 +--
  drivers/gpu/drm/drm_edid.c  | 23 +++
  2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d73e97ed7dff..ddd7d978f462 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1389,10 +1389,9 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 * duplicate it rather than attempt to ensure some arbitrary
 * ordering of calls.
 */
+   drm_reset_display_info(connector);
if (edid)
drm_add_display_info(connector, edid);
-   else
-   drm_reset_display_info(connector);
  
  	drm_object_property_set_value(&connector->base,

  dev->mode_config.non_desktop_property,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4b4bf9..78c1f37be3db 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4443,37 +4443,18 @@ drm_reset_display_info(struct drm_connector *connector)
  {
struct drm_display_info *info = &connector->display_info;
  
-	info->width_mm = 0;

-   info->height_mm = 0;
-
-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
-   info->non_desktop = 0;
+   memset(info, 0, sizeof(*info));
  }
  EXPORT_SYMBOL_GPL(drm_reset_display_info);
  
  u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)

  {
struct drm_display_info *info = &connector->display_info;
-
u32 quirks = edid_get_quirks(edid);
  
  	info->width_mm = edid->width_cm * 10;

info->height_mm = edid->height_cm * 10;
  
-	/* driver figures it out in this case */

-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
  
  	DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);

@@ -4684,6 +4665,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
int num_modes = 0;
u32 quirks;
  
+	drm_reset_display_info(connector);
How about if we move the call to drm_reset_display_info() within 
drm_add_display_info() ?

something like:
drm_add_display_info()
{
struct drm_display_info *info = &connector->display_info;
u32 quirks = edid_get_quirks(edid);

drm_reset_display_info();

info->width_mm = edid->width_cm * 10;
info->height_mm = edid->height_cm * 10;
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);

..
}

- Shashank

+
if (edid == NULL) {
clear_eld(connector);
return 0;


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


Re: [PATCH 03/24] drm/omap: add HPD support to connector-dvi

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 14:58, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday, 12 February 2018 11:44:33 EET Tomi Valkeinen wrote:
>> Add HPD support to the DVI connector driver. The code is almost
>> identical to the HPD code in the HDMI connector driver.
> 
> Would it make sense to share a single implementation then ? Or is that an 
> exercise left for the reader (that is, me) ? :-)

It would, but I suspect all these will go away soon with the
drm_bridge/panel work, so I didn't want to start doing a bigger refactoring.

>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 114 
>>  1 file changed, 114 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c index
>> 391d80364346..f9f8700223c3 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Could you please keep headers alphabetically sorted ?

Sure.

>>  #include 
>>
>> @@ -44,6 +45,13 @@ struct panel_drv_data {
>>  struct videomode vm;
>>
>>  struct i2c_adapter *i2c_adapter;
>> +
>> +struct gpio_desc *hpd_gpio;
>> +
>> +void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
>> +void *hpd_cb_data;
>> +bool hpd_enabled;
>> +struct mutex hpd_lock;
> 
> Locks should have a comment that describes which fields they protect.

Added.
>>  };
>>
>>  #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
>> @@ -189,6 +197,9 @@ static int dvic_read_edid(struct omap_dss_device
>> *dssdev, struct panel_drv_data *ddata = to_panel_data(dssdev);
>>  int r, l, bytes_read;
>>
>> +if (ddata->hpd_gpio && !gpiod_get_value_cansleep(ddata->hpd_gpio))
>> +return -ENODEV;
>> +
>>  if (!ddata->i2c_adapter)
>>  return -ENODEV;
>>
>> @@ -220,6 +231,9 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
>>  unsigned char out;
>>  int r;
>>
>> +if (ddata->hpd_gpio)
>> +return gpiod_get_value_cansleep(ddata->hpd_gpio);
>> +
>>  if (!ddata->i2c_adapter)
>>  return true;
>>
>> @@ -228,6 +242,60 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
>> return r == 0;
>>  }
>>
>> +static int dvic_register_hpd_cb(struct omap_dss_device *dssdev,
>> + void (*cb)(void *cb_data,
>> +enum drm_connector_status status),
>> + void *cb_data)
>> +{
>> +struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +if (!ddata->hpd_gpio)
>> +return -ENOTSUPP;
>> +
>> +mutex_lock(&ddata->hpd_lock);
>> +ddata->hpd_cb = cb;
>> +ddata->hpd_cb_data = cb_data;
>> +mutex_unlock(&ddata->hpd_lock);
>> +return 0;
>> +}
>> +
>> +static void dvic_unregister_hpd_cb(struct omap_dss_device *dssdev)
>> +{
>> +struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +if (!ddata->hpd_gpio)
>> +return;
>> +
>> +mutex_lock(&ddata->hpd_lock);
>> +ddata->hpd_cb = NULL;
>> +ddata->hpd_cb_data = NULL;
>> +mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>> +static void dvic_enable_hpd(struct omap_dss_device *dssdev)
>> +{
>> +struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +if (!ddata->hpd_gpio)
>> +return;
>> +
>> +mutex_lock(&ddata->hpd_lock);
>> +ddata->hpd_enabled = true;
>> +mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>> +static void dvic_disable_hpd(struct omap_dss_device *dssdev)
>> +{
>> +struct panel_drv_data *ddata = to_panel_data(dssdev);
>> +
>> +if (!ddata->hpd_gpio)
>> +return;
>> +
>> +mutex_lock(&ddata->hpd_lock);
>> +ddata->hpd_enabled = false;
>> +mutex_unlock(&ddata->hpd_lock);
>> +}
>> +
>>  static struct omap_dss_driver dvic_driver = {
>>  .connect= dvic_connect,
>>  .disconnect = dvic_disconnect,
>> @@ -241,14 +309,60 @@ static struct omap_dss_driver dvic_driver = {
>>
>>  .read_edid  = dvic_read_edid,
>>  .detect = dvic_detect,
>> +
>> +.register_hpd_cb= dvic_register_hpd_cb,
>> +.unregister_hpd_cb  = dvic_unregister_hpd_cb,
>> +.enable_hpd = dvic_enable_hpd,
>> +.disable_hpd= dvic_disable_hpd,
>>  };
>>
>> +static irqreturn_t dvic_hpd_isr(int irq, void *data)
>> +{
>> +struct panel_drv_data *ddata = data;
>> +
>> +mutex_lock(&ddata->hpd_lock);
>> +if (ddata->hpd_enabled && ddata->hpd_cb) {
>> +enum drm_connector_status status;
>> +
>> +if (dvic_detect(&ddata->dssdev))
>> +status = connector_status_connected;
>> +else
>> +status = connector_status_disconnected;
>> +
>> +ddata->hpd_cb(ddata->hpd_cb_data, status);
>> +   

Re: [PATCH 22/24] drm/omap: fix maximum sizes

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 15:42, Laurent Pinchart wrote:

>> +/*
>> + * Note: these values are used for multiple independent things:
>> + * connector mode filtering, buffer sizes, crtc sizes...
>> + * Use big enough values here to cover all use cases, and do more
>> + * specific checking in the respective code paths.
>>   */
>> -dev->mode_config.max_width = 2048;
>> -dev->mode_config.max_height = 2048;
>> +dev->mode_config.max_width = 8192;
>> +dev->mode_config.max_height = 8192;
> 
> This makes me ponder on the usefulness of the max_width and max_height 
> fields. 
> If we end up having to set them to very large values so they don't get in the 
> way, and implement independent checks manually, the fields should then be 
> split into finer-grained parameters to make DRM core checks useful.

I agree.

 Tomi

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


[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

2018-02-28 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198745

--- Comment #15 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Am trying it out soon. Will try and capture dmesg log if it matters.

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


Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-02-28 Thread Stefan Agner
On 27.02.2018 13:56, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
> 
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
> 
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().

Back when I introduced bus flags it was meant to be a static
information.

So for the general idea/drm_connector.h:

Reviewed-by: Stefan Agner 

[...] 

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-

For fsl-dcu:

Acked-by: Stefan Agner 

--
Stefan

>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
>  drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
>  drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
>  drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
>  drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
>  drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
>  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
>  drivers/gpu/drm/imx/parallel-display.c |   2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
>  drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
>  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
>  drivers/gpu/drm/panel/panel-lvds.c |   4 +-
>  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
>  drivers/gpu/drm/panel/panel-simple.c   |   4 +-
>  drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
>  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
>  drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
>  include/drm/drm_connector.h| 123 
> -
>  36 files changed, 125 insertions(+), 106 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 74d2efaec52f..1ba72dc2a85b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
>   } else
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>  
> - connector->display_info.subpixel_order = subpixel_order;
> + connector->static_display_info.subpixel_order = subpixel_order;
>   drm_connector_register(connector);
>  
>   if (has_aux)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> index 120dd3b26fc2..7e9f7f1ab1b1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> @@ -639,7 +639,7 @@ static int
> dce_virtual_connector_encoder_init(struct amdgpu_device *adev,
>   drm_connector_init(adev->ddev, connector, &dce_virtual_connector_funcs,
>  DRM_MODE_CONNECTOR_VIRTUAL);
>   drm_connector_helper_add(connector, 
> &dce_virtual_connector_helper_funcs);
> - connector->display_info.subpixel_order = SubPixelHorizontalRGB;
> + connector->static_display_info.subpixel_order = SubPixelHorizontalRGB;
>   connector->interlace_allowed = false;
>   connector->doublescan_allowed = false;
>   drm_connector_register(connector);
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..2d18c8ef22a0 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -238,7 +238,7 @@ static int
> atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
>   crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>  
>   for_each_new_connector_in_state(state->state, connector, cstate, i) {
> - struct drm_display_in

Re: [PATCH 11/24] drm/omap: Add kernel parameter to specify the desired display order

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 15:35, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday, 12 February 2018 11:44:41 EET Tomi Valkeinen wrote:
>> From: Peter Ujfalusi 
>>
>> omapdrm.displays (int array) can be used to reorder the displays by id if
>> needed. It can be also used to disable display.
>>
>> If the board have two active displays:
>> 0 - LCD
>> 1 - HDMI
>> then:
>> omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
>> omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
>> omapdrm.displays=0 - only the LCD is enabled
>> omapdrm.displays=1 - only the HDMI is enabled
>> omapdrm.displays=-1 - disable all displays
> 
> What's the use case for this ?

fbdev uses the first display as "main" display. There are also many apps
using DRM APIs that unfortunately depend on the order, and presume the
first one is the initial or main display. It's also a nice tool for
debugging, so that you can easily fully disable a display or all displays.

 Tomi

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


Re: [PATCH 1/5] drm/prime: fix potential race in drm_gem_map_detach

2018-02-28 Thread Lucas Stach
Hi Christian,

Am Dienstag, den 27.02.2018, 12:49 +0100 schrieb Christian König:
> Unpin the GEM object only after freeing the sg table.

What is the race that is being fixed here? The SG table is private to
the importer and the importer should hopefully only call map_detach if
it is done with all operations using the SG table. Thus it shouldn't
matter that the SG table might point to moved pages during execution of
this function.

Regards,
Lucas

> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/drm_prime.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c
> b/drivers/gpu/drm/drm_prime.c
> index e82a976f0fba..c38dacda6119 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -230,26 +230,26 @@ void drm_gem_map_detach(struct dma_buf
> *dma_buf,
>   struct drm_prime_attachment *prime_attach = attach->priv;
>   struct drm_gem_object *obj = dma_buf->priv;
>   struct drm_device *dev = obj->dev;
> - struct sg_table *sgt;
>  
> - if (dev->driver->gem_prime_unpin)
> - dev->driver->gem_prime_unpin(obj);
> + if (prime_attach) {
> + struct sg_table *sgt = prime_attach->sgt;
>  
> - if (!prime_attach)
> - return;
> -
> - sgt = prime_attach->sgt;
> - if (sgt) {
> - if (prime_attach->dir != DMA_NONE)
> - dma_unmap_sg_attrs(attach->dev, sgt->sgl,
> sgt->nents,
> -prime_attach->dir,
> -DMA_ATTR_SKIP_CPU_SYNC);
> - sg_free_table(sgt);
> + if (sgt) {
> + if (prime_attach->dir != DMA_NONE)
> + dma_unmap_sg_attrs(attach->dev, sgt-
> >sgl,
> +sgt->nents,
> +prime_attach-
> >dir,
> +DMA_ATTR_SKIP_CPU
> _SYNC);
> + sg_free_table(sgt);
> + }
> +
> + kfree(sgt);
> + kfree(prime_attach);
> + attach->priv = NULL;
>   }
>  
> - kfree(sgt);
> - kfree(prime_attach);
> - attach->priv = NULL;
> + if (dev->driver->gem_prime_unpin)
> + dev->driver->gem_prime_unpin(obj);
>  }
>  EXPORT_SYMBOL(drm_gem_map_detach);
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-intel-next

2018-02-28 Thread Joonas Lahtinen
Hi Dave,

Cannonlake driver support is fine for the hardware we've had at our disposal
to test on, so we've removed the alpha_support protection for it. That'll be
the biggest visible change.

Other than there's fixes for Dell Venue 8 Pro display issues, audio only HDMI
and out-fences from execbuf.

Many of the Icelake patches are still being reviewed, so expect more in the
last pull request.

Regards, Joonas

The following changes since commit 2f2f2db86d63605b1f57780ead21d4968e9d0bf3:

  drm/i915: Update DRIVER_DATE to 20180207 (2018-02-07 09:26:04 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-02-21

for you to fetch changes up to fed8165851e262575585b22055ff5dba7d91b0e5:

  drm/i915: Update DRIVER_DATE to 20180221 (2018-02-21 15:21:30 +0200)


Driver Changes:

- Lift alpha_support protection from Cannonlake (Rodrigo)
* Meaning the driver should mostly work for the hardware we had
  at our disposal when testing
* Used to be preliminary_hw_support
- Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo)
- Cannonlake port register fix (Mahesh)

- Fix Dell Venue 8 Pro black screen after modeset (Hans)
- Fix for always returning zero out-fence from execbuf (Daniele)
- Fix HDMI audio when no no relevant video output is active (Jani)
- Fix memleak of VBT data on driver_unload (Hans)

- Fix for KASAN found locking issue (Maarten)
- RCU barrier consolidation to improve igt/gem_sync/idle (Chris)
- Optimizations to IRQ handlers (Chris)
- vblank tracking improvements (64-bit resolution, PM) (Dhinakaran)
- Pipe select bit corrections (Ville)
- Reduce runtime computed device_info fields (Chris)
- Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris)
- A bunch of kerneldoc warning fixes (Chris)


Chris Wilson (63):
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Skip request serialisation if the timeline is already complete
  drm/i915: Trim the retired request queue after submitting
  drm/i915: Tidy up some error messages around reset failure
  drm/i915/pmu: Fix building without CONFIG_PM
  drm/i915/guc: Allow preempt-client to be NULL
  drm/i915: Move the scheduler feature bits into the purview of the engines
  drm/i915: Only allocate preempt context when required
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Remove superfluous worker wakeups when RPS is already boosted
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Mark the device as wedged from the beginning of set-wedged
  drm/i915: Be paranoid and post the writes to stop the rings
  drm/i915: Wait for gen3 reset status to be asserted
  drm/i915: Fix kerneldoc warnings for i915_gpu_error
  drm/i915: Fix kerneldoc warnings for intel_ringbuffer
  drm/i915: Fix kerneldoc warnings for i915_gem_userptr
  drm/i915: Fix kerneldoc warnings for i915_gem_request
  drm/i915: Remove lost comment from i915_gem_context
  drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
  drm/i915: Fix kerneldoc parameter markup
  drm/i915: Fix kerneldoc warnings in i915_gem_execbuffer
  drm/i915: Fix kerneldoc warnings for i915_gem_internal
  drm/i915: Disable unused-but-set compiler warning
  drm/i915: Avoid leaking lpe audio platdev.data
  drm/i915/crt: Silence compiler warning for uninitialised status
  drm/i915: Remove redundant check on execlists interrupt
  drm/i915: Move the final intel_gpu_reset() to after declaring wedged
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915: Hold rpm wakeref for printing the engine's register state
  drm/i915: Replace open-coded memset_p()
  drm/i915/selftests: Report setup errors for igt_partial_tiling
  drm/i915/tv: Cleanup up obsolete comments
  drm/i915/sdvo: Tidy up commentary
  drm/i915/panel: Add missing parameters to kerneldoc
  drm/i915/panel: Split range scaling calculation for readiblity
  drm/i915/crt: Remove obsolete kerneldoc-esque comment
  drm/i915/dvo: Remove incorrect kerneldoc markups
  drm/i915/dvo: Fixup commentary
  drm/i915/lvds: Fixup commentary
  drm/i915: Add missing kerneldoc parameters for huc_ucode_xfer
  drm/i915: Fixup kerneldoc for intel_uc_fw_upload()
  drm/i915/atomic: Fixup kerneldoc
  drm/i915: Fixup kerneldoc
  drm/i915: Fixup kerneldoc for intel_pm.c
  drm/i915: Clean up ancient doc comments for i915_ioc32.c
  drm/i915/gtt: Convert WARN_ON to GEM debugging
  drm/i915: Store gen_mask inside the static device info
  drm/i915: Always define GEN as part of GENx_FEATURES
  drm/i915: Store pla

Re: [PATCH 24/24] drm/omap: cleanup color space conversion

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 16:08, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Monday, 12 February 2018 11:44:54 EET Tomi Valkeinen wrote:
>> The setup code for color space conversion is a bit messy. This patch
>> cleans it up.
>>
>> For some reason the TRM uses values in YCrCb order, which is also used
>> in the current driver, whereas everywhere else it's YCbCr (which also
>> matches YUV order). This patch changes the tables to use the common
>> order to avoid confusion.
>>
>> The tables are split into separate lines, and comments added for
>> clarity.
>>
>> WB color conversion registers are similar but different than non-WB, but
>> the same function was used to write both. It worked fine because the
>> coef table was adjusted accordingly, but that was rather confusing. This
>> patch adds a separate function to write the WB values so that the coef
>> table can be written in an understandable way.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dispc.c | 59 ++
>>  1 file changed, 44 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> b/drivers/gpu/drm/omapdrm/dss/dispc.c index ff09e2be470f..697274317f7c
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
>> @@ -345,11 +345,6 @@ static const struct {
>>  },
>>  };
>>
>> -struct color_conv_coef {
>> -int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
>> -int full_range;
>> -};
>> -
>>  static unsigned long dispc_fclk_rate(void);
>>  static unsigned long dispc_core_clk_rate(void);
>>  static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
>> @@ -841,9 +836,18 @@ static void dispc_ovl_set_scale_coef(enum omap_plane_id
>> plane, int fir_hinc, }
>>  }
>>
>> +struct csc_coef_yuv2rgb {
>> +int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
> 
> If you made this a 3x3 matrix without explicit names for the fields I think 
> you wouldn't need two structure and two functions.

That is true, but I think it would also make the code more difficult to
follow. It's not exactly obvious which coefficients go where.

>> +bool full_range;
>> +};
>> +
>> +struct csc_coef_rgb2yuv {
>> +int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
>> +bool full_range;
>> +};
>>
>>  static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
>> -const struct color_conv_coef *ct)
>> +const struct csc_coef_yuv2rgb *ct)
>>  {
>>  #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
>>
>> @@ -853,7 +857,24 @@ static void dispc_ovl_write_color_conv_coef(enum
>> omap_plane_id plane, dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3),
>> CVAL(ct->bcr, ct->by)); dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4),
>> CVAL(0, ct->bcb));
>>
>> -REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
>> +REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
> 
> true and false should be equal to 1 and 0 respectively, so the !! shouldn't 
> be 
> needed.

Yep.

>> +
>> +#undef CVAL
>> +}
>> +
>> +static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv
>> *ct)
>> +{
>> +const enum omap_plane_id plane = OMAP_DSS_WB;
>> +
>> +#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
>> +
>> +dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,  ct->yr));
>> +dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
>> +dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct->crg));
>> +dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct->cbr));
>> +dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
>> +
>> +REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
>>
>>  #undef CVAL
>>  }
>> @@ -862,20 +883,28 @@ static void dispc_setup_color_conv_coef(void)
>>  {
>>  int i;
>>  int num_ovl = dispc_get_num_ovls();
>> -const struct color_conv_coef ctbl_bt601_5_ovl = {
>> -/* YUV -> RGB */
>> -298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
>> +
>> +/* YUV -> RGB, ITU-R BT.601, limited range */
>> +const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
>> +298,0,  409,/* ry, rcb, rcr */
>> +298, -100, -208,/* gy, gcb, gcr */
>> +298,  516,0,/* by, bcb, bcr */
> 
> The 517 turned into 516, was that intentional ?

Good point. It's been a while, but I did recalculate these, and with
rounding, all the other values match except the 517, so I changed it
according to my calculations.

That said, I'm not sure if the original calculations are correct, as
they seem to use 256 as multiplier, which would not result 0xff from 1.0
value. In any case, I changed the single value that seemed to be off
from the other ones.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
__

Re: [PATCH 24/24] drm/omap: cleanup color space conversion

2018-02-28 Thread Laurent Pinchart
Hi Tomi,

On Wednesday, 28 February 2018 12:09:35 EET Tomi Valkeinen wrote:
> On 27/02/18 16:08, Laurent Pinchart wrote:
> > On Monday, 12 February 2018 11:44:54 EET Tomi Valkeinen wrote:
> >> The setup code for color space conversion is a bit messy. This patch
> >> cleans it up.
> >> 
> >> For some reason the TRM uses values in YCrCb order, which is also used
> >> in the current driver, whereas everywhere else it's YCbCr (which also
> >> matches YUV order). This patch changes the tables to use the common
> >> order to avoid confusion.
> >> 
> >> The tables are split into separate lines, and comments added for
> >> clarity.
> >> 
> >> WB color conversion registers are similar but different than non-WB, but
> >> the same function was used to write both. It worked fine because the
> >> coef table was adjusted accordingly, but that was rather confusing. This
> >> patch adds a separate function to write the WB values so that the coef
> >> table can be written in an understandable way.
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >> 
> >>  drivers/gpu/drm/omapdrm/dss/dispc.c | 59 ---
> >>  1 file changed, 44 insertions(+), 15 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> b/drivers/gpu/drm/omapdrm/dss/dispc.c index ff09e2be470f..697274317f7c
> >> 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> @@ -345,11 +345,6 @@ static const struct {
> >>},
 >>  };
> >> 
> >> -struct color_conv_coef {
> >> -  int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
> >> -  int full_range;
> >> -};
> >> -
> >>  static unsigned long dispc_fclk_rate(void);
> >>  static unsigned long dispc_core_clk_rate(void);
> >>  static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
> >> @@ -841,9 +836,18 @@ static void dispc_ovl_set_scale_coef(enum
> >> omap_plane_id plane, int fir_hinc, }
> >> 
> >>  }
> >> 
> >> +struct csc_coef_yuv2rgb {
> >> +  int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
> > 
> > If you made this a 3x3 matrix without explicit names for the fields I
> > think you wouldn't need two structure and two functions.
> 
> That is true, but I think it would also make the code more difficult to
> follow. It's not exactly obvious which coefficients go where.

I don't expect this code to be often read, and I think that with appropriate 
comments in the source code and proper formatting of the table, as you do 
below, it should be clear enough, but I'll leave it up to you. We're really 
programming a 3x3 matrix in the hardware, so I think that modeling it as a 3x3 
matrix in the driver makes sense :-)

> >> +  bool full_range;
> >> +};
> >> +
> >> +struct csc_coef_rgb2yuv {
> >> +  int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
> >> +  bool full_range;
> >> +};
> >> 
> >>  static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
> >> 
> >> -  const struct color_conv_coef *ct)
> >> +  const struct csc_coef_yuv2rgb *ct)
> >> 
> >>  {
> >>  #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> >> 
> >> @@ -853,7 +857,24 @@ static void dispc_ovl_write_color_conv_coef(enum
> >> omap_plane_id plane, dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3),
> >> CVAL(ct->bcr, ct->by)); dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4),
> >> CVAL(0, ct->bcb));
> >> 
> >> -  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
> >> +  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
> > 
> > true and false should be equal to 1 and 0 respectively, so the !!
> > shouldn't be needed.
> 
> Yep.
> 
> >> +
> >> +#undef CVAL
> >> +}
> >> +
> >> +static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv
> >> *ct)
> >> +{
> >> +  const enum omap_plane_id plane = OMAP_DSS_WB;
> >> +
> >> +#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> >> +
> >> +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,  ct->yr));
> >> +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
> >> +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct->crg));
> >> +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct->cbr));
> >> +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
> >> +
> >> +  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
> >>  #undef CVAL
> >>  }
> >> 
> >> @@ -862,20 +883,28 @@ static void dispc_setup_color_conv_coef(void)
> >>  {
> >>int i;
> >>int num_ovl = dispc_get_num_ovls();
> >> -  const struct color_conv_coef ctbl_bt601_5_ovl = {
> >> -  /* YUV -> RGB */
> >> -  298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
> >> +
> >> +  /* YUV -> RGB, ITU-R BT.601, limited range */
> >> +  const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> >> +  298,0,  409,/* ry, rcb, rcr */
> >> +  298, -100, -208,/* gy, gcb, gcr */
> >> +  298,  516,0,/* by, bcb, bcr */
> > 
> > The 517 t

Re: [PATCH 24/24] drm/omap: cleanup color space conversion

2018-02-28 Thread Tomi Valkeinen
On 28/02/18 12:13, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 28 February 2018 12:09:35 EET Tomi Valkeinen wrote:
>> On 27/02/18 16:08, Laurent Pinchart wrote:
>>> On Monday, 12 February 2018 11:44:54 EET Tomi Valkeinen wrote:
 The setup code for color space conversion is a bit messy. This patch
 cleans it up.

 For some reason the TRM uses values in YCrCb order, which is also used
 in the current driver, whereas everywhere else it's YCbCr (which also
 matches YUV order). This patch changes the tables to use the common
 order to avoid confusion.

 The tables are split into separate lines, and comments added for
 clarity.

 WB color conversion registers are similar but different than non-WB, but
 the same function was used to write both. It worked fine because the
 coef table was adjusted accordingly, but that was rather confusing. This
 patch adds a separate function to write the WB values so that the coef
 table can be written in an understandable way.

 Signed-off-by: Tomi Valkeinen 
 ---

  drivers/gpu/drm/omapdrm/dss/dispc.c | 59 ---
  1 file changed, 44 insertions(+), 15 deletions(-)

 diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
 b/drivers/gpu/drm/omapdrm/dss/dispc.c index ff09e2be470f..697274317f7c
 100644
 --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
 +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
 @@ -345,11 +345,6 @@ static const struct {
},
>  >>  };

 -struct color_conv_coef {
 -  int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
 -  int full_range;
 -};
 -
  static unsigned long dispc_fclk_rate(void);
  static unsigned long dispc_core_clk_rate(void);
  static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
 @@ -841,9 +836,18 @@ static void dispc_ovl_set_scale_coef(enum
 omap_plane_id plane, int fir_hinc, }

  }

 +struct csc_coef_yuv2rgb {
 +  int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
>>>
>>> If you made this a 3x3 matrix without explicit names for the fields I
>>> think you wouldn't need two structure and two functions.
>>
>> That is true, but I think it would also make the code more difficult to
>> follow. It's not exactly obvious which coefficients go where.
> 
> I don't expect this code to be often read, and I think that with appropriate 
> comments in the source code and proper formatting of the table, as you do 
> below, it should be clear enough, but I'll leave it up to you. We're really 
> programming a 3x3 matrix in the hardware, so I think that modeling it as a 
> 3x3 
> matrix in the driver makes sense :-)

Yep. Well, another reason to not change this here is that Jyri has made
a patch to add full range and bt.709 conversions, based on this one.
Changing the structs here would break his patch, and verifying these
conversions is somewhat time consuming.

I'm fine with revisiting the struct after Jyri's patch is also merged.

 +  bool full_range;
 +};
 +
 +struct csc_coef_rgb2yuv {
 +  int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
 +  bool full_range;
 +};

  static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,

 -  const struct color_conv_coef *ct)
 +  const struct csc_coef_yuv2rgb *ct)

  {
  #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))

 @@ -853,7 +857,24 @@ static void dispc_ovl_write_color_conv_coef(enum
 omap_plane_id plane, dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3),
 CVAL(ct->bcr, ct->by)); dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4),
 CVAL(0, ct->bcb));

 -  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
 +  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
>>>
>>> true and false should be equal to 1 and 0 respectively, so the !!
>>> shouldn't be needed.
>>
>> Yep.
>>
 +
 +#undef CVAL
 +}
 +
 +static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv
 *ct)
 +{
 +  const enum omap_plane_id plane = OMAP_DSS_WB;
 +
 +#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
 +
 +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,  ct->yr));
 +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
 +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct->crg));
 +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct->cbr));
 +  dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
 +
 +  REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
  #undef CVAL
  }

 @@ -862,20 +883,28 @@ static void dispc_setup_color_conv_coef(void)
  {
int i;
int num_ovl = dispc_get_num_ovls();
 -  const struct color_conv_coef ctbl_bt601_5_ovl = {
 -  /* YUV -> RGB */
 -  

Re: [PATCH 1/5] drm/prime: fix potential race in drm_gem_map_detach

2018-02-28 Thread Christian König

Am 28.02.2018 um 10:48 schrieb Lucas Stach:

Hi Christian,

Am Dienstag, den 27.02.2018, 12:49 +0100 schrieb Christian König:

Unpin the GEM object only after freeing the sg table.

What is the race that is being fixed here? The SG table is private to
the importer and the importer should hopefully only call map_detach if
it is done with all operations using the SG table. Thus it shouldn't
matter that the SG table might point to moved pages during execution of
this function.


Exactly, it shouldn't matter. This is just a precaution.

When the device driver is buggy I want proper error messages from IOMMU 
and not accessing pages which might already be reused for something else.


Regards,
Christian.



Regards,
Lucas


Signed-off-by: Christian König 
---
  drivers/gpu/drm/drm_prime.c | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c
b/drivers/gpu/drm/drm_prime.c
index e82a976f0fba..c38dacda6119 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -230,26 +230,26 @@ void drm_gem_map_detach(struct dma_buf
*dma_buf,
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
-   struct sg_table *sgt;
  
-	if (dev->driver->gem_prime_unpin)

-   dev->driver->gem_prime_unpin(obj);
+   if (prime_attach) {
+   struct sg_table *sgt = prime_attach->sgt;
  
-	if (!prime_attach)

-   return;
-
-   sgt = prime_attach->sgt;
-   if (sgt) {
-   if (prime_attach->dir != DMA_NONE)
-   dma_unmap_sg_attrs(attach->dev, sgt->sgl,
sgt->nents,
-  prime_attach->dir,
-  DMA_ATTR_SKIP_CPU_SYNC);
-   sg_free_table(sgt);
+   if (sgt) {
+   if (prime_attach->dir != DMA_NONE)
+   dma_unmap_sg_attrs(attach->dev, sgt-

sgl,

+  sgt->nents,
+  prime_attach-

dir,

+  DMA_ATTR_SKIP_CPU
_SYNC);
+   sg_free_table(sgt);
+   }
+
+   kfree(sgt);
+   kfree(prime_attach);
+   attach->priv = NULL;
}
  
-	kfree(sgt);

-   kfree(prime_attach);
-   attach->priv = NULL;
+   if (dev->driver->gem_prime_unpin)
+   dev->driver->gem_prime_unpin(obj);
  }
  EXPORT_SYMBOL(drm_gem_map_detach);
  


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


[GIT PULL] tilcdc changes for 4.17

2018-02-28 Thread Jyri Sarha
Hi Dave,
Please pull the tilcdc changes for Linux v4.17.

Best regards and thanks,
Jyri

The following changes since commit 8bb5b22255dac09cd74eae9f86333b474d69fbbe:

  Merge branch 'drm-next-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2018-02-28
11:44:29 +1000)

are available in the git repository at:

  https://github.com/jsarha/linux tags/tilcdc-4.17

for you to fetch changes up to 7f78c3d69df03674644b724cdf4f01d67962beb4:

  drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel"
(2018-02-28 11:48:25 +0200)


drm/tilcdc changes to v4.17


Jyri Sarha (2):
  drm/tilcdc: Add support for drm panels
  drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel"

Markus Elfring (2):
  drm/tilcdc: Delete an error message for a failed memory allocation
in seven functions
  drm/tilcdc: panel: Use common error handling code in
of_get_panel_info()

 drivers/gpu/drm/tilcdc/Kconfig   |  2 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 29 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c| 23 ---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  8 ++--
 6 files changed, 34 insertions(+), 36 deletions(-)

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


[PATCH v2] drm/panel: simple: Add TVC S9700RTWV43TR-01B 800x480 panel support

2018-02-28 Thread Jyri Sarha
Add support for TVC S9700RTWV43TR-01B 800x480 panel found on TI's
AM335X-EVM.

Signed-off-by: Jyri Sarha 
Reviewed-by: Tomi Valkeinen 
---
The only change is added "Reviewed-by: Tomi Valkeinen ".
Who is going to pick this up?

The first version of the patch can be found here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/166902.html

 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..3b0ba9f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1962,6 +1962,29 @@ static const struct panel_desc tpk_f10a_0102 = {
},
 };
 
+static const struct drm_display_mode tvc_s9700rtwv43tr_01b_mode = {
+   .clock = 3000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 39,
+   .hsync_end = 800 + 39 + 47,
+   .htotal = 800 + 39 + 47 + 39,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 2,
+   .vtotal = 480 + 13 + 2 + 29,
+   .vrefresh = 62,
+};
+
+static const struct panel_desc tvc_s9700rtwv43tr_01b = {
+   .modes = &tvc_s9700rtwv43tr_01b_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 155,
+   .height = 90,
+   },
+};
+
 static const struct display_timing urt_umsh_8596md_timing = {
.pixelclock = { 3326, 3326, 3326 },
.hactive = { 800, 800, 800 },
@@ -2214,6 +2237,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "tpk,f10a-0102",
.data = &tpk_f10a_0102,
}, {
+   .compatible = "tvc,s9700rtwv43tr-01b",
+   .data = &tvc_s9700rtwv43tr_01b,
+   }, {
.compatible = "urt,umsh-8596md-t",
.data = &urt_umsh_8596md_parallel,
}, {
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

2018-02-28 Thread Robert Foss

Hey,

On 02/23/2018 03:34 PM, Stefan Schake wrote:

Hey Eric,

On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt  wrote:

Stefan Schake  writes:


Android assumes an implicit black background layer is always present
behind all layers it specifies for composition. drm_hwcomposer currently
punts responsibility for this to the kernel/DRM platform and puts layers
with per-pixel alpha content on the primary plane when requested.

On some platforms (e.g. VC4) a background color fill has a cycle cost for
the hardware composer and is not enabled by default. Instead, userland can
request a background color through a CRTC property. Use this property to
specify the implicit black background Android expects.

Signed-off-by: Stefan Schake 
---
Kernel changes for this (background_color) are available here:

https://github.com/stschake/linux/commits/background-upstream

Sending as RFC because I'm not entirely clear on whose responsibility
this should be, on most DRM drivers it seems to be implicit. I think
a case could also be made that VC4 should not accept alpha formats on
the lowest layer or enable background color fill when given one anyway.
On the other hand, userland control over background color seems desirable
regardless and is a feature of multiple hardware composers (i915, vc4, omap).


Couldn't we just ignore the alpha channel on the primary plane, on the
assumption that it's supposed to be all zeroes below it?  Or are we not
premultiplied, so we do still need to multiply the primary plane's
colors by the alpha value?  I couldn't find any obvious DRM
documentation about whether alpha is premultiplied.


That would work, too (for a black background anyway). Though the easiest place
to spoof this is presumably in the kernel. From what I have seen, everything in
Android is already premultiplied, but technically it can specify
either. Not sure if this
is correctly handled in drm_hwcomposer yet.



To me Erics solution sounds pragmatic, and would be easy to reason about going 
forward. Making sure that all of the kernel drivers behave the same way might be 
the hardest part.


Stefan: Are you looking at an entirely kernel side fix now, or are you pushing 
this series forward?



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


[Bug 104920] Broken hardware video encoding with vaapi/ffmpeg

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104920

--- Comment #6 from Andy Furniss  ---
(In reply to Luke McKee from comment #3)

> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
> -hwaccel_output_format vaapi -ss 120 -t 120 -i a-movie.mkv -map 0:0 -map 0:1
> -c:v h264_vaapi -b:v 4000k -qp 20 -bf 0 -profile:v 578 (or
> constrained_baseline in ffmpeg-git) -movflags +faststart -quality:v 0
> -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest.mp4

Not related to any issue as such - and I don't have the same h/w to test, but
some thoughts related to the command line.

-b:v 4000k -qp 20

I would think one or the other, not both ie. you want constant bitrate or you
want constant qp (= highly variable bitrate). I didn't test what ffmpeg takes
this to mean.

-coder:v cavlc

I don't think this is hooked up - you will probably get cabac or calvlc
depending on h/w.

-quality:v 0

I don't thing this will do anything either on VCE (I don't know anything about
the newer engines)

-- 
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 hwc v1] drm_hwcomposer: Fix comment on worker_test

2018-02-28 Thread Robert Foss

Thanks Rhys! Pushed.

I removed the Change-Id field though.


Rob.

On 02/26/2018 07:17 AM, Rhys Kidd wrote:

Reflect the boolean logic of the accompanying code, which is run after
Worker.InitWorker() has completed in test setup.

Change-Id: If5187bdaa944c5d74a70c55b5b5e58e1baa20511
Signed-off-by: Rhys Kidd 
---
  tests/worker_test.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/worker_test.cpp b/tests/worker_test.cpp
index 38f91db..82523f0 100644
--- a/tests/worker_test.cpp
+++ b/tests/worker_test.cpp
@@ -66,7 +66,7 @@ struct WorkerTest : public testing::Test {
  };
  
  TEST_F(WorkerTest, test_worker) {

-  // already isInitialized so should fail
+  // already isInitialized so should succeed
ASSERT_TRUE(worker.initialized());
  
int val = worker.value;



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


[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

2018-02-28 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198745

--- Comment #16 from Kyle De'Vir (kyle.de...@mykolab.com) ---
No change... dmesg looks no different. :/

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


[PATCH v2 1/2] drm/panel: Remove drm_panel_detach() calls from all panel drives

2018-02-28 Thread Jyri Sarha
Setting the connector and drm to NULL when the drm panel device is
going away hardly serves any purpose. Usually the the whole memory
stucture is freed right after the remove call.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c| 1 -
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   | 1 -
 drivers/gpu/drm/panel/panel-lvds.c   | 1 -
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 -
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  | 1 -
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  | 1 -
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 1 -
 drivers/gpu/drm/panel/panel-simple.c | 1 -
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c   | 1 -
 9 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 57df39b..bb53e08 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -292,7 +292,6 @@ static int innolux_panel_remove(struct mipi_dsi_device *dsi)
DRM_DEV_ERROR(&dsi->dev, "failed to detach from DSI host: %d\n",
  err);
 
-   drm_panel_detach(&innolux->base);
innolux_panel_del(innolux);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 0a94ab7..99caa78 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -500,7 +500,6 @@ static int jdi_panel_remove(struct mipi_dsi_device *dsi)
dev_err(&dsi->dev, "failed to detach from DSI host: %d\n",
ret);
 
-   drm_panel_detach(&jdi->base);
jdi_panel_del(jdi);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index b5e3994..e8bc356 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -282,7 +282,6 @@ static int panel_lvds_remove(struct platform_device *pdev)
 {
struct panel_lvds *lvds = dev_get_drvdata(&pdev->dev);
 
-   drm_panel_detach(&lvds->panel);
drm_panel_remove(&lvds->panel);
 
panel_lvds_disable(&lvds->panel);
diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 74a8061..cb4dfb9 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -299,7 +299,6 @@ static int wuxga_nt_panel_remove(struct mipi_dsi_device 
*dsi)
if (ret < 0)
dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
 
-   drm_panel_detach(&wuxga_nt->base);
wuxga_nt_panel_del(wuxga_nt);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c 
b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
index 71c09ed..75f9253 100644
--- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -292,7 +292,6 @@ static int seiko_panel_remove(struct platform_device *pdev)
 {
struct seiko_panel *panel = dev_get_drvdata(&pdev->dev);
 
-   drm_panel_detach(&panel->base);
drm_panel_remove(&panel->base);
 
seiko_panel_disable(&panel->base);
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 6bf8730..02fc0f5 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -418,7 +418,6 @@ static int sharp_panel_remove(struct mipi_dsi_device *dsi)
if (err < 0)
dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", err);
 
-   drm_panel_detach(&sharp->base);
sharp_panel_del(sharp);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 494aa9b..e5cae00 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -327,7 +327,6 @@ static int sharp_nt_panel_remove(struct mipi_dsi_device 
*dsi)
if (ret < 0)
dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
 
-   drm_panel_detach(&sharp_nt->base);
sharp_nt_panel_del(sharp_nt);
 
return 0;
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3b0ba9f..5aa736c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -364,7 +364,6 @@ static int panel_simple_remove(struct device *dev)
 {
struct panel_simple *panel = dev_get_drvdata(dev);
 
-   drm_panel_detach(&panel->base);
drm_panel_remove(&panel->base);
 
panel_simple_disable(&panel->base);
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c 
b/drivers/gpu/drm/panel/panel

[PATCH v2 0/2] drm/panel: Add device link in drm_panel_attach()

2018-02-28 Thread Jyri Sarha
The first version of the series can be found here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/166909.html

The only change is the dev_err print in drm_panel_attach() if
device_link_add() fails.

The device_link_del() is still there in drm_panel_detach(), despite
Lukas Wunner's comment[1]. In the usual (currently all) cases things
would work perfectly without the call too, because
device_links_driver_cleanup() will eventually remove all orphaned
links. However, this would cause an error in the situation where a drm
device would like to detach a panel but remain operational, since the
drm device would be unbound for no good reason if the detached panel
is later unbound.

Anyway, if somebody still comes up with an argument for dropping the
device_link_del() from drm_panel_detach(), I'll do it as things will
normally work fine either case (drm devices don't normally detach
panels and remain operational).

These older comment still apply:

The first patch could be squashed to second, but kept is separate
since I think it is correct even without the second patch.

With these patches unbinding a panel driver in use does not cause
nasty backtraces and corrupted drm core structures, but instead it
cleanly unbind the drm master device at the same time.

The only down side (currently[2]) is that the drm device does not reprobe
if the panel driver is bound again, but everything should work if the
drm master driver is bound manually.

Best regards,
Jyri

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167047.html
[2] https://lists.freedesktop.org/archives/dri-devel/2018-February/166907.html

Jyri Sarha (2):
  drm/panel: Remove drm_panel_detach() calls from all panel drives
  drm/panel: Add device_link from panel device to drm device

 drivers/gpu/drm/drm_panel.c  | 12 
 drivers/gpu/drm/panel/panel-innolux-p079zca.c|  1 -
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c   |  1 -
 drivers/gpu/drm/panel/panel-lvds.c   |  1 -
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c |  1 -
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c  |  1 -
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c  |  1 -
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  |  1 -
 drivers/gpu/drm/panel/panel-simple.c |  1 -
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c   |  1 -
 include/drm/drm_panel.h  |  1 +
 11 files changed, 13 insertions(+), 9 deletions(-)

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCH v2 2/2] drm/panel: Add device_link from panel device to drm device

2018-02-28 Thread Jyri Sarha
Add device_link from panel device (supplier) to drm device (consumer)
with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
the master drm driver is not protected against the attached. The
device_link with DL_FLAG_AUTOREMOVE should make sure the drm device is
unbound before the panel driver becomes unavailable.

The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the panel driver it self when
it is removed. Otherwise the both driver are racing to delete the same
link.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/drm_panel.c | 12 
 include/drm/drm_panel.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 308d442..afa8337 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -98,9 +99,18 @@ EXPORT_SYMBOL(drm_panel_remove);
  */
 int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
 {
+   u32 flags = DL_FLAG_AUTOREMOVE;
+
if (panel->connector)
return -EBUSY;
 
+   panel->link = device_link_add(connector->dev->dev, panel->dev, flags);
+   if (!panel->link) {
+   dev_err(panel->dev, "failed to link panel to %s\n",
+   dev_name(connector->dev->dev));
+   return -EINVAL;
+   }
+
panel->connector = connector;
panel->drm = connector->dev;
 
@@ -119,6 +129,8 @@ EXPORT_SYMBOL(drm_panel_attach);
  */
 int drm_panel_detach(struct drm_panel *panel)
 {
+   device_link_del(panel->link);
+
panel->connector = NULL;
panel->drm = NULL;
 
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 14ac240..26a1b5f 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -89,6 +89,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+   struct device_link *link;
 
const struct drm_panel_funcs *funcs;
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105046

--- Comment #7 from Michael Zapf  ---
Is there at least some way to restore the real monitor resolution without
killing the Xserver (and hence all running desktop applications)?

Right now I either have to reboot, or I must turn off the monitor, then kill
the Xserver (ctrl-alt-bs), then turn on the monitor again. It does not even
suffice to kill the Xserver alone.

-- 
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 hwc RFC] drm_hwcomposer: Enable and refactor Separate Rects test

2018-02-28 Thread Robert Foss

Hey Rhys,

Pushed! Change-ID tag was dropped.


Rob.

On 02/26/2018 07:18 AM, Rhys Kidd wrote:

Plumb through the existing test based on known sample data for the
Separate Rect algorithm via Android's NATIVE_TEST harness.

Change-Id: I82b5ab8ed97e338fd20b7e38b4b35ac8c53f4d2d
Signed-off-by: Rhys Kidd 
---
  separate_rects.cpp|  99 -
  tests/Android.mk  |   2 +
  tests/separate_rects_test.cpp | 100 ++
  3 files changed, 102 insertions(+), 99 deletions(-)
  create mode 100644 tests/separate_rects_test.cpp

diff --git a/separate_rects.cpp b/separate_rects.cpp
index 9fd1ae4..0e74cfc 100644
--- a/separate_rects.cpp
+++ b/separate_rects.cpp
@@ -315,102 +315,3 @@ void separate_rects_64(const std::vector> &in,
  }
  
  }  // namespace separate_rects

-
-#ifdef RECTS_TEST
-
-using namespace separate_rects;
-
-int main(int argc, char **argv) {
-#define RectSet RectSet
-#define Rect Rect
-#define IdSet IdSet
-  typedef uint64_t TId;
-  typedef float TNum;
-
-  std::vector in;
-  std::vector out;
-  std::vector expected_out;
-
-  in.push_back({0, 0, 4, 5});
-  in.push_back({2, 0, 6, 6});
-  in.push_back({4, 0, 8, 5});
-  in.push_back({0, 7, 8, 9});
-
-  in.push_back({10, 0, 18, 5});
-  in.push_back({12, 0, 16, 5});
-
-  in.push_back({20, 11, 24, 17});
-  in.push_back({22, 13, 26, 21});
-  in.push_back({32, 33, 36, 37});
-  in.push_back({30, 31, 38, 39});
-
-  in.push_back({40, 43, 48, 45});
-  in.push_back({44, 41, 46, 47});
-
-  in.push_back({50, 51, 52, 53});
-  in.push_back({50, 51, 52, 53});
-  in.push_back({50, 51, 52, 53});
-
-  in.push_back({0, 0, 0, 10});
-  in.push_back({0, 0, 10, 0});
-  in.push_back({10, 0, 0, 10});
-  in.push_back({0, 10, 10, 0});
-
-  for (int i = 0; i < 10; i++) {
-out.clear();
-separate_rects(in, &out);
-  }
-
-  for (int i = 0; i < out.size(); i++) {
-std::cout << out[i].id_set << "(" << out[i].rect << ")" << std::endl;
-  }
-
-  std::cout << "# of rects: " << out.size() << std::endl;
-
-  expected_out.push_back(RectSet(IdSet(0), Rect(0, 0, 2, 5)));
-  expected_out.push_back(RectSet(IdSet(1), Rect(2, 5, 6, 6)));
-  expected_out.push_back(RectSet(IdSet(1) | 0, Rect(2, 0, 4, 5)));
-  expected_out.push_back(RectSet(IdSet(1) | 2, Rect(4, 0, 6, 5)));
-  expected_out.push_back(RectSet(IdSet(2), Rect(6, 0, 8, 5)));
-  expected_out.push_back(RectSet(IdSet(3), Rect(0, 7, 8, 9)));
-  expected_out.push_back(RectSet(IdSet(4), Rect(10, 0, 12, 5)));
-  expected_out.push_back(RectSet(IdSet(5) | 4, Rect(12, 0, 16, 5)));
-  expected_out.push_back(RectSet(IdSet(4), Rect(16, 0, 18, 5)));
-  expected_out.push_back(RectSet(IdSet(6), Rect(20, 11, 22, 17)));
-  expected_out.push_back(RectSet(IdSet(6) | 7, Rect(22, 13, 24, 17)));
-  expected_out.push_back(RectSet(IdSet(6), Rect(22, 11, 24, 13)));
-  expected_out.push_back(RectSet(IdSet(7), Rect(22, 17, 24, 21)));
-  expected_out.push_back(RectSet(IdSet(7), Rect(24, 13, 26, 21)));
-  expected_out.push_back(RectSet(IdSet(9), Rect(30, 31, 32, 39)));
-  expected_out.push_back(RectSet(IdSet(8) | 9, Rect(32, 33, 36, 37)));
-  expected_out.push_back(RectSet(IdSet(9), Rect(32, 37, 36, 39)));
-  expected_out.push_back(RectSet(IdSet(9), Rect(32, 31, 36, 33)));
-  expected_out.push_back(RectSet(IdSet(9), Rect(36, 31, 38, 39)));
-  expected_out.push_back(RectSet(IdSet(10), Rect(40, 43, 44, 45)));
-  expected_out.push_back(RectSet(IdSet(10) | 11, Rect(44, 43, 46, 45)));
-  expected_out.push_back(RectSet(IdSet(11), Rect(44, 41, 46, 43)));
-  expected_out.push_back(RectSet(IdSet(11), Rect(44, 45, 46, 47)));
-  expected_out.push_back(RectSet(IdSet(10), Rect(46, 43, 48, 45)));
-  expected_out.push_back(RectSet(IdSet(12) | 13 | 14, Rect(50, 51, 52, 53)));
-
-  for (int i = 0; i < expected_out.size(); i++) {
-RectSet &ex_out = expected_out[i];
-if (std::find(out.begin(), out.end(), ex_out) == out.end()) {
-  std::cout << "Missing Rect: " << ex_out.id_set << "(" << ex_out.rect
-<< ")" << std::endl;
-}
-  }
-
-  for (int i = 0; i < out.size(); i++) {
-RectSet &actual_out = out[i];
-if (std::find(expected_out.begin(), expected_out.end(), actual_out) ==
-expected_out.end()) {
-  std::cout << "Extra Rect: " << actual_out.id_set << "(" << 
actual_out.rect
-<< ")" << std::endl;
-}
-  }
-
-  return 0;
-}
-
-#endif
diff --git a/tests/Android.mk b/tests/Android.mk
index 5bbda93..3b9e0a2 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -3,10 +3,12 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  
  LOCAL_SRC_FILES := \

+   separate_rects_test.cpp \
worker_test.cpp
  
  LOCAL_MODULE := hwc-drm-tests

  LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
+LOCAL_SHARED_LIBRARIES := hwcomposer.drm
  LOCAL_C_INCLUDES := external/drm_hwcomposer
  
  include $(BUILD_NATIVE_TEST)

diff --git a/tests/separate_rects_test.cpp b/tests/separate_rects_test.cpp
new file mode 100644
index 000.

[Bug 105262] ttf fonts are invisible

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105262

LoneVVolf  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)

--- Comment #5 from LoneVVolf  ---
Installed gvim to verify, and that has no menus AND shows no text.
It looks like both of us have the same issue, but i have an additonal one: no
text at all in affected programs.

I'm running archlinux x86_64 with xf86-video-ati on an AMD HD 4870.
xorg 1.19.6, kernel 4.15.5

programs without text in menus on my system : 
openbox, lxde, gvim, libreoffice, firefox gtk-filechooser, thunderbird
gtk-filechooser

No issues at all in qt programs like lxqt, kwin, gwenview , okular, calligra .

Could you verify whether qt programs have issues ?

-- 
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 105262] ttf fonts are invisible

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105262

--- Comment #6 from LoneVVolf  ---
It appears most recent commits wrt r600 were written by Dave Airlie.
Added him to CC list

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


[PATCHv2 07/17] drm/omap: dispc: disp_wb_setup to check return code

2018-02-28 Thread Tomi Valkeinen
From: Benoit Parrot 

When dispc_wb_setup() calls dispc_ovl_setup_common() it does not
check for failure but instead keeps on partially setting up WB.
This causes the WB H/W to be partially initialized and yield
unexpected behavior.

Make sure return code is successful before proceeding.

Signed-off-by: Benoit Parrot 
Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index d2d95c76a313..f0f729fc4ca2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2783,6 +2783,8 @@ int dispc_wb_setup(struct dispc_device *dispc,
wi->height, wi->fourcc, wi->rotation, zorder,
wi->pre_mult_alpha, global_alpha, wi->rotation_type,
replication, vm, mem_to_mem);
+   if (r)
+   return r;
 
switch (wi->fourcc) {
case DRM_FORMAT_RGB565:
@@ -2823,7 +2825,7 @@ int dispc_wb_setup(struct dispc_device *dispc,
REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
}
 
-   return r;
+   return 0;
 }
 
 static int dispc_ovl_enable(struct dispc_device *dispc,
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 05/17] dt-bindings: display: add HPD gpio to DVI connector

2018-02-28 Thread Tomi Valkeinen
Add hpd-gpios property to dvi-connector.txt.

Signed-off-by: Tomi Valkeinen 
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
---
 Documentation/devicetree/bindings/display/connector/dvi-connector.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt 
b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt
index fc53f7c60bc6..207e42e9eba0 100644
--- a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt
+++ b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt
@@ -10,6 +10,7 @@ Optional properties:
 - analog: the connector has DVI analog pins
 - digital: the connector has DVI digital pins
 - dual-link: the connector has pins for DVI dual-link
+- hpd-gpios: HPD GPIO number
 
 Required nodes:
 - Video port for DVI input
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 06/17] drm/omap: remove leftover enums

2018-02-28 Thread Tomi Valkeinen
A few enums are not used anywhere, so remove them.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index a4f71e082c1c..162f36fa3431 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -163,21 +163,6 @@ enum omap_overlay_caps {
OMAP_DSS_OVL_CAP_REPLICATION = 1 << 5,
 };
 
-enum omap_dss_clk_source {
-   OMAP_DSS_CLK_SRC_FCK = 0,   /* OMAP2/3: DSS1_ALWON_FCLK
-* OMAP4: DSS_FCLK */
-   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,   /* OMAP3: DSI1_PLL_FCLK
-* OMAP4: PLL1_CLK1 */
-   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI, /* OMAP3: DSI2_PLL_FCLK
-* OMAP4: PLL1_CLK2 */
-   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC,  /* OMAP4: PLL2_CLK1 */
-   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI,/* OMAP4: PLL2_CLK2 */
-};
-
-enum omap_hdmi_flags {
-   OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 << 0,
-};
-
 enum omap_dss_output_id {
OMAP_DSS_OUTPUT_DPI = 1 << 0,
OMAP_DSS_OUTPUT_DBI = 1 << 1,
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 03/17] drm/omap: Init fbdev emulation only when we have displays

2018-02-28 Thread Tomi Valkeinen
From: Peter Ujfalusi 

Do not try to init the fbdev if either num_crtcs or num_connectors is 0.
In this case we do not have display so the fbdev init would fail anyways.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index be94480326d7..0f66c74a54b0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -249,6 +249,9 @@ void omap_fbdev_init(struct drm_device *dev)
struct drm_fb_helper *helper;
int ret = 0;
 
+   if (!priv->num_crtcs || !priv->num_connectors)
+   return;
+
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
goto fail;
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 09/17] drm/omap: set WB channel-in in wb_setup()

2018-02-28 Thread Tomi Valkeinen
We need to know the WB channel-in in wb_setup() to be able to configure
WB properly for capture mode. At the moment channel-in is set
separately.

This patch moves channel-in to wb_setup().

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 12 +++-
 drivers/gpu/drm/omapdrm/dss/dss.h   |  3 ++-
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 3ad56b30c90a..ccfafce1ea89 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -1234,14 +1234,6 @@ static enum omap_channel 
dispc_ovl_get_channel_out(struct dispc_device *dispc,
}
 }
 
-void dispc_wb_set_channel_in(struct dispc_device *dispc,
-enum dss_writeback_channel channel)
-{
-   enum omap_plane_id plane = OMAP_DSS_WB;
-
-   REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), channel, 18, 16);
-}
-
 static void dispc_ovl_set_burst_size(struct dispc_device *dispc,
 enum omap_plane_id plane,
 enum omap_burst_size burst_size)
@@ -2764,7 +2756,8 @@ static int dispc_ovl_setup(struct dispc_device *dispc,
 
 int dispc_wb_setup(struct dispc_device *dispc,
   const struct omap_dss_writeback_info *wi,
-  bool mem_to_mem, const struct videomode *vm)
+  bool mem_to_mem, const struct videomode *vm,
+  enum dss_writeback_channel channel_in)
 {
int r;
u32 l;
@@ -2809,6 +2802,7 @@ int dispc_wb_setup(struct dispc_device *dispc,
/* setup extra DISPC_WB_ATTRIBUTES */
l = dispc_read_reg(dispc, DISPC_OVL_ATTRIBUTES(plane));
l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
+   l = FLD_MOD(l, channel_in, 18, 16); /* CHANNELIN */
l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
if (mem_to_mem)
l = FLD_MOD(l, 1, 26, 24);  /* CAPTUREMODE */
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 6f6fd3d1b159..c56c3c59bf18 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -455,7 +455,8 @@ void dispc_wb_set_channel_in(struct dispc_device *dispc,
 enum dss_writeback_channel channel);
 int dispc_wb_setup(struct dispc_device *dispc,
   const struct omap_dss_writeback_info *wi,
-  bool mem_to_mem, const struct videomode *vm);
+  bool mem_to_mem, const struct videomode *vm,
+  enum dss_writeback_channel channel_in);
 
 #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
 static inline void dss_collect_irq_stats(u32 irqstatus, unsigned int *irq_arr)
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 02/17] drm/omap: cleanup fbdev init/free

2018-02-28 Thread Tomi Valkeinen
omap_fbdev_init() and omap_fbdev_free() use priv->fbdev directly.
However, omap_fbdev_init() returns the fbdev, and omap_drv.c also
assigns the return value to priv->fbdev. This is slightly confusing.

Clean this up by removing the omap_fbdev_init() return value, as we
don't care whether fbdev init succeeded or not. Also change omap_drv.c
to call omap_fbdev_free() always, and omap_fbdev_free() does the check
if fbdev was initialized.

While at it, rename omap_fbdev_free() to omap_fbdev_fini() to better
match the "init" counterpart.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   |  9 -
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 18 --
 drivers/gpu/drm/omapdrm/omap_fbdev.h |  9 -
 3 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 65a567dcf3ab..4f48b908bdc6 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -570,7 +570,7 @@ static int omapdrm_init(struct omap_drm_private *priv, 
struct device *dev)
for (i = 0; i < priv->num_crtcs; i++)
drm_crtc_vblank_off(priv->crtcs[i]);
 
-   priv->fbdev = omap_fbdev_init(ddev);
+   omap_fbdev_init(ddev);
 
drm_kms_helper_poll_init(ddev);
omap_modeset_enable_external_hpd();
@@ -588,8 +588,8 @@ static int omapdrm_init(struct omap_drm_private *priv, 
struct device *dev)
 err_cleanup_helpers:
omap_modeset_disable_external_hpd();
drm_kms_helper_poll_fini(ddev);
-   if (priv->fbdev)
-   omap_fbdev_free(ddev);
+
+   omap_fbdev_fini(ddev);
 err_cleanup_modeset:
drm_mode_config_cleanup(ddev);
omap_drm_irq_uninstall(ddev);
@@ -615,8 +615,7 @@ static void omapdrm_cleanup(struct omap_drm_private *priv)
omap_modeset_disable_external_hpd();
drm_kms_helper_poll_fini(ddev);
 
-   if (priv->fbdev)
-   omap_fbdev_free(ddev);
+   omap_fbdev_fini(ddev);
 
drm_atomic_helper_shutdown(ddev);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 632ebcf2165f..be94480326d7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -242,7 +242,7 @@ static struct drm_fb_helper *get_fb(struct fb_info *fbi)
 }
 
 /* initialize fbdev helper */
-struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
+void omap_fbdev_init(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev->dev_private;
struct omap_fbdev *fbdev = NULL;
@@ -260,10 +260,8 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
drm_fb_helper_prepare(dev, helper, &omap_fb_helper_funcs);
 
ret = drm_fb_helper_init(dev, helper, priv->num_connectors);
-   if (ret) {
-   dev_err(dev->dev, "could not init fbdev: ret=%d\n", ret);
+   if (ret)
goto fail;
-   }
 
ret = drm_fb_helper_single_add_all_connectors(helper);
if (ret)
@@ -275,7 +273,7 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
 
priv->fbdev = helper;
 
-   return helper;
+   return;
 
 fini:
drm_fb_helper_fini(helper);
@@ -283,12 +281,9 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
kfree(fbdev);
 
dev_warn(dev->dev, "omap_fbdev_init failed\n");
-   /* well, limp along without an fbdev.. maybe X11 will work? */
-
-   return NULL;
 }
 
-void omap_fbdev_free(struct drm_device *dev)
+void omap_fbdev_fini(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev->dev_private;
struct drm_fb_helper *helper = priv->fbdev;
@@ -296,11 +291,14 @@ void omap_fbdev_free(struct drm_device *dev)
 
DBG();
 
+   if (!helper)
+   return;
+
drm_fb_helper_unregister_fbi(helper);
 
drm_fb_helper_fini(helper);
 
-   fbdev = to_omap_fbdev(priv->fbdev);
+   fbdev = to_omap_fbdev(helper);
 
/* unpin the GEM object pinned in omap_fbdev_create() */
if (fbdev->bo)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.h 
b/drivers/gpu/drm/omapdrm/omap_fbdev.h
index 1f5ba0996a1a..7dfd843f73f1 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.h
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.h
@@ -24,14 +24,13 @@ struct drm_device;
 struct drm_fb_helper;
 
 #ifdef CONFIG_DRM_FBDEV_EMULATION
-struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev);
-void omap_fbdev_free(struct drm_device *dev);
+void omap_fbdev_init(struct drm_device *dev);
+void omap_fbdev_fini(struct drm_device *dev);
 #else
-static inline struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
+static inline void omap_fbdev_init(struct drm_device *dev)
 {
-   return NULL;
 }
-static inline void omap_fbdev_free(struct drm_device *dev)
+static inline void omap_fbdev_fini(struct drm_device *dev)
 {
 }
 #endif
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00

[PATCHv2 01/17] drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called

2018-02-28 Thread Tomi Valkeinen
If we have no crtcs/connectors, fbdev init goes fine, but
omap_fbdev_create() is never called. This means that omap_fbdev->bo is
NULL and omap_fbdev_free() crashes.

Add a check to omap_fbdev_free() to handle the NULL case.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 1ace63e2ff22..632ebcf2165f 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -303,7 +303,8 @@ void omap_fbdev_free(struct drm_device *dev)
fbdev = to_omap_fbdev(priv->fbdev);
 
/* unpin the GEM object pinned in omap_fbdev_create() */
-   omap_gem_unpin(fbdev->bo);
+   if (fbdev->bo)
+   omap_gem_unpin(fbdev->bo);
 
/* this will free the backing object */
if (fbdev->fb)
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 04/17] drm/omap: add HPD support to connector-dvi

2018-02-28 Thread Tomi Valkeinen
Add HPD support to the DVI connector driver. The code is almost
identical to the HPD code in the HDMI connector driver.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 118 +++
 1 file changed, 118 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 391d80364346..6d8cbd9e2110 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -9,6 +9,7 @@
  * the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -44,6 +45,14 @@ struct panel_drv_data {
struct videomode vm;
 
struct i2c_adapter *i2c_adapter;
+
+   struct gpio_desc *hpd_gpio;
+
+   void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
+   void *hpd_cb_data;
+   bool hpd_enabled;
+   /* mutex for hpd fields above */
+   struct mutex hpd_lock;
 };
 
 #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -189,6 +198,9 @@ static int dvic_read_edid(struct omap_dss_device *dssdev,
struct panel_drv_data *ddata = to_panel_data(dssdev);
int r, l, bytes_read;
 
+   if (ddata->hpd_gpio && !gpiod_get_value_cansleep(ddata->hpd_gpio))
+   return -ENODEV;
+
if (!ddata->i2c_adapter)
return -ENODEV;
 
@@ -220,6 +232,9 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
unsigned char out;
int r;
 
+   if (ddata->hpd_gpio)
+   return gpiod_get_value_cansleep(ddata->hpd_gpio);
+
if (!ddata->i2c_adapter)
return true;
 
@@ -228,6 +243,60 @@ static bool dvic_detect(struct omap_dss_device *dssdev)
return r == 0;
 }
 
+static int dvic_register_hpd_cb(struct omap_dss_device *dssdev,
+void (*cb)(void *cb_data,
+   enum drm_connector_status status),
+void *cb_data)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   if (!ddata->hpd_gpio)
+   return -ENOTSUPP;
+
+   mutex_lock(&ddata->hpd_lock);
+   ddata->hpd_cb = cb;
+   ddata->hpd_cb_data = cb_data;
+   mutex_unlock(&ddata->hpd_lock);
+   return 0;
+}
+
+static void dvic_unregister_hpd_cb(struct omap_dss_device *dssdev)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   if (!ddata->hpd_gpio)
+   return;
+
+   mutex_lock(&ddata->hpd_lock);
+   ddata->hpd_cb = NULL;
+   ddata->hpd_cb_data = NULL;
+   mutex_unlock(&ddata->hpd_lock);
+}
+
+static void dvic_enable_hpd(struct omap_dss_device *dssdev)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   if (!ddata->hpd_gpio)
+   return;
+
+   mutex_lock(&ddata->hpd_lock);
+   ddata->hpd_enabled = true;
+   mutex_unlock(&ddata->hpd_lock);
+}
+
+static void dvic_disable_hpd(struct omap_dss_device *dssdev)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   if (!ddata->hpd_gpio)
+   return;
+
+   mutex_lock(&ddata->hpd_lock);
+   ddata->hpd_enabled = false;
+   mutex_unlock(&ddata->hpd_lock);
+}
+
 static struct omap_dss_driver dvic_driver = {
.connect= dvic_connect,
.disconnect = dvic_disconnect,
@@ -241,14 +310,60 @@ static struct omap_dss_driver dvic_driver = {
 
.read_edid  = dvic_read_edid,
.detect = dvic_detect,
+
+   .register_hpd_cb= dvic_register_hpd_cb,
+   .unregister_hpd_cb  = dvic_unregister_hpd_cb,
+   .enable_hpd = dvic_enable_hpd,
+   .disable_hpd= dvic_disable_hpd,
 };
 
+static irqreturn_t dvic_hpd_isr(int irq, void *data)
+{
+   struct panel_drv_data *ddata = data;
+
+   mutex_lock(&ddata->hpd_lock);
+   if (ddata->hpd_enabled && ddata->hpd_cb) {
+   enum drm_connector_status status;
+
+   if (dvic_detect(&ddata->dssdev))
+   status = connector_status_connected;
+   else
+   status = connector_status_disconnected;
+
+   ddata->hpd_cb(ddata->hpd_cb_data, status);
+   }
+   mutex_unlock(&ddata->hpd_lock);
+
+   return IRQ_HANDLED;
+}
+
 static int dvic_probe_of(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
struct device_node *adapter_node;
struct i2c_adapter *adapter;
+   struct gpio_desc *gpio;
+   int r;
+
+   gpio = devm_gpiod_get_optional(&pdev->dev, "hpd", GPIOD_IN);
+   if (IS_ERR(gpio)) {
+   dev_err(&pdev->dev, "failed to parse HPD gpio\n");
+   return PTR_ERR(gpio);
+   }
+
+   ddata->hpd_gpio = gpio;
+
+   mutex_init(&ddata->hpd_lock);
+
+   if (

[PATCHv2 08/17] drm/omap: Add pclk setting case when channel is DSS_WB

2018-02-28 Thread Tomi Valkeinen
From: Benoit Parrot 

In dispc_set_ovl_common() we need to initialize pclk to a valid
value when we use WB in capture mode (i.e. mem_2_mem is false).
Otherwise dispc_ovl_calc_scaling() fails.

Signed-off-by: Benoit Parrot 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f0f729fc4ca2..3ad56b30c90a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2590,6 +2590,10 @@ static int dispc_ovl_setup_common(struct dispc_device 
*dispc,
unsigned long pclk = dispc_plane_pclk_rate(dispc, plane);
unsigned long lclk = dispc_plane_lclk_rate(dispc, plane);
 
+   /* when setting up WB, dispc_plane_pclk_rate() returns 0 */
+   if (plane == OMAP_DSS_WB)
+   pclk = vm->pixelclock;
+
if (paddr == 0 && rotation_type != OMAP_DSS_ROT_TILER)
return -EINVAL;
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 10/17] drm/omap: fix WBDELAYCOUNT for HDMI

2018-02-28 Thread Tomi Valkeinen
For HDMI, WBDELAYCOUNT starts counting at the start of vsync, not at the
start of vfp.

This patch adjusts the wbdelay for HDMI accordingly.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index ccfafce1ea89..7398039954a5 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2816,8 +2816,12 @@ int dispc_wb_setup(struct dispc_device *dispc,
} else {
int wbdelay;
 
-   wbdelay = min(vm->vfront_porch +
- vm->vsync_len + vm->vback_porch, (u32)255);
+   if (channel_in == DSS_WB_TV_MGR)
+   wbdelay = min(vm->vsync_len + vm->vback_porch,
+   (u32)255);
+   else
+   wbdelay = min(vm->vfront_porch +
+   vm->vsync_len + vm->vback_porch, (u32)255);
 
/* WBDELAYCOUNT */
REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 00/17] drm/omap: misc patches

2018-02-28 Thread Tomi Valkeinen
Hi,

This is v2 of the series.

I've rebased these on top of Laurent's latest patches. I also dropped most of
Peter's patches, as they need rebasing and some work. I think I addressed all
of Laurent's comments to the patches in this v2.

 Tomi

Benoit Parrot (2):
  drm/omap: dispc: disp_wb_setup to check return code
  drm/omap: Add pclk setting case when channel is DSS_WB

Jyri Sarha (1):
  drm/omap: Allow HDMI audio setup even if we do not have video
configured

Peter Ujfalusi (1):
  drm/omap: Init fbdev emulation only when we have displays

Tomi Valkeinen (13):
  drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called
  drm/omap: cleanup fbdev init/free
  drm/omap: add HPD support to connector-dvi
  dt-bindings: display: add HPD gpio to DVI connector
  drm/omap: remove leftover enums
  drm/omap: set WB channel-in in wb_setup()
  drm/omap: fix WBDELAYCOUNT for HDMI
  drm/omap: fix WBDELAYCOUNT with interlace
  drm/omap: fix WB height with interlace
  drm/omap: fix scaling limits for WB
  drm/omap: add writeback funcs to dispc_ops
  drm/omap: fix maximum sizes
  drm/omap: cleanup color space conversion

 .../bindings/display/connector/dvi-connector.txt   |   1 +
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   | 118 +++
 drivers/gpu/drm/omapdrm/dss/dispc.c| 160 +++--
 drivers/gpu/drm/omapdrm/dss/dss.h  |  20 ---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  33 ++---
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  37 +++--
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  35 +++--
 drivers/gpu/drm/omapdrm/omap_drv.c |  20 +--
 drivers/gpu/drm/omapdrm/omap_fbdev.c   |  24 ++--
 drivers/gpu/drm/omapdrm/omap_fbdev.h   |   9 +-
 10 files changed, 311 insertions(+), 146 deletions(-)

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 12/17] drm/omap: fix WB height with interlace

2018-02-28 Thread Tomi Valkeinen
When using WB capture from interlaced source, we need to halve the
picture heights correctly.

Unfortunately the current dispc_ovl_setup_common() doesn't deal with
interlace very neatly, so the end result is a bit messy.

Signed-off-by: Tomi Valkeinen 
Acked-by: Benoit Parrot 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 000a3d4a27bf..72f00e8a1329 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2597,18 +2597,19 @@ static int dispc_ovl_setup_common(struct dispc_device 
*dispc,
out_width = out_width == 0 ? width : out_width;
out_height = out_height == 0 ? height : out_height;
 
-   if (ilace && height == out_height)
-   fieldmode = true;
-
-   if (ilace) {
-   if (fieldmode)
-   in_height /= 2;
-   pos_y /= 2;
-   out_height /= 2;
-
-   DSSDBG("adjusting for ilace: height %d, pos_y %d, "
-   "out_height %d\n", in_height, pos_y,
-   out_height);
+   if (plane != OMAP_DSS_WB) {
+   if (ilace && height == out_height)
+   fieldmode = true;
+
+   if (ilace) {
+   if (fieldmode)
+   in_height /= 2;
+   pos_y /= 2;
+   out_height /= 2;
+
+   DSSDBG("adjusting for ilace: height %d, pos_y %d, 
out_height %d\n",
+   in_height, pos_y, out_height);
+   }
}
 
if (!dispc_ovl_color_mode_supported(dispc, plane, fourcc))
@@ -2771,6 +2772,9 @@ int dispc_wb_setup(struct dispc_device *dispc,
enum omap_overlay_caps caps =
OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
 
+   if (vm->flags & DISPLAY_FLAGS_INTERLACED)
+   in_height /= 2;
+
DSSDBG("dispc_wb_setup, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
"rot %d\n", wi->paddr, wi->p_uv_addr, in_width,
in_height, wi->width, wi->height, wi->fourcc, wi->rotation);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 11/17] drm/omap: fix WBDELAYCOUNT with interlace

2018-02-28 Thread Tomi Valkeinen
Vertical blanking needs to be halved on interlace modes. WBDELAYCOUNT
was calculated without such halving, resulting in WBUNCOMPLETE errors.

Signed-off-by: Tomi Valkeinen 
Acked-by: Benoit Parrot 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 7398039954a5..000a3d4a27bf 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2814,14 +2814,18 @@ int dispc_wb_setup(struct dispc_device *dispc,
/* WBDELAYCOUNT */
REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES2(plane), 0, 7, 0);
} else {
-   int wbdelay;
+   u32 wbdelay;
 
if (channel_in == DSS_WB_TV_MGR)
-   wbdelay = min(vm->vsync_len + vm->vback_porch,
-   (u32)255);
+   wbdelay = vm->vsync_len + vm->vback_porch;
else
-   wbdelay = min(vm->vfront_porch +
-   vm->vsync_len + vm->vback_porch, (u32)255);
+   wbdelay = vm->vfront_porch + vm->vsync_len +
+   vm->vback_porch;
+
+   if (vm->flags & DISPLAY_FLAGS_INTERLACED)
+   wbdelay /= 2;
+
+   wbdelay = min(wbdelay, 255u);
 
/* WBDELAYCOUNT */
REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 14/17] drm/omap: add writeback funcs to dispc_ops

2018-02-28 Thread Tomi Valkeinen
Add writeback specific dispc functions to dispc_ops so that omapdrm can
use them.  Also move 'enum dss_writeback_channel' to the public
omapdss.h for omapdrm.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 19 +++
 drivers/gpu/drm/omapdrm/dss/dss.h | 21 -
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 20 
 3 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 2aa72845f819..57960df1517a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -715,7 +715,7 @@ static u32 dispc_mgr_get_sync_lost_irq(struct dispc_device 
*dispc,
return mgr_desc[channel].sync_lost_irq;
 }
 
-u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc)
+static u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc)
 {
return DISPC_IRQ_FRAMEDONEWB;
 }
@@ -750,12 +750,12 @@ static void dispc_mgr_go(struct dispc_device *dispc, enum 
omap_channel channel)
mgr_fld_write(dispc, channel, DISPC_MGR_FLD_GO, 1);
 }
 
-bool dispc_wb_go_busy(struct dispc_device *dispc)
+static bool dispc_wb_go_busy(struct dispc_device *dispc)
 {
return REG_GET(dispc, DISPC_CONTROL2, 6, 6) == 1;
 }
 
-void dispc_wb_go(struct dispc_device *dispc)
+static void dispc_wb_go(struct dispc_device *dispc)
 {
enum omap_plane_id plane = OMAP_DSS_WB;
bool enable, go;
@@ -2771,7 +2771,7 @@ static int dispc_ovl_setup(struct dispc_device *dispc,
return r;
 }
 
-int dispc_wb_setup(struct dispc_device *dispc,
+static int dispc_wb_setup(struct dispc_device *dispc,
   const struct omap_dss_writeback_info *wi,
   bool mem_to_mem, const struct videomode *vm,
   enum dss_writeback_channel channel_in)
@@ -2854,6 +2854,11 @@ int dispc_wb_setup(struct dispc_device *dispc,
return 0;
 }
 
+static bool dispc_has_writeback(struct dispc_device *dispc)
+{
+   return dispc->feat->has_writeback;
+}
+
 static int dispc_ovl_enable(struct dispc_device *dispc,
enum omap_plane_id plane, bool enable)
 {
@@ -4709,6 +4714,12 @@ static const struct dispc_ops dispc_ops = {
.ovl_enable = dispc_ovl_enable,
.ovl_setup = dispc_ovl_setup,
.ovl_get_color_modes = dispc_ovl_get_color_modes,
+
+   .wb_get_framedone_irq = dispc_wb_get_framedone_irq,
+   .wb_setup = dispc_wb_setup,
+   .has_writeback = dispc_has_writeback,
+   .wb_go_busy = dispc_wb_go_busy,
+   .wb_go = dispc_wb_go,
 };
 
 /* DISPC HW IP initialisation */
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index c56c3c59bf18..c601ed9a09c2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -102,17 +102,6 @@ enum dss_dsi_content_type {
DSS_DSI_CONTENT_GENERIC,
 };
 
-enum dss_writeback_channel {
-   DSS_WB_LCD1_MGR =   0,
-   DSS_WB_LCD2_MGR =   1,
-   DSS_WB_TV_MGR = 2,
-   DSS_WB_OVL0 =   3,
-   DSS_WB_OVL1 =   4,
-   DSS_WB_OVL2 =   5,
-   DSS_WB_OVL3 =   6,
-   DSS_WB_LCD3_MGR =   7,
-};
-
 enum dss_clk_source {
DSS_CLK_SRC_FCK = 0,
 
@@ -448,16 +437,6 @@ int dispc_mgr_get_clock_div(struct dispc_device *dispc,
struct dispc_clock_info *cinfo);
 void dispc_set_tv_pclk(struct dispc_device *dispc, unsigned long pclk);
 
-u32 dispc_wb_get_framedone_irq(struct dispc_device *dispc);
-bool dispc_wb_go_busy(struct dispc_device *dispc);
-void dispc_wb_go(struct dispc_device *dispc);
-void dispc_wb_set_channel_in(struct dispc_device *dispc,
-enum dss_writeback_channel channel);
-int dispc_wb_setup(struct dispc_device *dispc,
-  const struct omap_dss_writeback_info *wi,
-  bool mem_to_mem, const struct videomode *vm,
-  enum dss_writeback_channel channel_in);
-
 #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
 static inline void dss_collect_irq_stats(u32 irqstatus, unsigned int *irq_arr)
 {
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 162f36fa3431..14d74adb13fb 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -626,6 +626,17 @@ omapdss_of_find_source_for_first_ep(struct device_node 
*node);
 struct device_node *dss_of_port_get_parent_device(struct device_node *port);
 u32 dss_of_port_get_port_number(struct device_node *port);
 
+enum dss_writeback_channel {
+   DSS_WB_LCD1_MGR =   0,
+   DSS_WB_LCD2_MGR =   1,
+   DSS_WB_TV_MGR = 2,
+   DSS_WB_OVL0 =   3,
+   DSS_WB_OVL1 =   4,
+   DSS_WB_OVL2 =   5,
+   DSS_WB_OVL3 =   6,
+   DSS_WB_LCD3_MGR =   7,
+};
+
 struct dss_mgr_ops {
int (*connect)(struct omap_dr

[PATCHv2 16/17] drm/omap: Allow HDMI audio setup even if we do not have video configured

2018-02-28 Thread Tomi Valkeinen
From: Jyri Sarha 

Allow HDMI audio setup even if we do not have video configured. Audio
will get configured at the same time with video if the video is
configured soon enough. If it is not the audio DMA will timeout in
couple of seconds and audio playback will be aborted.

Signed-off-by: Jyri Sarha 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 33 ++---
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 37 -
 2 files changed, 30 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 1f7897c58f2f..97c88861d67a 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -615,21 +615,16 @@ static int hdmi_audio_startup(struct device *dev,
  void (*abort_cb)(struct device *dev))
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret = 0;
 
mutex_lock(&hd->lock);
 
-   if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
-   }
+   WARN_ON(hd->audio_abort_cb != NULL);
 
hd->audio_abort_cb = abort_cb;
 
-out:
mutex_unlock(&hd->lock);
 
-   return ret;
+   return 0;
 }
 
 static int hdmi_audio_shutdown(struct device *dev)
@@ -650,12 +645,14 @@ static int hdmi_audio_start(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(&hd->cfg));
-
spin_lock_irqsave(&hd->audio_playing_lock, flags);
 
-   if (hd->display_enabled)
+   if (hd->display_enabled) {
+   if (!hdmi_mode_has_audio(&hd->cfg))
+   DSSERR("%s: Video mode does not support audio\n",
+  __func__);
hdmi_start_audio_stream(hd);
+   }
hd->audio_playing = true;
 
spin_unlock_irqrestore(&hd->audio_playing_lock, flags);
@@ -686,17 +683,15 @@ static int hdmi_audio_config(struct device *dev,
 
mutex_lock(&hd->lock);
 
-   if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
+   if (hd->display_enabled) {
+   ret = hdmi4_audio_config(&hd->core, &hd->wp, dss_audio,
+hd->cfg.vm.pixelclock);
+   if (ret)
+   goto out;
}
 
-   ret = hdmi4_audio_config(&hd->core, &hd->wp, dss_audio,
-hd->cfg.vm.pixelclock);
-   if (!ret) {
-   hd->audio_configured = true;
-   hd->audio_config = *dss_audio;
-   }
+   hd->audio_configured = true;
+   hd->audio_config = *dss_audio;
 out:
mutex_unlock(&hd->lock);
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 4a0178ab8016..d28da9ac3e90 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -606,21 +606,16 @@ static int hdmi_audio_startup(struct device *dev,
  void (*abort_cb)(struct device *dev))
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret = 0;
 
mutex_lock(&hd->lock);
 
-   if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
-   }
+   WARN_ON(hd->audio_abort_cb != NULL);
 
hd->audio_abort_cb = abort_cb;
 
-out:
mutex_unlock(&hd->lock);
 
-   return ret;
+   return 0;
 }
 
 static int hdmi_audio_shutdown(struct device *dev)
@@ -641,12 +636,14 @@ static int hdmi_audio_start(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(&hd->cfg));
-
spin_lock_irqsave(&hd->audio_playing_lock, flags);
 
-   if (hd->display_enabled)
+   if (hd->display_enabled) {
+   if (!hdmi_mode_has_audio(&hd->cfg))
+   DSSERR("%s: Video mode does not support audio\n",
+  __func__);
hdmi_start_audio_stream(hd);
+   }
hd->audio_playing = true;
 
spin_unlock_irqrestore(&hd->audio_playing_lock, flags);
@@ -658,7 +655,8 @@ static void hdmi_audio_stop(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(&hd->cfg));
+   if (!hdmi_mode_has_audio(&hd->cfg))
+   DSSERR("%s: Video mode does not support audio\n", __func__);
 
spin_lock_irqsave(&hd->audio_playing_lock, flags);
 
@@ -677,18 +675,15 @@ static int hdmi_audio_config(struct device *dev,
 
mutex_lock(&hd->lock);
 
-   if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
+   if (hd->display_enabled) {
+   

[PATCHv2 15/17] drm/omap: fix maximum sizes

2018-02-28 Thread Tomi Valkeinen
We define max width and height in mode_config to 2048. These maximums
affect many things, which are independent and depend on platform. We
need to do more fine grained checks in the code paths for each
component, and so the maximum values in mode_config should just be "big
enough" to cover all use cases.

Change the maximum width & height to 8192.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 4f48b908bdc6..3632854c2b91 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -310,11 +310,14 @@ static int omap_modeset_init(struct drm_device *dev)
dev->mode_config.min_width = 8;
dev->mode_config.min_height = 2;
 
-   /* note: eventually will need some cpu_is_omapXYZ() type stuff here
-* to fill in these limits properly on different OMAP generations..
+   /*
+* Note: these values are used for multiple independent things:
+* connector mode filtering, buffer sizes, crtc sizes...
+* Use big enough values here to cover all use cases, and do more
+* specific checking in the respective code paths.
 */
-   dev->mode_config.max_width = 2048;
-   dev->mode_config.max_height = 2048;
+   dev->mode_config.max_width = 8192;
+   dev->mode_config.max_height = 8192;
 
dev->mode_config.funcs = &omap_mode_config_funcs;
dev->mode_config.helper_private = &omap_mode_config_helper_funcs;
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCHv2 17/17] drm/omap: cleanup color space conversion

2018-02-28 Thread Tomi Valkeinen
The setup code for color space conversion is a bit messy. This patch
cleans it up.

For some reason the TRM uses values in YCrCb order, which is also used
in the current driver, whereas everywhere else it's YCbCr (which also
matches YUV order). This patch changes the tables to use the common
order to avoid confusion.

The tables are split into separate lines, and comments added for
clarity.

WB color conversion registers are similar but different than non-WB, but
the same function was used to write both. It worked fine because the
coef table was adjusted accordingly, but that was rather confusing. This
patch adds a separate function to write the WB values so that the coef
table can be written in an understandable way.

Recalculation also showed that 'bcb' value in yuv-to-rgb conversion had
been rounded wrongly, and it should be 516 instead of 517.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 59 +++--
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 57960df1517a..f688f09b4eae 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -352,11 +352,6 @@ static const struct {
},
 };
 
-struct color_conv_coef {
-   int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
-   int full_range;
-};
-
 static unsigned long dispc_fclk_rate(struct dispc_device *dispc);
 static unsigned long dispc_core_clk_rate(struct dispc_device *dispc);
 static unsigned long dispc_mgr_lclk_rate(struct dispc_device *dispc,
@@ -868,10 +863,19 @@ static void dispc_ovl_set_scale_coef(struct dispc_device 
*dispc,
}
 }
 
+struct csc_coef_yuv2rgb {
+   int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
+   bool full_range;
+};
+
+struct csc_coef_rgb2yuv {
+   int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
+   bool full_range;
+};
 
 static void dispc_ovl_write_color_conv_coef(struct dispc_device *dispc,
enum omap_plane_id plane,
-   const struct color_conv_coef *ct)
+   const struct csc_coef_yuv2rgb *ct)
 {
 #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
 
@@ -886,25 +890,50 @@ static void dispc_ovl_write_color_conv_coef(struct 
dispc_device *dispc,
 #undef CVAL
 }
 
+static void dispc_wb_write_color_conv_coef(struct dispc_device *dispc,
+  const struct csc_coef_rgb2yuv *ct)
+{
+   const enum omap_plane_id plane = OMAP_DSS_WB;
+
+#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+
+   dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,  
ct->yr));
+   dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, 
ct->yb));
+   dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, 
ct->crg));
+   dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, 
ct->cbr));
+   dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
+
+   REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 
11);
+
+#undef CVAL
+}
+
 static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
 {
int i;
int num_ovl = dispc_get_num_ovls(dispc);
-   const struct color_conv_coef ctbl_bt601_5_ovl = {
-   /* YUV -> RGB */
-   298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
+
+   /* YUV -> RGB, ITU-R BT.601, limited range */
+   const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+   298,0,  409,/* ry, rcb, rcr */
+   298, -100, -208,/* gy, gcb, gcr */
+   298,  516,0,/* by, bcb, bcr */
+   false,  /* limited range */
};
-   const struct color_conv_coef ctbl_bt601_5_wb = {
-   /* RGB -> YUV */
-   66, 129, 25, 112, -94, -18, -38, -74, 112, 0,
+
+   /* RGB -> YUV, ITU-R BT.601, limited range */
+   const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
+66, 129,  25,  /* yr,   yg,  yb */
+   -38, -74, 112,  /* cbr, cbg, cbb */
+   112, -94, -18,  /* crr, crg, crb */
+   false,  /* limited range */
};
 
for (i = 1; i < num_ovl; i++)
-   dispc_ovl_write_color_conv_coef(dispc, i, &ctbl_bt601_5_ovl);
+   dispc_ovl_write_color_conv_coef(dispc, i, 
&coefs_yuv2rgb_bt601_lim);
 
if (dispc->feat->has_writeback)
-   dispc_ovl_write_color_conv_coef(dispc, OMAP_DSS_WB,
-   &ctbl_bt601_5_wb);
+   dispc_wb_write_color_conv_coef(dispc, &coefs_rgb2yuv_bt601_lim);
 }
 
 static void dispc_ovl_set_ba0(struct dispc_device *dispc,
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 0018

[PATCHv2 13/17] drm/omap: fix scaling limits for WB

2018-02-28 Thread Tomi Valkeinen
WB has additional scaling limits when the output color format is one of
the YUV formats. These limits are not handled at the moment, causing
bad scaling and/or NULL dereference crash.

This patchs adds the check so that dispc returns an error for bad
scaling request.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 72f00e8a1329..2aa72845f819 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2475,6 +2475,7 @@ static int dispc_ovl_calc_scaling_44xx(struct 
dispc_device *dispc,
((dividend) * 100 / (divisor) - ((dividend) / (divisor) * 100))
 
 static int dispc_ovl_calc_scaling(struct dispc_device *dispc,
+ enum omap_plane_id plane,
  unsigned long pclk, unsigned long lclk,
  enum omap_overlay_caps caps,
  const struct videomode *vm,
@@ -2485,7 +2486,8 @@ static int dispc_ovl_calc_scaling(struct dispc_device 
*dispc,
  enum omap_dss_rotation_type rotation_type,
  bool mem_to_mem)
 {
-   const int maxdownscale = dispc->feat->max_downscale;
+   int maxhdownscale = dispc->feat->max_downscale;
+   int maxvdownscale = dispc->feat->max_downscale;
const int max_decim_limit = 16;
unsigned long core_clk = 0;
int decim_x, decim_y, ret;
@@ -2493,6 +2495,20 @@ static int dispc_ovl_calc_scaling(struct dispc_device 
*dispc,
if (width == out_width && height == out_height)
return 0;
 
+   if (plane == OMAP_DSS_WB) {
+   switch (fourcc) {
+   case DRM_FORMAT_NV12:
+   maxhdownscale = maxvdownscale = 2;
+   break;
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_UYVY:
+   maxhdownscale = 2;
+   maxvdownscale = 4;
+   break;
+   default:
+   break;
+   }
+   }
if (!mem_to_mem && (pclk == 0 || vm->pixelclock == 0)) {
DSSERR("cannot calculate scaling settings: pclk is zero\n");
return -EINVAL;
@@ -2510,8 +2526,8 @@ static int dispc_ovl_calc_scaling(struct dispc_device 
*dispc,
2 : max_decim_limit;
}
 
-   decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxdownscale);
-   decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxdownscale);
+   decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxhdownscale);
+   decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxvdownscale);
 
if (decim_x > *x_predecim || out_width > width * 8)
return -EINVAL;
@@ -2615,7 +2631,7 @@ static int dispc_ovl_setup_common(struct dispc_device 
*dispc,
if (!dispc_ovl_color_mode_supported(dispc, plane, fourcc))
return -EINVAL;
 
-   r = dispc_ovl_calc_scaling(dispc, pclk, lclk, caps, vm, in_width,
+   r = dispc_ovl_calc_scaling(dispc, plane, pclk, lclk, caps, vm, in_width,
   in_height, out_width, out_height, fourcc,
   &five_taps, &x_predecim, &y_predecim, pos_x,
   rotation_type, mem_to_mem);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


Re: [PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

2018-02-28 Thread Tomi Valkeinen
On 27/02/18 16:35, Laurent Pinchart wrote:

> the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ 
> handling to the DSS side, as they're not DRM/KMS-related ?

I think we should react to both errors somehow (I'm not sure how,
disable output probably), and that has to be done on the KMS level. We
don't do that now, but moving this to DSS side would make error handling
more difficult to do in the future.

 Tomi

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


[PATCH] drm/sun4i: init dclk_min_div & dclk_max_div inside encoder init functions

2018-02-28 Thread Giulio Benetti
sun4i_dclk_round_rate is called before sun4i_tcon_mode_set,
so it finds dclk_min_div and dclk_max_div set to 0 and fails
adding crtc.

Move dclk_min_div and dclk_max_div to encoders init functions.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 4 
 drivers/gpu/drm/sun4i/sun4i_rgb.c  | 4 
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index be3f14d..6e1abd6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -123,6 +123,10 @@ int sun4i_lvds_init(struct drm_device *drm, struct 
sun4i_tcon *tcon)
return 0;
}
 
+   /* Init min and max clock divisor according to LVDS encoder */
+   tcon->dclk_min_div = 7;
+   tcon->dclk_max_div = 7;
+
drm_encoder_helper_add(&lvds->encoder,
   &sun4i_lvds_enc_helper_funcs);
ret = drm_encoder_init(drm,
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 832f8f9..75ab3e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -187,6 +187,10 @@ int sun4i_rgb_init(struct drm_device *drm, struct 
sun4i_tcon *tcon)
return 0;
}
 
+   /* Init min and max clock divisor according to RGB encoder */
+   tcon->dclk_min_div = 6;
+   tcon->dclk_max_div = 127;
+
drm_encoder_helper_add(&rgb->encoder,
   &sun4i_rgb_enc_helper_funcs);
ret = drm_encoder_init(drm,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e7c5e3c..ce89fd4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -277,8 +277,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
u8 clk_delay;
u32 reg, val = 0;
 
-   tcon->dclk_min_div = 7;
-   tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Adjust clock delay */
@@ -348,8 +346,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
u8 clk_delay;
u32 val = 0;
 
-   tcon->dclk_min_div = 6;
-   tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Adjust clock delay */
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

2018-02-28 Thread Ville Syrjälä
On Fri, Feb 23, 2018 at 04:04:10PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 23, 2018 at 01:52:22PM +, Brian Starkey wrote:
> > Hi Ville,
> > 
> > On Thu, Feb 22, 2018 at 11:42:29PM +0200, Ville Syrjala wrote:
> > >From: Ville Syrjälä 
> > >
> > >The documentation for the ctm matrix suggests a two's complement
> > >format, but at least the i915 implementation is using sign-magnitude
> > >instead. And looks like malidp is doing the same. Change the docs
> > >to match the current implementation, and change the type from __s64
> > >to __u64 to drive the point home.
> > 
> > I totally agree that this is a good idea, but...
> > 
> > >
> > >Cc: dri-devel@lists.freedesktop.org
> > >Cc: Mihail Atanassov 
> > >Cc: Liviu Dudau 
> > >Cc: Brian Starkey 
> > >Cc: Mali DP Maintainers 
> > >Cc: Johnson Lin 
> > >Cc: Uma Shankar 
> > >Cc: Shashank Sharma 
> > >Signed-off-by: Ville Syrjälä 
> > >---
> > > include/uapi/drm/drm_mode.h | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > >diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > >index 2c575794fb52..b5d7d9e0eff5 100644
> > >--- a/include/uapi/drm/drm_mode.h
> > >+++ b/include/uapi/drm/drm_mode.h
> > >@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> > > };
> > >
> > > struct drm_color_ctm {
> > >-  /* Conversion matrix in S31.32 format. */
> > >-  __s64 matrix[9];
> > >+  /*
> > >+   * Conversion matrix in S31.32 sign-magnitude
> > >+   * (not two's complement!) format.
> > >+   */
> > >+  __u64 matrix[9];
> > 
> > Isn't changing the type liable to break something for someone?
> 
> I hope not. Renaming the member would be a no no, but just changing the
> type should be mostly safe I think. I suppose if someone is building
> something with very strict compiler -W flags and -Werror it might cause
> a build failure, so I guess one might label it as a minor api break but
> not an abi break.
> 
> If people think that's a serious concern I guess we can keep the
> __s64, but I'd rather not give people that much rope to hang
> themselves by interpreting it as 2's complement.

OK, no one complained loudly so I've gone and pushed this to
drm-misc-next. Now we wait and see whether I can dodge the egg...

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


[PATCH v2] bridge: Elaborate a bit on dumb VGA bridges in Kconfig

2018-02-28 Thread Linus Walleij
It's better if we explain a bit that this pertains to
passive VGA DAC bridges.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Write that these bridges are non-programmable rather than
  discrete, as that reflects the name of the bridge being
  "dumb". Discrete is wrong as it has a specific electronic
  meaning, as in "non-integrated" and this is integrated.
---
 drivers/gpu/drm/bridge/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a06c16..e1ab948707a0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -30,7 +30,8 @@ config DRM_DUMB_VGA_DAC
depends on OF
select DRM_KMS_HELPER
help
- Support for RGB to VGA DAC based bridges
+ Support for non-programmable RGB to VGA DAC based bridges
+ such as ADI ADV7123 or TI THS8134 and THS8135.
 
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
-- 
2.14.3

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


Re: [PATCH v2] bridge: Elaborate a bit on dumb VGA bridges in Kconfig

2018-02-28 Thread Laurent Pinchart
Hi Linus,

Thank you for the patch.

On Wednesday, 28 February 2018 15:02:49 EET Linus Walleij wrote:
> It's better if we explain a bit that this pertains to
> passive VGA DAC bridges.

s/passive/non-programmable/ ?

> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Write that these bridges are non-programmable rather than
>   discrete, as that reflects the name of the bridge being
>   "dumb". Discrete is wrong as it has a specific electronic
>   meaning, as in "non-integrated" and this is integrated.

s/discrete/passive/ :-)

> ---
>  drivers/gpu/drm/bridge/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a06c16..e1ab948707a0 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -30,7 +30,8 @@ config DRM_DUMB_VGA_DAC
>   depends on OF
>   select DRM_KMS_HELPER
>   help
> -   Support for RGB to VGA DAC based bridges
> +   Support for non-programmable RGB to VGA DAC based bridges
> +   such as ADI ADV7123 or TI THS8134 and THS8135.

How about

"Support for non-programmable RGB to VGA DAC bridges, such as ADI ADV7123, TI 
THS8134 and THS8135 or passive resistor ladder DACs."

Reviewed-by: Laurent Pinchart 

>  config DRM_LVDS_ENCODER
>   tristate "Transparent parallel to LVDS encoder support"

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

2018-02-28 Thread Laurent Pinchart
Hi Tomi,

On Wednesday, 28 February 2018 13:37:48 EET Tomi Valkeinen wrote:
> On 27/02/18 16:35, Laurent Pinchart wrote:
> > the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ
> > handling to the DSS side, as they're not DRM/KMS-related ?
> 
> I think we should react to both errors somehow (I'm not sure how,
> disable output probably), and that has to be done on the KMS level. We
> don't do that now, but moving this to DSS side would make error handling
> more difficult to do in the future.

Ideally I'd demultiplex interrupts on the DSS side and report events to the 
KMS side (page flip completion, underflows, ...).

-- 
Regards,

Laurent Pinchart

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


[PATCH] tinydrm: add backlight dependency

2018-02-28 Thread Arnd Bergmann
Calling devm_of_find_backlight directly means we get a link failure
without CONFIG_BACKLIGHT_CLASS_DEVICE:

drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe':
mi0283qt.c:(.text+0x684): undefined reference to `devm_of_find_backlight'

This adds an explicit Kconfig dependency for it. While I did not
observe that failure for st7735r, I assume the same change is needed
there for the same reason.

Fixes: d1a2e7004b5e ("drm/tinydrm: Replace tinydrm_of_find_backlight with 
of_find_backlight")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tinydrm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 13339be843bc..4592a5e3f20b 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -23,6 +23,7 @@ config TINYDRM_ILI9225
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
select TINYDRM_MIPI_DBI
help
  DRM driver for the Multi-Inno MI0283QT display panel
@@ -54,6 +55,7 @@ config TINYDRM_ST7586
 config TINYDRM_ST7735R
tristate "DRM support for Sitronix ST7735R display panels"
depends on DRM_TINYDRM && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
select TINYDRM_MIPI_DBI
help
  DRM driver Sitronix ST7735R with one of the following LCDs:
-- 
2.9.0

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


Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

2018-02-28 Thread Andrzej Hajda
On 27.02.2018 23:26, Chanwoo Choi wrote:
> Hi,
>
> On 2018년 02월 27일 21:05, Andrzej Hajda wrote:
>> On 27.02.2018 12:08, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
 From: Maciej Purski 

 Currently MHL chip must be turned on permanently to detect MHL cable. It
 duplicates micro-USB controller's (MUIC) functionality and consumes
 unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
 only if it detects MHL cable.

 Signed-off-by: Maciej Purski 
 Signed-off-by: Andrzej Hajda 
 ---
 v5: updated extcon API

 This is rework of the patch by Maciej with following changes:
 - use micro-USB port bindings to get extcon, instead of extcon property,
 - fixed remove sequence,
 - fixed extcon get state logic.

 Code finding extcon node is hacky IMO, I guess ultimately it should be done
 via some framework (maybe even extcon), or at least via helper, I hope it
 can stay as is until the proper solution will be merged.

 Signed-off-by: Andrzej Hajda 
 ---
  drivers/gpu/drm/bridge/sil-sii8620.c | 97 
 ++--
  1 file changed, 94 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
 b/drivers/gpu/drm/bridge/sil-sii8620.c
 index 9e785b8e0ea2..62b0adabcac2 100644
 --- a/drivers/gpu/drm/bridge/sil-sii8620.c
 +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
 @@ -17,6 +17,7 @@
  
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -25,6 +26,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  
 @@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
 +  struct extcon_dev *extcon;
 +  struct notifier_block extcon_nb;
 +  struct work_struct extcon_wq;
 +  int cable_state;
struct list_head mt_queue;
struct {
int r_size;
 @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct 
 sii8620 *ctx)
ctx->rc_dev = rc_dev;
  }
  
 +static void sii8620_cable_out(struct sii8620 *ctx)
 +{
 +  disable_irq(to_i2c_client(ctx->dev)->irq);
 +  sii8620_hw_off(ctx);
 +}
 +
 +static void sii8620_extcon_work(struct work_struct *work)
 +{
 +  struct sii8620 *ctx =
 +  container_of(work, struct sii8620, extcon_wq);
 +  int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
 +
 +  if (state == ctx->cable_state)
 +  return;
 +
 +  ctx->cable_state = state;
 +
 +  if (state > 0)
 +  sii8620_cable_in(ctx);
 +  else
 +  sii8620_cable_out(ctx);
 +}
 +
 +static int sii8620_extcon_notifier(struct notifier_block *self,
 +  unsigned long event, void *ptr)
 +{
 +  struct sii8620 *ctx =
 +  container_of(self, struct sii8620, extcon_nb);
 +
 +  schedule_work(&ctx->extcon_wq);
 +
 +  return NOTIFY_DONE;
 +}
 +
 +static int sii8620_extcon_init(struct sii8620 *ctx)
 +{
 +  struct extcon_dev *edev;
 +  struct device_node *musb, *muic;
 +  int ret;
 +
 +  /* get micro-USB connector node */
 +  musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
 +  /* next get micro-USB Interface Controller node */
 +  muic = of_get_next_parent(musb);
 +
 +  if (!muic) {
 +  dev_info(ctx->dev, "no extcon found, switching to 'always on' 
 mode\n");
 +  return 0;
 +  }
 +
 +  edev = extcon_find_edev_by_node(muic);
 +  of_node_put(muic);
 +  if (IS_ERR(edev)) {
 +  if (PTR_ERR(edev) == -EPROBE_DEFER)
 +  return -EPROBE_DEFER;
 +  dev_err(ctx->dev, "Invalid or missing extcon\n");
 +  return PTR_ERR(edev);
 +  }
 +
 +  ctx->extcon = edev;
 +  ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
 +  INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
 +  ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
>>> You better to use devm_extcon_register_notifier().
>> With devm version I risk that in case of device unbind notification will
>> be called after .remove callback, it seems to me quite dangerous. Or am
>> I missing something?
> If you use the cancel_work_sync() in remove() instead of flush_work(),
> you can use the 'devm_extcon_*'.

cancel_work_sync() does not prevent works scheduled later from execution
[1] and this scenario is possible with devm_extcon_register_notifier()
and cancel_work_sync().
So we end up with:
    sii8620_remove() calls cancel_work_sync()
...
    notifier(called asynchronously) schedules sii8620_extcon_work()
...
    notifier is removed by devm framework
    s

Re: [PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

2018-02-28 Thread Tomi Valkeinen
On 28/02/18 15:23, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 28 February 2018 13:37:48 EET Tomi Valkeinen wrote:
>> On 27/02/18 16:35, Laurent Pinchart wrote:
>>> the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ
>>> handling to the DSS side, as they're not DRM/KMS-related ?
>>
>> I think we should react to both errors somehow (I'm not sure how,
>> disable output probably), and that has to be done on the KMS level. We
>> don't do that now, but moving this to DSS side would make error handling
>> more difficult to do in the future.
> 
> Ideally I'd demultiplex interrupts on the DSS side and report events to the 
> KMS side (page flip completion, underflows, ...).

That's more or less what Jyri's "drm/omap: Make omapdss API more
generic" does, isn't it? Or what is the difference with interrupt and
event in your mind? Function calls vs status bits?

 Tomi

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


Re: [PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

2018-02-28 Thread Laurent Pinchart
Hi Tomi,

On Wednesday, 28 February 2018 16:05:34 EET Tomi Valkeinen wrote:
> On 28/02/18 15:23, Laurent Pinchart wrote:
> > On Wednesday, 28 February 2018 13:37:48 EET Tomi Valkeinen wrote:
> >> On 27/02/18 16:35, Laurent Pinchart wrote:
> >>> the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ
> >>> handling to the DSS side, as they're not DRM/KMS-related ?
> >> 
> >> I think we should react to both errors somehow (I'm not sure how,
> >> disable output probably), and that has to be done on the KMS level. We
> >> don't do that now, but moving this to DSS side would make error handling
> >> more difficult to do in the future.
> > 
> > Ideally I'd demultiplex interrupts on the DSS side and report events to
> > the KMS side (page flip completion, underflows, ...).
> 
> That's more or less what Jyri's "drm/omap: Make omapdss API more
> generic" does, isn't it? Or what is the difference with interrupt and
> event in your mind? Function calls vs status bits?

Yes, that's the difference in my mind. I'd keep the status bits on the DSS 
side. We don't have to implement one callback function for each status bit, we 
could translate them into abstract event bits that are not specific to a 
particular DSS version. What I'd like to avoid is omapdrm calling into omapdss 
to retrieve a name for a bit that is DSS-specific. If we want hardware names 
in debug messages I think they should be printed on the omapdss side, and if 
we want to handle status bits on the omapdrm side they shouldn't require 
hardware names.

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state

2018-02-28 Thread Alex Deucher
+ dri-devel


On Wed, Feb 28, 2018 at 4:33 AM, S, Shirish  wrote:
> From: Shirish S 
>
> Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to
> complement "for_each_oldnew_plane_in_state" way of reading plane
> states.
>
> The plane states are required to be read in reverse order for
> amdgpu, as the z order convention followed in linux is
> opposite to how the planes are supposed to be presented to DC
> engine, which is in common to both windows and linux.
>
> Signed-off-by: Shirish S 
> Signed-off-by: Pratik Vishwakarma 
> ---
>  include/drm/drm_atomic.h | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index cf13842..b947930 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
>
>  /**
> + * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an 
> atomic
> + * update in reverse order
> + * @__state: &struct drm_atomic_state pointer
> + * @plane: &struct drm_plane iteration cursor
> + * @old_plane_state: &struct drm_plane_state iteration cursor for the old 
> state
> + * @new_plane_state: &struct drm_plane_state iteration cursor for the new 
> state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all planes in an atomic update in reverse order,
> + * tracking both old and  new state. This is useful in places where the
> + * state delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_plane_in_state_reverse(__state, plane, 
> old_plane_state, new_plane_state, __i) \
> +   (for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1);  
>   \
> +(__i) >= 0;\
> +(__i)--)   \
> +   for_each_if ((__state)->planes[__i].ptr &&  \
> +((plane) = (__state)->planes[__i].ptr, \
> + (old_plane_state) = 
> (__state)->planes[__i].old_state,\
> + (new_plane_state) = 
> (__state)->planes[__i].new_state, 1)))
> +
> +/**
>   * for_each_old_plane_in_state - iterate over all planes in an atomic update
>   * @__state: &struct drm_atomic_state pointer
>   * @plane: &struct drm_plane iteration cursor
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

2018-02-28 Thread Tomi Valkeinen


On 28/02/18 16:24, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 28 February 2018 16:05:34 EET Tomi Valkeinen wrote:
>> On 28/02/18 15:23, Laurent Pinchart wrote:
>>> On Wednesday, 28 February 2018 13:37:48 EET Tomi Valkeinen wrote:
 On 27/02/18 16:35, Laurent Pinchart wrote:
> the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ
> handling to the DSS side, as they're not DRM/KMS-related ?

 I think we should react to both errors somehow (I'm not sure how,
 disable output probably), and that has to be done on the KMS level. We
 don't do that now, but moving this to DSS side would make error handling
 more difficult to do in the future.
>>>
>>> Ideally I'd demultiplex interrupts on the DSS side and report events to
>>> the KMS side (page flip completion, underflows, ...).
>>
>> That's more or less what Jyri's "drm/omap: Make omapdss API more
>> generic" does, isn't it? Or what is the difference with interrupt and
>> event in your mind? Function calls vs status bits?
> 
> Yes, that's the difference in my mind. I'd keep the status bits on the DSS 
> side. We don't have to implement one callback function for each status bit, 
> we 
> could translate them into abstract event bits that are not specific to a 
> particular DSS version. What I'd like to avoid is omapdrm calling into 
> omapdss 
> to retrieve a name for a bit that is DSS-specific. If we want hardware names 
> in debug messages I think they should be printed on the omapdss side, and if 
> we want to handle status bits on the omapdrm side they shouldn't require 
> hardware names.

Ok, yes, I see your point, and agree.

Here, I think what's done (after the IRQ change patch) is that we get a
an abstracted bit for the underflow. Omapdrm can map that bit to an
omap_plane, and should get the name from omap_plane, instead of asking
it directly from dispc.

 Tomi

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


Re: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

2018-02-28 Thread Heiko Stübner
Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
> From: zain wang 
> 
> The bridge does not need to be powered in analogix_dp_bind(), so
> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
> as well as their power-off counterparts.
> 
> Cc: Stéphane Marchesin 
> Signed-off-by: zain wang 
> Signed-off-by: Caesar Wang 
> [the patch originally just removed the power_on portion, seanpaul removed
> the power off code as well as improved the commit message]
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> cb5e18d6ba04..1477ea9ba85d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
> 
>   pm_runtime_enable(dev);
> 
> - pm_runtime_get_sync(dev);
> - phy_power_on(dp->phy);
> -
> - analogix_dp_init_dp(dp);
> -
>   ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
>   analogix_dp_hardirq,
>   analogix_dp_irq_thread,

Not 100% sure here, as the driver has the request-irq + disable-irq hack
here. So a pending interrupt could possibly fire between request and
disable.

Right now the block should be on, but can it still handle such an irq
when the power is removed?

So before removing the power here, we might want something
similar to what Marc posted for the vop [0] for the analogix-dp?


Heiko

[0] https://patchwork.kernel.org/patch/10210513/

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


RE: [PATCH 02/10] drm: Add Plane Degamma properties

2018-02-28 Thread Shankar, Uma


>-Original Message-
>From: Sean Paul [mailto:seanp...@chromium.org]
>Sent: Tuesday, February 27, 2018 8:44 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org; brian.star...@arm.com; Shankar, Uma
>
>Subject: Re: [PATCH 02/10] drm: Add Plane Degamma properties
>
>On Thu, Feb 15, 2018 at 12:32:52AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Add Plane Degamma as a blob property and plane degamma size as a range
>> property.
>>
>> (am from https://patchwork.kernel.org/patch/10046515/)
>
>The discussion on this previous version has some feedback on using 32-bit 
>values
>in the gamma lut instead of 16-bit. Have you considered this?
>

This needs to be modified. Will address this and send a next version.
Kept it on hold since was trying to get a userspace implementation done.
But, it's good to refresh the series addressing all the review comments.
Thanks for the review Sean Paul.

>>
>> Change-Id: Iaead6f944a8b677227d1be11169f46178de533b1
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_atomic.c| 12 
>>  drivers/gpu/drm/drm_atomic_helper.c |  7 +++
>>  drivers/gpu/drm/drm_mode_config.c   | 14 ++
>>  include/drm/drm_mode_config.h   | 10 ++
>>  include/drm/drm_plane.h | 10 ++
>>  5 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index b76d49218cf1d..4a06ff2fd1a5e
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct
>> drm_plane *plane,  {
>>  struct drm_device *dev = plane->dev;
>>  struct drm_mode_config *config = &dev->mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>>  if (property == config->prop_fb_id) {
>>  struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL,
>> val); @@ -762,6 +764,12 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  } else if (plane->funcs->atomic_set_property) {
>>  return plane->funcs->atomic_set_property(plane, state,
>>  property, val);
>> +} else if (property == config->plane_degamma_lut_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +&state->degamma_lut,
>> +val, -1, &replaced);
>> +state->color_mgmt_changed |= replaced;
>> +return ret;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -820,6 +828,9 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
>>  *val = state->zpos;
>>  } else if (plane->funcs->atomic_get_property) {
>>  return plane->funcs->atomic_get_property(plane, state,
>property,
>> val);
>> +} else if (property == config->plane_degamma_lut_property) {
>> +*val = (state->degamma_lut) ?
>> +state->degamma_lut->base.id : 0;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -944,6 +955,7 @@ static void drm_atomic_plane_print_state(struct
>drm_printer *p,
>>  drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n",
>DRM_RECT_ARG(&dest));
>>  drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n",
>DRM_RECT_FP_ARG(&src));
>>  drm_printf(p, "\trotation=%x\n", state->rotation);
>> +drm_printf(p, "\tcolor_mgmt_changed=%d\n",
>> +state->color_mgmt_changed);
>>
>>  if (plane->funcs->atomic_print_state)
>>  plane->funcs->atomic_print_state(p, state); diff --git
>> a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index ab4032167094c..d3eaf4d397681 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -3488,7 +3488,12 @@ void
>__drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>  drm_framebuffer_get(state->fb);
>>
>>  state->fence = NULL;
>> +
>
>Extra line snuck in here
>

Will rectify this.

>>  state->commit = NULL;
>> +
>> +if (state->degamma_lut)
>> +drm_property_reference_blob(state->degamma_lut);
>> +state->color_mgmt_changed = false;
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>>
>> @@ -3533,6 +3538,8 @@ void
>> __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>>
>>  if (state->commit)
>>  drm_crtc_commit_put(state->commit);
>> +
>> +drm_property_unreference_blob(state->degamma_lut);
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index e5c653357024d..7d8e74715b565 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -348,6 +348,20 @@ static int
>drm_mode_create_standard_properties(struct drm_device *dev)
>>  return -ENOMEM;
>>

RE: [PATCH 03/10] drm: Add Plane CTM property

2018-02-28 Thread Shankar, Uma


>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sean Paul
>Sent: Tuesday, February 27, 2018 8:53 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 03/10] drm: Add Plane CTM property
>
>On Thu, Feb 15, 2018 at 12:32:53AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Add a blob property for plane CSC usage.
>>
>> (am from https://patchwork.kernel.org/patch/9971339/)
>>
>> Change-Id: I688ce7c95c20d307cb0aa35c5eba5ce2e1e88314
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_atomic.c| 10 ++
>>  drivers/gpu/drm/drm_atomic_helper.c |  3 +++
>>  drivers/gpu/drm/drm_mode_config.c   |  6 ++
>>  include/drm/drm_mode_config.h   |  6 ++
>>  include/drm/drm_plane.h |  8 
>>  5 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 4a06ff2fd1a5e..d4b8c6cc84128
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -770,6 +770,14 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>>  val, -1, &replaced);
>>  state->color_mgmt_changed |= replaced;
>>  return ret;
>> +} else if (property == config->plane_ctm_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +&state->ctm,
>> +val,
>> +sizeof(struct drm_color_ctm),
>> +&replaced);
>> +state->color_mgmt_changed |= replaced;
>> +return ret;
>>  } else {
>>  return -EINVAL;
>>  }
>> @@ -831,6 +839,8 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
>>  } else if (property == config->plane_degamma_lut_property) {
>>  *val = (state->degamma_lut) ?
>>  state->degamma_lut->base.id : 0;
>> +} else if (property == config->plane_ctm_property) {
>> +*val = (state->ctm) ? state->ctm->base.id : 0;
>>  } else {
>>  return -EINVAL;
>>  }
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index d3eaf4d397681..17e137a529a0e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -3493,6 +3493,8 @@ void
>> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>
>>  if (state->degamma_lut)
>>  drm_property_reference_blob(state->degamma_lut);
>> +if (state->ctm)
>> +drm_property_reference_blob(state->ctm);
>>  state->color_mgmt_changed = false;
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>> @@ -3540,6 +3542,7 @@ void
>__drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>>  drm_crtc_commit_put(state->commit);
>>
>>  drm_property_unreference_blob(state->degamma_lut);
>> +drm_property_unreference_blob(state->ctm);
>>  }
>>  EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c
>> b/drivers/gpu/drm/drm_mode_config.c
>> index 7d8e74715b565..c8763977413e7 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -361,6 +361,12 @@ static int
>drm_mode_create_standard_properties(struct drm_device *dev)
>>  if (!prop)
>>  return -ENOMEM;
>>  dev->mode_config.plane_degamma_lut_size_property = prop;
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB,
>> +"PLANE_CTM", 0);
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.plane_ctm_property = prop;
>>
>>  return 0;
>>  }
>> diff --git a/include/drm/drm_mode_config.h
>> b/include/drm/drm_mode_config.h index dcec93d062b4d..ad7235ced531b
>> 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -734,6 +734,12 @@ struct drm_mode_config {
>>   * size of the degamma LUT as supported by the driver (read-only).
>>   */
>>  struct drm_property *plane_degamma_lut_size_property;
>> +/**
>> + * @plane_ctm_property: Optional CRTC property to set the
>> + * matrix used to convert colors after the lookup in the
>> + * degamma LUT.
>> + */
>> +struct drm_property *plane_ctm_property;
>
>Same comments re: puttting the property in drm_plane and adding a helper to
>create it.
>

Sure, will update this.

Regards,
Uma Shankar

>Sean
>
>>  /**
>>   * @ctm_property: Optional CRTC property to set the
>>   * matrix used to convert colors after the lookup in the diff --git
>> a/include/drm/drm_plane.h b/include/drm/drm_plane.h index
>> 2f8f5db77a406..21aecc9c91a09 100644
>> --- a/include/drm/drm_plane.h
>> +++ b/include/drm/drm_plane

Re: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

2018-02-28 Thread Heiko Stübner
Am Mittwoch, 28. Februar 2018, 15:54:30 CET schrieb Marc Zyngier:
> On 28/02/18 14:37, Heiko Stübner wrote:
> > Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
> >> From: zain wang 
> >> 
> >> The bridge does not need to be powered in analogix_dp_bind(), so
> >> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
> >> as well as their power-off counterparts.
> >> 
> >> Cc: Stéphane Marchesin 
> >> Signed-off-by: zain wang 
> >> Signed-off-by: Caesar Wang 
> >> [the patch originally just removed the power_on portion, seanpaul removed
> >> the power off code as well as improved the commit message]
> >> Signed-off-by: Sean Paul 
> >> Signed-off-by: Thierry Escande 
> >> ---
> >> 
> >>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
> >>  1 file changed, 10 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> >> cb5e18d6ba04..1477ea9ba85d 100644
> >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
> >> drm_device *drm_dev,
> >> 
> >>pm_runtime_enable(dev);
> >> 
> >> -  pm_runtime_get_sync(dev);
> >> -  phy_power_on(dp->phy);
> >> -
> >> -  analogix_dp_init_dp(dp);
> >> -
> >> 
> >>ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
> >>
> >>analogix_dp_hardirq,
> >>analogix_dp_irq_thread,
> > 
> > Not 100% sure here, as the driver has the request-irq + disable-irq hack
> > here. So a pending interrupt could possibly fire between request and
> > disable.
> > 
> > Right now the block should be on, but can it still handle such an irq
> > when the power is removed?
> 
> Probably not (see below).
> 
> > So before removing the power here, we might want something
> > similar to what Marc posted for the vop [0] for the analogix-dp?
> 
> You can do that trick only if the interrupt is not shared. In the VOP
> case, it is shared with the IOMMU, which makes it more... interesting.

Yep, which is why I mentioned it, as the dp-irq should not be shared
I'd think :-)


Heiko

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


RE: [PATCH 05/10] drm: Define helper function for plane color enabling

2018-02-28 Thread Shankar, Uma


>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sean Paul
>Sent: Tuesday, February 27, 2018 8:59 PM
>To: Daniele Castagna 
>Cc: dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 05/10] drm: Define helper function for plane color enabling
>
>On Thu, Feb 15, 2018 at 12:32:55AM -0500, Daniele Castagna wrote:
>> From: "uma.shankar at intel.com (Uma Shankar)" 
>>
>> Define helper function to enable Plane color features to attach plane
>> color properties to plane structure.
>>
>> (am from https://patchwork.kernel.org/patch/9971333/)
>>
>> Change-Id: I0a6647607fe482786e7cdb5f997faf196b2f59a2
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_plane.c  | 48
>> 
>>  include/drm/drm_color_mgmt.h |  5 
>>  2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 2c90519576a3e..bc2fc5e6771ac 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -143,6 +143,54 @@ static int create_in_format_blob(struct drm_device
>*dev, struct drm_plane *plane
>>  return 0;
>>  }
>>
>> + /**
>> + * drm_plane_enable_color_mgmt - enable color management properties
>> + * @plane: DRM Plane
>> + * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
>> + * @plane_has_ctm: whether to attach ctm_property for CSC matrix
>> + * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
>> + *
>> + * This function lets the driver enable the color correction
>> + * properties on a plane. This includes 3 degamma, csc and gamma
>> + * properties that userspace can set and 2 size properties to inform
>> + * the userspace of the lut sizes. Each of the properties are
>> + * optional. The gamma and degamma properties are only attached if
>> + * their size is not 0 and ctm_property is only attached if has_ctm
>> +is
>> + * true.
>> + *
>> + * Drivers should use drm_atomic_helper_legacy_gamma_set() to
>> +implement the
>> + * legacy &drm_crtc_funcs.gamma_set callback.
>> + */
>> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
>> +uint plane_degamma_lut_size,
>> +bool plane_has_ctm,
>> +uint plane_gamma_lut_size)
>> +{
>
>This seems like a good place to create the properties once they're located in
>drm_plane.
>

Yeah, I agree. Will update the series.

Regards,
Uma Shankar

>> +struct drm_device *dev = plane->dev;
>> +struct drm_mode_config *config = &dev->mode_config;
>> +
>> +if (plane_degamma_lut_size) {
>> +drm_object_attach_property(&plane->base,
>> +config->plane_degamma_lut_property, 0);
>> +drm_object_attach_property(&plane->base,
>> +config->plane_degamma_lut_size_property,
>> +plane_degamma_lut_size);
>> +}
>> +
>> +if (plane_has_ctm)
>> +drm_object_attach_property(&plane->base,
>> +config->plane_ctm_property, 0);
>> +
>> +if (plane_gamma_lut_size) {
>> +drm_object_attach_property(&plane->base,
>> +config->plane_gamma_lut_property, 0);
>> +drm_object_attach_property(&plane->base,
>> +config->plane_gamma_lut_size_property,
>> +plane_gamma_lut_size);
>> +}
>> +}
>> +EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
>> +
>>  /**
>>   * drm_universal_plane_init - Initialize a new universal plane object
>>   * @dev: DRM device
>> diff --git a/include/drm/drm_color_mgmt.h
>> b/include/drm/drm_color_mgmt.h index 03a59cbce6212..155a9ba38471c
>> 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc
>> *crtc,  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>>   int gamma_size);
>>
>> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
>> + uint plane_degamma_lut_size,
>> + bool plane_has_ctm,
>> + uint plane_gamma_lut_size);
>> +
>>  #endif
>> --
>> 2.16.1.291.g4437f3f132-goog
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Sean Paul, Software Engineer, Google / Chromium OS
>___
>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 libdrm] meson: add configuration summary

2018-02-28 Thread Eric Engestrom
On Tuesday, 2018-02-27 12:30:48 -0800, Eric Anholt wrote:
> Dylan Baker  writes:
> 
> > [ Unknown signature status ]
> > Quoting Eric Engestrom (2018-02-27 03:11:07)
> >> The message block printed is the same as the one in configure.ac
> >> 
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >>  meson.build | 17 +
> >>  1 file changed, 17 insertions(+)
> >> 
> >> diff --git a/meson.build b/meson.build
> >> index bd00cdc2cae9f0749180..ab6f881755935968b822 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -373,3 +373,20 @@ if with_man_pages
> >>  endif
> >>  subdir('data')
> >>  subdir('tests')
> >> +
> >> +message('')
> >> +message('@0@ will be compiled with:'.format(meson.project_name()))
> >> +message('')
> >> +message('  libkms @0@'.format(with_libkms))
> >> +message('  Intel API  @0@'.format(with_intel))
> >> +message('  vmwgfx API @0@'.format(with_vmwgfx))
> >> +message('  Radeon API @0@'.format(with_radeon))
> >> +message('  AMDGPU API @0@'.format(with_amdgpu))
> >> +message('  Nouveau API@0@'.format(with_nouveau))
> >> +message('  OMAP API   @0@'.format(with_omap))
> >> +message('  EXYNOS API @0@'.format(with_exynos))
> >> +message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
> >> with_freedreno_kgsl))
> >> +message('  Tegra API  @0@'.format(with_tegra))
> >> +message('  VC4 API@0@'.format(with_vc4))
> >> +message('  Etnaviv API@0@'.format(with_etnaviv))
> >> +message('')
> >> -- 
> >> Cheers,
> >>   Eric
> >> 
> >
> > This one is certainly simple enough that we can use a single message call 
> > and a
> > ''' string :)
> 
> But then you end up with 13 @n@ values and when someone wants to put
> something earlier in the list for some sorting reason, then they need to
> renumber the rest.  This is much nicer.

I have to agree here. Dylan, why did you want to avoid multiple
`message()`? They're not expensive afaict, so I'm not sure what the gain
would be?

I also had a try, and multiline messages only get a `Message:` prefix on
the first line, so combining them would result in unpredictable vertical
alignments. Unless there's a good reason to merge them, I'll keep them
separate.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/arm: mali-dp: Reorder atomic_commit_hw_done to avoid waiting on wrong vblank event

2018-02-28 Thread Liviu Dudau
mali-dp driver sets the 'go' bit (config_valid) and then waits for
confirmation from the hardware that the config has been updated before
arming the vblank event. The issue is that config_valid is actually
asserted by the hardware after vblank event, during the prefetch phase,
so when arming the vblank event we are going to wait on the wrong
vblank.

Fix it by arming the vblank event first and then setting the
config_valid bit. That way the event will be signalled for the correct
vblank interrupt.

Reported-by: Alexandru-Cosmin Gheorghe 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d88a3b9d59cc..ac44c6127a4f 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -189,12 +189,6 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
 
-   if (malidp->crtc.enabled) {
-   /* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm))
-   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
-   }
-
event = malidp->crtc.state->event;
if (event) {
malidp->crtc.state->event = NULL;
@@ -206,6 +200,12 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
drm_crtc_send_vblank_event(&malidp->crtc, event);
spin_unlock_irq(&drm->event_lock);
}
+   if (malidp->crtc.enabled) {
+   /* only set config_valid if the CRTC is enabled */
+   if (malidp_set_and_wait_config_valid(drm))
+   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
+
drm_atomic_helper_commit_hw_done(state);
 }
 
@@ -232,8 +232,6 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 
malidp_atomic_commit_hw_done(state);
 
-   drm_atomic_helper_wait_for_vblanks(drm, state);
-
pm_runtime_put(drm->dev);
 
drm_atomic_helper_cleanup_planes(drm, state);
-- 
2.16.2

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


Re: [PATCH 0/3] console: Expand dummy functions for CFI

2018-02-28 Thread Bartlomiej Zolnierkiewicz
On Wednesday, February 28, 2018 04:09:47 PM Bartlomiej Zolnierkiewicz wrote:
> On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> > This is a small series that cleans up struct consw a bit and
> > prepares it for Control Flow Integrity checking (i.e. Clang's
> > -fsanitize=cfi).
> 
> for drivers/video/ parts:
> 
> Acked-by: Bartlomiej Zolnierkiewicz 

also I'll be happy to merge all patches through fbdev tree
(if Greg is fine with it and ACKs drivers/usb/ parts)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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


[PATCH] drm: mali-dp: Turn off CRTC vblank when removing module.

2018-02-28 Thread Liviu Dudau
When unbinding the mali-dp driver the drm_vblank_cleanup() function
warns us that the vblanks are still enabled. Fix that by calling
drm_crtc_vblank_off() in the malidp_unbind() function.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 1d2b1c1c83aa..5c2e8260cfa1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -673,8 +673,10 @@ static void malidp_unbind(struct device *dev)
drm_fb_cma_fbdev_fini(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
+   drm_crtc_vblank_off(&malidp->crtc);
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
+   drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-- 
2.16.2

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


Re: [PATCH 0/3] console: Expand dummy functions for CFI

2018-02-28 Thread Bartlomiej Zolnierkiewicz
On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> This is a small series that cleans up struct consw a bit and
> prepares it for Control Flow Integrity checking (i.e. Clang's
> -fsanitize=cfi).

for drivers/video/ parts:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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


Re: [PATCH v3 05/43] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind

2018-02-28 Thread Heiko Stübner
Am Dienstag, 30. Januar 2018, 21:28:35 CET schrieb Thierry Escande:
> From: zain wang 
> 
> The bridge does not need to be powered in analogix_dp_bind(), so
> remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
> as well as their power-off counterparts.
> 
> Cc: Stéphane Marchesin 
> Signed-off-by: zain wang 
> Signed-off-by: Caesar Wang 
> [the patch originally just removed the power_on portion, seanpaul removed
> the power off code as well as improved the commit message]
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> cb5e18d6ba04..1477ea9ba85d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1382,11 +1382,6 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
> 
>   pm_runtime_enable(dev);
> 
> - pm_runtime_get_sync(dev);
> - phy_power_on(dp->phy);
> -
> - analogix_dp_init_dp(dp);
> -
>   ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
>   analogix_dp_hardirq,
>   analogix_dp_irq_thread,
> @@ -1414,15 +1409,10 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev, goto err_disable_pm_runtime;
>   }
> 
> - phy_power_off(dp->phy);
> - pm_runtime_put(dev);
> -
>   return dp;
> 
>  err_disable_pm_runtime:
> 
> - phy_power_off(dp->phy);
> - pm_runtime_put(dev);
>   pm_runtime_disable(dev);
> 
>   return ERR_PTR(ret);

In general, this patch seems to also create the opposite than
"drm/bridge: analogix_dp: Keep PHY powered between driver bind/unbind" [0]

posted on monday?

[0] https://patchwork.kernel.org/patch/10242493/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

2018-02-28 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=198745

--- Comment #17 from Harry Wentland (harry.wentl...@amd.com) ---
Thanks for checking. Non-DC display driver and DC do detection somewhat
differently. It's somewhat difficult to say what's going wrong there.

Do you see different behavior when booting headless, then plugging in the
display?

If you're interested in debugging I'd probably use ftrace to get started,
checking that the functions get hit:
- handle_hpd_irq (only on hotplug)
- dc_link_detect (crucial to detection)
- dc_sink_create
- dm_helpers_read_local_edid
- drm_get_edid
- dm_helpers_parse_edid_caps
- amdgpu_dm_update_connector_after_detect
- drm_mode_connector_update_edid_property

Script to do ftrace debugging (run as root):

#!/bin/bash
cd /sys/kernel/debug/tracing/

echo handle_hpd_irq >> set_ftrace_filter
echo dc_link_detect >> set_ftrace_filter
echo dc_sink_create >> set_ftrace_filter
echo dm_helpers_read_local_edid >> set_ftrace_filter
echo drm_get_edid >> set_ftrace_filter
echo dm_helpers_parse_edid_caps >> set_ftrace_filter
echo amdgpu_dm_update_connector_after_detect >> set_ftrace_filter
echo drm_mode_connector_update_edid_property >> set_ftrace_filter

echo function_graph >> current_tracer
echo '' >> trace
cat trace_pipe

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


[PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

2018-02-28 Thread Liviu Dudau
The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
ioctl expects that any capability set by the client will have a value of 1.
Make the check early so that we don't have to test the value for each
capability.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_ioctl.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af782911c505..02ffa0e8d77b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
 {
struct drm_set_client_cap *req = data;
 
+   if (req->value > 1)
+   return -EINVAL;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
-   if (req->value > 1)
-   return -EINVAL;
file_priv->stereo_allowed = req->value;
break;
case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
-   if (req->value > 1)
-   return -EINVAL;
file_priv->universal_planes = req->value;
break;
case DRM_CLIENT_CAP_ATOMIC:
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
return -EINVAL;
-   if (req->value > 1)
-   return -EINVAL;
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
-- 
2.16.2

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


Re: [PATCH 0/3] console: Expand dummy functions for CFI

2018-02-28 Thread Greg Kroah-Hartman
On Wed, Feb 28, 2018 at 04:14:38PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday, February 28, 2018 04:09:47 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, February 26, 2018 04:04:17 PM Kees Cook wrote:
> > > This is a small series that cleans up struct consw a bit and
> > > prepares it for Control Flow Integrity checking (i.e. Clang's
> > > -fsanitize=cfi).
> > 
> > for drivers/video/ parts:
> > 
> > Acked-by: Bartlomiej Zolnierkiewicz 
> 
> also I'll be happy to merge all patches through fbdev tree
> (if Greg is fine with it and ACKs drivers/usb/ parts)

I've already taken this through the tty tree, sorry about that.
Shouldn't cause any merge issues.

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


[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105046

--- Comment #8 from Harry Wentland  ---
Unplugging and replugging the display should get you back to normal.

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


[PULL] drm-misc-fixes

2018-02-28 Thread Gustavo Padovan
Hi Dave,

A few more fixes for 4.16, including 2 regression fixes. Please pull.

Thanks,

Gustavo

drm-misc-fixes-2018-02-28:
Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.
The following changes since commit dfe8db22372873d205c78a9fd5370b1b088a2b87:

  Merge tag 'drm-misc-fixes-2018-02-21' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-02-22 08:39:26 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/drm-misc tags/drm-misc-fixes-2018-02-28

for you to fetch changes up to 9a191b114906457c4b2494c474f58ae4142d4e67:

  virtio-gpu: fix ioctl and expose the fixed status to userspace. (2018-02-27 
08:37:58 +0100)


Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.


Dave Airlie (1):
  virtio-gpu: fix ioctl and expose the fixed status to userspace.

Ilia Mirkin (1):
  drm/nouveau: prefer XBGR2101010 for addfb ioctl

Maxime Ripard (1):
  drm/sun4i: Protect the TCON pixel clocks

Ondrej Jirman (1):
  drm/sun4i: Enable the output on the pins (tcon0)

 drivers/gpu/drm/drm_framebuffer.c  |  4 
 drivers/gpu/drm/nouveau/nv50_display.c |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  7 +--
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +++--
 include/drm/drm_drv.h  |  1 +
 include/uapi/drm/virtgpu_drm.h |  1 +
 6 files changed, 23 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/drm_ioctl.c: Test client capability value early when setting.

2018-02-28 Thread Ville Syrjälä
On Wed, Feb 28, 2018 at 03:27:41PM +, Liviu Dudau wrote:
> The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP
> ioctl expects that any capability set by the client will have a value of 1.
> Make the check early so that we don't have to test the value for each
> capability.

What if we want a a non-boolean capability at some point?

> 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af782911c505..02ffa0e8d77b 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>  {
>   struct drm_set_client_cap *req = data;
>  
> + if (req->value > 1)
> + return -EINVAL;
> +
>   switch (req->capability) {
>   case DRM_CLIENT_CAP_STEREO_3D:
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->stereo_allowed = req->value;
>   break;
>   case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->universal_planes = req->value;
>   break;
>   case DRM_CLIENT_CAP_ATOMIC:
>   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>   return -EINVAL;
> - if (req->value > 1)
> - return -EINVAL;
>   file_priv->atomic = req->value;
>   file_priv->universal_planes = req->value;
>   break;
> -- 
> 2.16.2
> 
> ___
> 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


  1   2   >