date:20150921

On 17.09.2015 01:18, Russell King - ARM Linux wrote:
> On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote:
>> Yes, I'd expect 100kHz and 400kHz.
>>
>> I agree that 50ms is non-trivial, but it's also not something you're
>> doing lots of.  I'd expect that the EDID is read over this channel at
>> cable plugin time and then not used much after that.  Adding an extra
>> 40ms (10ms vs 50ms) before we can access the TV doesn't seem terrible
>> for compatibility.
>>
>> Doing a quick scan for what others in mainline do:
>>
>> A few can be found with:
>>
>> $ git grep -A3 hdmiddc | grep clock-freq
>> arch/arm/boot/dts/stihxxx-b2120.dtsi-
>> clock-frequency = <10>;
>> arch/arm/boot/dts/tegra30-apalis.dtsi-  clock-frequency = <10>;
>> arch/arm/boot/dts/tegra30-beaver.dts-   clock-frequency = <10>;
>> arch/arm/boot/dts/tegra30-colibri.dtsi- clock-frequency = <10>;
> 
> This is a sure way to propagate a bug.
> 
> I said in a previous email that you need to check the HDMI and CEA
> specs.  I've done this, and HDMI 1.3a specifies a maximum SCL clock
> rate of 100kHz.
> 
> So that's settled then.  100kHz is must be.  Using 400kHz is out of
> specification.
> 

FYI I've managed to measure SCL on iMX6, fast mode stands for 333KHz and
standard mode stands for 100KHz, therefore I'll set the latter mode.

--
With best wishes,
Vladimir

[PATCH] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin

2015-09-21 Thread Russell King - ARM Linux

On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote:
> On Wed, Sep 16, 2015 at 01:41:38PM -0700, Douglas Anderson wrote:
> > There's a member in 'struct dw_hdmi' called cable_plugin.  It's never
> > set to anything anywhere so thus is always false.  There's a bit of code
> > checking it, but since it's always false this must be dead code.
> > Eliminate it.
> > 
> > Note: if someone wants to figure out the intention of the original code
> > and implement whatever feature / fix was needed then we can drop this
> > patch.  The 'cable_plugin' member has been unused since the code was
> > first added in (9aaf880 imx-drm: Add mx6 hdmi transmitter support).
> > 
> > Signed-off-by: Douglas Anderson 
> > ---
> >  drivers/gpu/drm/bridge/dw_hdmi.c | 9 -
> >  1 file changed, 9 deletions(-)
> 
> Except for the CHROMIUM: prefix this looks good to me:
> 
> Reviewed-by: Thierry Reding 
> 
> Russell, do you have patches to this driver queued for v4.4 and plan to
> pick this up into your tree or should I take it?

My current patch stack for imx-drm related stuff looks like this at
present:

drm: bridge/dw_hdmi: place PHY into low power mode when disabled
drm: bridge/dw_hdmi: start of support for pixel doubled modes
drm: bridge/dw_hdmi: remove CEC engine register definitions
drm: bridge/dw_hdmi-cec: add Designware HDMI CEC driver
cec: add HDMI CEC input driver
cec: add HDMI CEC core driver
drm: bridge/dw_hdmi: replace CTS calculation for the ACR
drm: bridge/dw_hdmi: remove ratio support from ACR code
drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
drm: bridge/dw_hdmi: avoid being recursive in N calculation
drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
drm: bridge/dw_hdmi-ahb-audio: add audio driver
drm: bridge/dw_hdmi: improve HDMI enable/disable handling
drm: bridge/dw_hdmi: add connector mode forcing
drm: bridge/dw_hdmi: add support for interlaced video modes
gpu: imx: fix support for interlaced modes
gpu: imx: simplify sync polarity setting

I haven't yet decided what, if anything, from that stack I'm going to
try to get into the next merge window.  Given the lack of interest last
time I posted these patches, I'm loosing interest myself in trying to
get them merged, especially ones which are getting on for being 2 years
old.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Jyri Sarha

On 09/21/15 12:37, Russell King - ARM Linux wrote:
> On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:
>> Add IEC958 channel status helper that gets the audio properties from
>> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
>> produce the channel status bits already in audio stream configuration
>> phase.
>
> What is the reason for doing this early?
>

After some thinking, there is no good reason. It makes the codec bit 
more complicated, but that is not a good reason. I'll change that and 
use the prepare callback.

This patch can be dropped.

> ALSA documentation (which may be out of date) says that the hw_params
> callback can be called multiple times during stream setup.  Do we want
> to be repeatedly programming the HDMI infoframe with different settings,
> potentially confusing the attached device, or would it be better to do
> it slightly later (in the prepare callback) after the parameters have
> been fully negotiated?
>

If it is possible that hw_params() can be called multiple times, at 
least it does not happen very often. I wonder if it would ever happen 
again after a successful hw_params() call. But there is no downside in 
using prepare callback. I was just too much following the way ASoC 
codecs usually do the thing by writing everything to iron as the 
callbacks come in.

Best regards,
Jyri

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

--- Comment #55 from montsegur87 at gmail.com ---
This bug is still happening. Sometimes I can play 2 hours without a crash,
sometimes 5 minutes.

Mesa 11.1.0-devel 
kernel 4.2
llvm 3.8

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/0019a8ce/attachment.html>

[Bug 86320] Monitor on DisplayPort doesn't wake up

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

--- Comment #13 from ValdikSS  ---
(In reply to Wolfgang Rupprecht from comment #12)
> Xrandr seems to think the monitors want 59.xx hz instead of 60.

Just FYI: 59.xx is probably a modeline with reduced blanking (CVT-RB standard)
while 60 is probably usual CVT modeline. You'd better use 59.xx and not 60
because CVT-RB was designed specially for LCDs and requires less bandwidth than
CVT.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/2ca00890/attachment.html>

[PATCH v4] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.

The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.

The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed, in my practice all tested HDMI
monitors have at maximum one extension block.

Signed-off-by: Vladimir Zapolskiy 
---
The change is based on v4.3.0-rc2 and it is applicable to rmk/drm-dwhdmi-devel,
please let me know, if it should be rebased.

v3 of the change was

  Tested-by: Philipp Zabel 

Changes frov v3 to v4, thanks to Doug and Philipp for review:
- set speed mode after software reset in dw_hdmi_i2c_init()
- by default set standard speed mode instead of fast speed mode, on iMX6Q
  this configures SCL to 100 KHz, which is compliant with HDMI 1.3a spec
- do I2C bus controller reinitialization on every data transfer,
  this change hopefully solves some observed problems on RK3288 platform
- added short functional change description to dw_hdmi.txt

Changes from v2 to v3, thanks to Russell:
- moved register field value definitions to dw_hdmi.h
- made completions uninterruptible to avoid transfer retries if interrupted
- use one completion for both read and write transfers as in v1, operation_reg 
is removed
- redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
- struct i2c_algorithm dw_hdmi_algorithm is qualified as const
- dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
- dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is not for 
I2CM
- spin lock is removed from dw_hdmi_i2c_irq()
- removed spin lock from dw_hdmi_i2c_xfer() around write to 
HDMI_IH_MUTE_I2CM_STAT0 register
- split loop over message array in dw_hdmi_i2c_xfer() to validation and 
transfer parts
- added a mutex to serialize I2C transfer requests, i2c->lock is completely 
removed
- removed if(len) check from dw_hdmi_i2c_write(), hardware supports only len>0 
transfers
- described extension blocks <= 1 limitation in the commit message
- a number of minor clean ups

Changes from v1 to v2:
- fixed a devm_kfree() signature
- split completions for read and write operations

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt |   4 +-
 drivers/gpu/drm/bridge/dw_hdmi.c   | 258 -
 drivers/gpu/drm/bridge/dw_hdmi.h   |  19 ++
 3 files changed, 274 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
index a905c14..55f5a7c 100644
--- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -19,7 +19,9 @@ Required properties:

 Optional properties
 - reg-io-width: the width of the reg:1,4, default set to 1 if not present
-- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing,
+  if the property is omitted, a functionally reduced I2C bus
+  controller on DW HDMI is probed
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"

 Example:
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 0083d4e..58dcacf 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1,14 +1,15 @@
 /*
+ * DesignWare High-Definition Multimedia Interface (HDMI) driver
+ *
+ * Copyright (C) 2013-2015 Mentor Graphics Inc.
  * Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010, Guennadi Liakhovetski 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * Designware High-Definition Multimedia Interface (HDMI) driver
- *
- * Copyright (C) 2010, Guennadi Liakhovetski 
  */
 #include 
 #include 
@@ -99,6 +100,17 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+struct dw_hdmi_i2c {
+   struct i2c_adapter  adap;
+
+   struct mutexlock;
+   struct completion   cmp;
+   u8  stat;
+
+   u8  slave_reg;
+   boolis_regaddr;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -108,6 +120,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+   struct dw_hdmi_i2c *i2c;

struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
@@ -184,6

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

--- Comment #3 from Kenneth Graunke  ---
It looks pretty much the same on i965/broadwell as well.  FWIW, I've overheard
that the game requires tessellation shaders for terrain and character
rendering, and if your driver doesn't support them, the game simply skips the
associated drawing.

But on radeonsi, you should have tessellation, so maybe there's something else
going on...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/edd05e58/attachment.html>

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

--- Comment #4 from Kai  ---
(In reply to Kenneth Graunke from comment #3)
> It looks pretty much the same on i965/broadwell as well.  FWIW, I've
> overheard that the game requires tessellation shaders for terrain and
> character rendering, and if your driver doesn't support them, the game
> simply skips the associated drawing.

Nice... shouldn't the game check the features and then either fall back to some
legacy code path or refuse to run with a sensible error message? Ah well.
Also I find this a bit curious, since there *is* a checkbox in the graphics
menu, letting me toggle tessellation.

> But on radeonsi, you should have tessellation, so maybe there's something
> else going on...

Yes, I do have working tessellation â at least it works with Unigine Heaven 
for
example. Of course tessellation is only supported in Core Contexts, maybe the
game fails miserably there and creates a Compatibility Context? (Btw, since I'm
seeing many games/porters getting context creation wrong, I was wondering what
Mac OS X hands out on default? AFAIK they only support higher OpenGL feature
levels in a Core Context as well. But there the games most of the times seem to
work, from what I'm hearing. This leads to me wondering whether Apple just
defaults to Core Contexts and whether Mesa might want to do the same then, if
true.)
Is there a way I can force a core context through some environment variable?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/733de548/attachment.html>

[PATCH 1/2] drm: sti_hdmi: fix i2c adapter device refcounting

The commit 53bdcf5f026c ("drm: sti: fix sub-components bind") moves
i2c adapter search and locking from .bind() to .probe(), however
proper error path in the modified .probe() is not implemented and
leftover of the related error path in .bind() remains. This change
fixes these issues.

Fixes: 53bdcf5f026c ("drm: sti: fix sub-components bind")
Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 49 ++
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 09e29e4..c23b580 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -700,18 +700,17 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)

encoder = sti_hdmi_find_encoder(drm_dev);
if (!encoder)
-   goto err_adapt;
+   return -EINVAL;

connector = devm_kzalloc(dev, sizeof(*connector), GFP_KERNEL);
if (!connector)
-   goto err_adapt;
-
+   return -EINVAL;

connector->hdmi = hdmi;

bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
if (!bridge)
-   goto err_adapt;
+   return -EINVAL;

bridge->driver_private = hdmi;
bridge->funcs = &sti_hdmi_bridge_funcs;
@@ -748,8 +747,7 @@ err_sysfs:
drm_connector_unregister(drm_connector);
 err_connector:
drm_connector_cleanup(drm_connector);
-err_adapt:
-   put_device(&hdmi->ddc_adapt->dev);
+
return -EINVAL;
 }

@@ -809,24 +807,29 @@ static int sti_hdmi_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hdmi-reg");
if (!res) {
DRM_ERROR("Invalid hdmi resource\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto release_adapter;
}
hdmi->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
-   if (!hdmi->regs)
-   return -ENOMEM;
+   if (!hdmi->regs) {
+   ret = -ENOMEM;
+   goto release_adapter;
+   }

if (of_device_is_compatible(np, "st,stih416-hdmi")) {
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
   "syscfg");
if (!res) {
DRM_ERROR("Invalid syscfg resource\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto release_adapter;
}
hdmi->syscfg = devm_ioremap_nocache(dev, res->start,
resource_size(res));
-   if (!hdmi->syscfg)
-   return -ENOMEM;
-
+   if (!hdmi->syscfg) {
+   ret = -ENOMEM;
+   goto release_adapter;
+   }
}

hdmi->phy_ops = (struct hdmi_phy_ops *)
@@ -836,25 +839,29 @@ static int sti_hdmi_probe(struct platform_device *pdev)
hdmi->clk_pix = devm_clk_get(dev, "pix");
if (IS_ERR(hdmi->clk_pix)) {
DRM_ERROR("Cannot get hdmi_pix clock\n");
-   return PTR_ERR(hdmi->clk_pix);
+   ret = PTR_ERR(hdmi->clk_pix);
+   goto release_adapter;
}

hdmi->clk_tmds = devm_clk_get(dev, "tmds");
if (IS_ERR(hdmi->clk_tmds)) {
DRM_ERROR("Cannot get hdmi_tmds clock\n");
-   return PTR_ERR(hdmi->clk_tmds);
+   ret = PTR_ERR(hdmi->clk_tmds);
+   goto release_adapter;
}

hdmi->clk_phy = devm_clk_get(dev, "phy");
if (IS_ERR(hdmi->clk_phy)) {
DRM_ERROR("Cannot get hdmi_phy clock\n");
-   return PTR_ERR(hdmi->clk_phy);
+   ret = PTR_ERR(hdmi->clk_phy);
+   goto release_adapter;
}

hdmi->clk_audio = devm_clk_get(dev, "audio");
if (IS_ERR(hdmi->clk_audio)) {
DRM_ERROR("Cannot get hdmi_audio clock\n");
-   return PTR_ERR(hdmi->clk_audio);
+   ret = PTR_ERR(hdmi->clk_audio);
+   goto release_adapter;
}

hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
@@ -867,7 +874,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
hdmi_irq_thread, IRQF_ONESHOT, dev_name(dev), hdmi);
if (ret) {
DRM_ERROR("Failed to register HDMI interrupt\n");
-   return ret;
+   goto release_adapter;
}

hdmi->reset = devm_reset_control_get(dev, "hdmi");
@@ -878,6 +885,12 @@ static int sti_hdmi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, hdmi);

return component_add(&pdev->dev, &sti_hdmi_ops);
+
+ release_adapter:
+   if (hdmi->ddc_adapt)
+   put_device(&hdmi->ddc_adapt->dev);

[PATCH 2/2] drm: sti_hdmi: use of_get_i2c_adapter_by_node interface

This change is needed to properly lock I2C bus device and driver,
which serve DDC lines. Without this change I2C bus driver module
may gone in runtime and this won't be noticed by the driver.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index c23b580..b892f29a 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -792,13 +792,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)

ddc = of_parse_phandle(pdev->dev.of_node, "ddc", 0);
if (ddc) {
-   hdmi->ddc_adapt = of_find_i2c_adapter_by_node(ddc);
-   if (!hdmi->ddc_adapt) {
-   of_node_put(ddc);
-   return -EPROBE_DEFER;
-   }
-
+   hdmi->ddc_adapt = of_get_i2c_adapter_by_node(ddc);
of_node_put(ddc);
+   if (!hdmi->ddc_adapt)
+   return -EPROBE_DEFER;
}

hdmi->dev = pdev->dev;
@@ -887,8 +884,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sti_hdmi_ops);

  release_adapter:
-   if (hdmi->ddc_adapt)
-   put_device(&hdmi->ddc_adapt->dev);
+   i2c_put_adapter(hdmi->ddc_adapt);

return ret;
 }
@@ -897,10 +893,9 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);

-   if (hdmi->ddc_adapt)
-   put_device(&hdmi->ddc_adapt->dev);
-
+   i2c_put_adapter(hdmi->ddc_adapt);
component_del(&pdev->dev, &sti_hdmi_ops);
+
return 0;
 }

-- 
2.5.0

[PATCH] drm/exynos: fix missed calling of drm_prime_gem_destroy()

HI Joonyoung,

2015-09-16 Joonyoung Shim :

> When obj->import_attach is existed, code calling drm_prime_gem_destroy()
> was removed from commit 67e93c808b48 ("drm/exynos: stop copying sg
> table"), and it's a fault.
> 
> The drm_prime_gem_destroy() is cleanup function which GEM drivers need
> to call when they use drm_gem_prime_import() to import dma-bufs, so
> exynos-drm driver using drm_gem_prime_import() needs calling
> drm_prime_gem_destroy().
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
>  2 files changed, 7 insertions(+), 4 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH] drm/exynos: fix layering violation of address

Hi Joonyoung,

2015-09-16 Joonyoung Shim :

> There is no guarantee that DMA addresses are the same as physical
> addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
> which can then be converted to a struct page.
> 
> Suggested-by: Russell King 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 1/4] drm/exynos: remove unnecessary NULL assignment

Hi Joonyoung,

2015-09-16 Joonyoung Shim :

> They will be freed right or was freed already, so NULL assignment is
> unnecessary.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 2/4] drm/exynos: staticize exynos_drm_gem_init()

Hi Joonyoung,

2015-09-16 Joonyoung Shim :

> The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
> static and don't export it.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 4 
>  2 files changed, 1 insertion(+), 6 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH v2 0/9] drm/exynos: rewrite fimg2d error handling

2015-09-21 Thread Emil Velikov

Hi Tobias,

On 8 September 2015 at 16:22, Tobias Jakobi
 wrote:
> Hello,
>
> during the discussion about the last patchset touching the
> fimg2d code, it became apparent that the error handling for
> the command submission is currently unsatisfactory.
>
> This series rewrites the handling. All functions that submit
> command buffers now first check if enough space is available
> and only then proceed to build the command buffers.
>
> In particular the command buffer is no longer left in a
> half-finished state, since parameters passed to the functions
> are now validated before command submission. For this some
> validation functions are introduced.
>
> This should also increase performance if the bottleneck is
> the submission part, since adding commands to the buffer
> is now more lightweight.
>
> Last but not least some prefix was added to messages printed
> by fprintf and printf, and the G2D context struct was moved
> out of the public header.
>
>
> Please review and let me know if I can improve anything!
>
Considering that there were no more objections with the series I've
scooped them up.

Thanks for clearing this and sticking around !
Emil

[PATCH 04/23] drm: Add drm structures for palette color property

2015-09-21 Thread Ville Syrjälä

On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi 
> 
> This patch adds new structures in DRM layer for Palette color
> correction.These structures will be used by user space agents
> to configure appropriate number of samples and Palette LUT for
> a platform.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  include/uapi/drm/drm.h | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index e3c642f..f72b916 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -840,6 +840,33 @@ struct drm_palette_caps {
>   __u32 num_samples_after_ctm;
>  };
>  
> +struct drm_r32g32b32 {
> + /*
> +  * Data is in U8.24 fixed point format.
> +  * All platforms support values within [0, 1.0] range,
> +  * for Red, Green and Blue colors.
> +  */
> + __u32 r32;
> + __u32 g32;
> + __u32 b32;
> +};
> +
> +struct drm_palette {
> + /* Structure version. Should be 1 currently */
> + __u32 version;

I don't think we want to version the blobs. For one, we don't have a way
for userspace to ask for a specific version, so the kernel wouldn't know
which version it should return to each client.

If we ever need to come up with new version of a specific blob, I think we
just have to define another property for it. Either that or we'd some kind
of client cap stuff to negotiate the used version between the kernel and
a specific client.

Well, I suppose we migth be able to borrow the "flags+extend at the end"
trick we sometimes use for ioctl parameters to work for blobs too. But I
have a feeling we don't want to go there.

So yeah, I think we should go with the "blob layout is fixed for each
property" approach. Versioning then happens by introducing new versions
of the same property if needed.

> + /*
> +  * This has to be a supported value during get call.
> +  * Feature will be disabled if this is 0 while set
> +  */
> + __u32 num_samples;
> + /*
> +  * Starting of palette LUT in R32G32B32 format.
> +  * Each of RGB value is in U8.24 fixed point format.
> +  * Actual number of samples will depend upon num_samples
> +  */
> + struct drm_r32g32b32 lut[0];
> +};
> +
>  /* typedef area */
>  #ifndef __KERNEL__
>  typedef struct drm_clip_rect drm_clip_rect_t;
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH libdrm 0/12] Rework drm{Get, Free}Devices and add drm{Get, Free}Device

2015-09-21 Thread Emil Velikov

On 10 September 2015 at 16:49, Alex Deucher  wrote:
> On Wed, Sep 9, 2015 at 1:21 PM, Emil Velikov  
> wrote:
>> Hello all,
>>
>> With this series, we add a couple of new functions drm{Get,Free}Device,
>> which will be used to query information about the opened device.
>>
>> To do that some refactoring was done, plus an extra test is added to
>> demonstrate how the drm{Get,Free}Device{,s} can be used.
>>
>> Any and all input will be appreciated.
>
> Looks like a nice clean up to me.
>
> Acked-by: Alex Deucher 
>
Thanks Alex. It's all in master now.

-Emil

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

--- Comment #5 from Kai  ---
Created attachment 118391
  --> https://bugs.freedesktop.org/attachment.cgi?id=118391&action=edit
Compressed shader that fails during compilation

Ok, I'm pretty sure now, that the game actually loads a Core Context, at least
the apitrace I've made (will be uploaded shortly, as soon as the compression is
done) shows a 4.1 context, when I do "lookup state".

Also, the game seems to choke on the missing AoA functionality or at least
doesn't check whether it can use AoA:
> 0:9(23): error: GL_ARB_arrays_of_arrays required for defining arrays of arrays

The shader triggering this is, however, a tessellation control shader, so maybe
Kenneth is right anyway (ie. I don't get the geometry with radeonsi because the
tessellation control shader fails to compile due to another extension, that is
as of yet missing while i965-supported GPUs don't get the geometry because
they're lacking tessellation to begin with).

The attached file is the shader triggering this error in the following call
sequence:
glCreateShader(GL_TESS_CONTROL_SHADER); # = 594
glShaderSource(594, 1, , NULL);
glCompileShader(594); # compile error

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/65d45bb4/attachment.html>

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #118391|0   |1
is obsolete||

--- Comment #6 from Ilia Mirkin  ---
Created attachment 118392
  --> https://bugs.freedesktop.org/attachment.cgi?id=118392&action=edit
shader that fails during compilation

[reattaching in a non-compressed format so that people can actually see it
without performing gymnastics]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/e5d6b13f/attachment.html>

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

--- Comment #7 from Ilia Mirkin  ---
(In reply to Kai from comment #5)
> Also, the game seems to choke on the missing AoA functionality or at least
> doesn't check whether it can use AoA:
> > 0:9(23): error: GL_ARB_arrays_of_arrays required for defining arrays of 
> > arrays

I guess line 9 is: out vec4 vControlPoint[][2];

Which should work without AoA. I wonder if this was recently broken by the AoA
support patches... Or maybe it started out broken.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/81227cf5/attachment-0001.html>

[alsa-devel] [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Jyri Sarha

On 09/21/15 18:08, Clemens Ladisch wrote:
>> >But there is no downside in using prepare callback.
> The prepare callback also can be called multiple times.  This certainly
> happens when the stream is stopped/restarted multiple times.
>
> If something does not need to be done again when a stream is restarted,
> then it should be done in the hw_params callback.

Oh, forgot about that. This would suggest to keep the stream header 
configuration in the hw_params().

Thanks,
Jyri

[PATCH v2 0/9] drm/exynos: rewrite fimg2d error handling

2015-09-21 Thread Tobias Jakobi

Hey Emil,

Emil Velikov wrote:
> Hi Tobias,
> 
> On 8 September 2015 at 16:22, Tobias Jakobi
>  wrote:
>> Hello,
>>
>> during the discussion about the last patchset touching the
>> fimg2d code, it became apparent that the error handling for
>> the command submission is currently unsatisfactory.
>>
>> This series rewrites the handling. All functions that submit
>> command buffers now first check if enough space is available
>> and only then proceed to build the command buffers.
>>
>> In particular the command buffer is no longer left in a
>> half-finished state, since parameters passed to the functions
>> are now validated before command submission. For this some
>> validation functions are introduced.
>>
>> This should also increase performance if the bottleneck is
>> the submission part, since adding commands to the buffer
>> is now more lightweight.
>>
>> Last but not least some prefix was added to messages printed
>> by fprintf and printf, and the G2D context struct was moved
>> out of the public header.
>>
>>
>> Please review and let me know if I can improve anything!
>>
> Considering that there were no more objections with the series I've
> scooped them up.
thanks a lot! Going to prepare the next batch then :)

With best wishes,
Tobias

> 
> Thanks for clearing this and sticking around !
> Emil
>

[Bug 92059] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

--- Comment #8 from Kai  ---
I've just uploaded two trace files to a password protected area â to prevent
unnecessary downloads â on my server:
-
<http://dev.carbon-project.org/debian/mesa.bugs/92059/shadowofmordor_tessellation.trace.xz>
-
<http://dev.carbon-project.org/debian/mesa.bugs/92059/shadowofmordor_no-tessellation.trace.xz>

They both display the issues described in comment #0 as well as attachment
118375 and attachment 118376. shadowofmordor_tessellation.trace was produced
with tessellation enabled in the graphics settings, while
shadowofmordor_no-tessellation.trace was created with tessellation disabled in
the graphics settings. All other settings were identical.

Known Mesa developers can ask me for password access, the password is merely
there to prevent unnecessary traffic. If you already have login credentials
from other bugs for which I provided trace files, those should continue to
work.


(In reply to Ilia Mirkin from comment #7)
> (In reply to Kai from comment #5)
> > Also, the game seems to choke on the missing AoA functionality or at least
> > doesn't check whether it can use AoA:
> > > 0:9(23): error: GL_ARB_arrays_of_arrays required for defining arrays of 
> > > arrays
> 
> I guess line 9 is: out vec4 vControlPoint[][2];
> 
> Which should work without AoA. I wonder if this was recently broken by the
> AoA support patches... Or maybe it started out broken.

I might have missed something, but I'm not seeing GL_ARB_arrays_of_arrays being
exposed on radeonsi?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/99bf4383/attachment.html>

[PATCH 3/4] drm/exynos: cleanup function calling written twice

Hi Joonyoung,

2015-09-16 Joonyoung Shim :

> By if statment, some function callings are written twice. It needs
> several line feed by indentation in if statment. Make to one function
> calling from outside if statment.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 56 
> ++---
>  1 file changed, 23 insertions(+), 33 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 4/4] drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl

Hi Joonyoung,

2015-09-16 Joonyoung Shim :

> The beginning of statement in function is next line of a brace.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

Kai  changed:

   What|Removed |Added

Summary|Missing textures and|[radeonsi, apitrace]
   |geometry in "Middle-earth:  |Missing textures and
   |Shadow of Mordor"   |geometry in "Middle-earth:
   ||Shadow of Mordor"
 Whiteboard||apitrace

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/0c6fdc36/attachment.html>

[git pull] drm for 4.3

2015-09-21 Thread Dave Jones

On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
 > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
 >  > 
 >  > Hi Linus,
 >  > 
 >  > This is the main pull request for the drm for 4.3. Nouveau is probably 
 > the biggest
 >  > amount of changes in here, since it missed 4.2. Highlights below, along 
 > with the usual
 >  > bunch of fixes. There are a few minor conflicts with your tree but 
 > nothing 
 >  > you can't handle. All stuff outside drm should have applicable acks.
 >  > 
 >  > Highlights:
 >  > 
 >  > ...
 >  > i915:
 >  >   Skylake support enabled by default
 >  >   legacy modesetting using atomic infrastructure
 >  >   Skylake fixes
 >  >   GEN9 workarounds
 > 
 > Since this merge, I'm seeing this twice during boot..

And still there in -rc2.  Several other people reported this too,
and they also got no reponse.

I'll start bisecting when I get home tonight. It shouldn't be too hard,
as 4.2 was fine.

Dave

 > [ cut here ]
 > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
 > assert_planes_disabled+0xdf/0x140()
 > plane A assertion failure, should be disabled but not
 > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
 > Workqueue: events_unbound async_run_entry_fn
 >  0561 88050392b6f8 8d7dccce 88050392b740
 >  88050392b730 8d079ee2 880500a6 
 >    8805008e99c8 88050392b790
 > Call Trace:
 >  [] dump_stack+0x4e/0x79
 >  [] warn_slowpath_common+0x82/0xc0
 >  [] warn_slowpath_fmt+0x4c/0x50
 >  [] assert_planes_disabled+0xdf/0x140
 >  [] intel_disable_pipe+0x4b/0x2c0
 >  [] haswell_crtc_disable+0x8a/0x2e0
 >  [] intel_atomic_commit+0xff/0x1320
 >  [] ? drm_atomic_check_only+0x21e/0x550
 >  [] drm_atomic_commit+0x37/0x60
 >  [] drm_atomic_helper_set_config+0x1c5/0x430
 >  [] drm_mode_set_config_internal+0x65/0x110
 >  [] restore_fbdev_mode+0xbe/0xe0
 >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
 >  [] drm_fb_helper_set_par+0x2d/0x50
 >  [] intel_fbdev_set_par+0x1a/0x60
 >  [] fbcon_init+0x545/0x5d0
 >  [] visual_init+0xca/0x130
 >  [] do_bind_con_driver+0x1c5/0x3b0
 >  [] do_take_over_console+0x149/0x1a0
 >  [] do_fbcon_takeover+0x57/0xb0
 >  [] fbcon_event_notify+0x66c/0x760
 >  [] notifier_call_chain+0x3e/0xb0
 >  [] __blocking_notifier_call_chain+0x4d/0x70
 >  [] blocking_notifier_call_chain+0x16/0x20
 >  [] fb_notifier_call_chain+0x1b/0x20
 >  [] register_framebuffer+0x1e7/0x300
 >  [] drm_fb_helper_initial_config+0x252/0x3e0
 >  [] intel_fbdev_initial_config+0x1b/0x20
 >  [] async_run_entry_fn+0x4a/0x140
 >  [] process_one_work+0x1fd/0x670
 >  [] ? process_one_work+0x16c/0x670
 >  [] worker_thread+0x4e/0x450
 >  [] ? process_one_work+0x670/0x670
 >  [] kthread+0x101/0x120
 >  [] ? kthread_create_on_node+0x250/0x250
 >  [] ret_from_fork+0x3f/0x70
 >  [] ? kthread_create_on_node+0x250/0x250
 > ---[ end trace 54cab2e0c772d5d9 ]---
 > 
 > 
 > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
 > Processor Integrated Graphics Controller (rev 06)

[PATCH RFC v4 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

2015-09-21 Thread Rob Herring

On 09/18/2015 06:06 AM, Jyri Sarha wrote:
> From: Jean-Francois Moine 
> 
> Two kinds of ports may be declared in a DT graph of ports: video and audio.
> This patch accepts the port value from a video port as an alternative
> to the video-ports property.
> It also accepts audio ports in the case the transmitter is not used as
> a slave encoder.
> The new file include/sound/tda998x.h prepares to the definition of
> a tda998x CODEC.
> 
> Signed-off-by: Jean-Francois Moine 
> Signed-off-by: Jyri Sarha 
> ---
>  .../devicetree/bindings/drm/i2c/tda998x.txt| 51 
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 90 
> +++---
>  include/sound/tda998x.h|  8 ++
>  3 files changed, 140 insertions(+), 9 deletions(-)
>  create mode 100644 include/sound/tda998x.h
> 
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index e9e4bce..35f6a80 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -16,6 +16,35 @@ Optional properties:
>  
>- video-ports: 24 bits value which defines how the video controller
>   output is wired to the TDA998x input - default: <0x230145>
> + This property is not used when ports are defined.
> +
> +Optional nodes:
> +
> +  - port: up to three ports.
> + The ports are defined according to [1].
> +
> +Video port.
> + There may be only one video port.
> + This one must contain the following property:
> +
> + - port-type: must be "rgb"

Why do you need this if there is no other choice? The port number should
define which one is video.

> +
> + and may contain the optional property:
> +
> + - reg: 24 bits value which defines how the video controller
> + output is wired to the TDA998x input (video pins)
> + When absent, the default value is <0x230145>.

I'm failing to decode how this value works. In any case, I would keep
this as a vendor specific property rather than abusing reg.

> +
> +Audio ports.
> + There may be one or two audio ports.
> + These ones must contain the following properties:
> +
> + - port-type: must be "i2s" or "spdif"
> +
> + - reg: 8 bits value which defines how the audio controller
> + output is wired to the TDA998x input (audio pins)

reg is 32-bits.

> +
> +[1] Documentation/devicetree/bindings/graph.txt
>  
>  Example:
>  
> @@ -26,4 +55,26 @@ Example:
>   interrupts = <27 2>;/* falling edge */
>   pinctrl-0 = <&pmx_camera>;
>   pinctrl-names = "default";
> +
> + port at 230145 {
> + port-type = "rgb";
> + reg = <0x230145>;
> + hdmi_0: endpoint {
> + remote-endpoint = <&lcd0_0>;
> + };
> + };
> + port at 3 { /* AP1 = I2S */

Is 3 significant? What happened to 0-2?

> + port-type = "i2s";
> + reg = <0x03>;
> + tda998x_i2s: endpoint {
> + remote-endpoint = <&audio1_i2s>;
> + };
> + };
> + port at 4 {  /* AP2 = S/PDIF */
> + port-type = "spdif";
> + reg = <0x04>;
> + tda998x_spdif: endpoint {
> + remote-endpoint = <&audio1_spdif1>;
> + };
> + };
>   };
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 424228b..0952eac 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  
> @@ -47,6 +48,8 @@ struct tda998x_priv {
>   wait_queue_head_t wq_edid;
>   volatile int wq_edid_wait;
>   struct drm_encoder *encoder;
> +
> + struct tda998x_audio audio;
>  };
>  
>  #define to_tda998x_priv(x)  ((struct tda998x_priv 
> *)to_encoder_slave(x)->slave_priv)
> @@ -774,6 +777,8 @@ static void tda998x_encoder_set_config(struct 
> tda998x_priv *priv,
>   (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
>  
>   priv->params = *p;
> + priv->audio.port_types[0] = p->audio_format;
> + priv->audio.ports[0] = p->audio_cfg;
>  }
>  
>  static void tda998x_encoder_dpms(struct tda998x_priv *priv, int mode)
> @@ -1230,9 +1235,57 @@ static struct drm_encoder_slave_funcs 
> tda998x_encoder_slave_funcs = {
>  
>  /* I2C driver functions */
>  
> +static int tda998x_parse_ports(struct tda998x_priv *priv,
> + struct device_node *np)
> +{
> + struct device_node *of_port;
> + const char *port_type;
> + int ret, audio_inde

[PATCH 12/31] drm/amdgpu: use kmemdup rather than duplicating its implementation

2015-09-21 Thread Alex Deucher

On Wed, Sep 16, 2015 at 12:21 PM, Christian KÃ¶nig
 wrote:
> On 16.09.2015 11:56, Andrzej Hajda wrote:
>>
>> Ping.
>>
>> Regards
>> Andrzej
>>
>> On 08/07/2015 09:59 AM, Andrzej Hajda wrote:
>>>
>>> The patch was generated using fixed coccinelle semantic patch
>>> scripts/coccinelle/api/memdup.cocci [1].
>>>
>>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>>>
>>> Signed-off-by: Andrzej Hajda 
>
>
> Somehow missed that. Patch is Reviewed-by: Christian KÃ¶nig
> .

I hadn't seen it either.  Applied now.

Alex

>
> Regards,
> Christian.
>
>
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
>>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> index 8da6424..94bd992 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> @@ -549,12 +549,10 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo,
>>> void *metadata,
>>> if (metadata == NULL)
>>> return -EINVAL;
>>>   - buffer = kzalloc(metadata_size, GFP_KERNEL);
>>> +   buffer = kmemdup(metadata, metadata_size, GFP_KERNEL);
>>> if (buffer == NULL)
>>> return -ENOMEM;
>>>   - memcpy(buffer, metadata, metadata_size);
>>> -
>>> kfree(bo->metadata);
>>> bo->metadata_flags = flags;
>>> bo->metadata = buffer;
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

2015-09-21 Thread Matt Roper

Starting with commit

commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
Author: Rob Clark 
Date:   Tue Aug 25 15:36:00 2015 -0400

drm/i915: enable atomic fb-helper

I've been seeing some panics on i915 when the DRM master shuts down that appear
to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
dropping our initial FB's reference count to 0 and freeing it, which causes a
crash when we try to restore it later).  Digging deeper, the state FB
refcounting is working as expected, but we seem to be missing proper
refcounting on the legacy plane->fb pointers in the new atomic fbdev code.

Tracking plane->old_fb and then doing a ref/unref at the end of the
fbdev restore like we do in the legacy ioctl's ensures we don't miscount
references on plane->fb and avoids the panics.

Cc: Rob Clark 
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Matt Roper 
---
I don't see any existing bugzilla's (or mailing list complaints) for this,
which surprises me a bit since it seems to be very easy to reproduce for me on
latest drm-intel-nightly running on IVB...boot the system, load X, kill X,
panic.

 drivers/gpu/drm/drm_fb_helper.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64fc5ca..2149ac7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -352,6 +352,8 @@ retry:
drm_for_each_plane(plane, dev) {
struct drm_plane_state *plane_state;

+   plane->old_fb = plane->fb;
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -385,6 +387,14 @@ retry:
if (ret != 0)
goto fail;

+   drm_for_each_plane(plane, dev) {
+   if (plane->fb)
+   drm_framebuffer_reference(plane->fb);
+   if (plane->old_fb)
+   drm_framebuffer_unreference(plane->old_fb);
+   plane->old_fb = NULL;
+   }
+
return 0;

 fail:
-- 
2.1.4

[PATCH v4 0/16] Add Analogix Core Display Port Driver

Hi Thierry,

Thanks for your suggest :)

On 09/21/2015 05:15 PM, Thierry Reding wrote:
> On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
>> Hi Heiko,
>>
>> On 09/02/2015 10:15 AM, Yakir Yang wrote:
>>> Hi Heiko,
>>>
>>> å¨ 09/02/2015 05:47 AM, Heiko Stuebner åé:
 Hi Yakir,

 Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
> dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are
> different
> between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> debug
> register).
>
> I have verified this series on two kinds of rockchip platform board,
> one
> is rk3288 sdk board which connect with a 2K display port monitor, the
> other
> is google jerry chromebook which connect with a eDP screen
> "cnm,n116bgeea2",
> both of them works rightlly.
 it looks like during the rebase something did go wrong and I found some
 issues
 I mentioned in the replies to individual patches.

 I did prepare a branch based on mainline [0] with both the old and the
 new edp
 driver - rk3288_veyron_defconfig build both drivers into the image.

 While the old driver still works, I wasn't able to make the new one work
 yet
 ... the drm core does find the connector, but not that anything is
 connected
 to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
 interesting before then.
>>> Many thanks for your comment and debug, I would rebase on your
>>> "edp-with-veyron" branch and fix the broken, make sure v6 would
>>> work rightly at least in your side and my side.
>> Just like we talk off line, I guess there are two tricky questions which
>> make analogix_dp just crash/failed on rockchip platform:
>>
>> -  One is how to reach a agreement with the common way to register
>> connector. There would be a conflict with Exynos & IMX & Rockchip.
>>   On analogix_dp thread, Exynos want to register connector when that
>> connector is ready.
>>   On dw_hdmi thread, IMX want to register connector when all component is
>> already.
>>   So Exynos & IMX & Rockchip should reach a common way to register
>> connector to fix this issue.
>>
>> -  The other is atomic API.
>>The rockchip drm haven't implemented the atomic API, but the original
>> exynos_dp have used the atomic API on connector helper function. That's why
>> analogix_dp just keep crash on your side.
> There's really no reason not to convert Rockchip to atomic. It will have
> to happen eventually anyway.

Do agree on this point, and I see Tomasz Figa have done some WIP
works on implementing the atomic_commit, maybe would upstream
in further.(https://chromium-review.googlesource.com/#/c/284560/1)


> That said, there's another option that would allow you to side-step both
> of the above problems at the same time. If you turn the common code into
> a helper library that should give you enough flexibility to integrate it
> into all existing users. For example you could leave out the connector
> registration and let the drivers do that. Similarly since the helpers
> are only hooked up at registration time you could probably find a way to
> share the low-level code but again leave it up to the drivers to glue it
> all together at registration time (drivers could wrap the low-level code
> with atomic or non-atomic callbacks).

Wow, sounds good, but I'm not sure I understand this rightly. Do you
mean that I could support two kinds of callbacks in analogix_dp_core
driver, and export them out. And move the connector registration code
into the helper driver (like exynos_dp.c), so helper driver could chose to
use the atomic or non-atomic callbacks. like:

-- analogix_dp_core.c 

...
struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
 .dpms = drm_atomic_helper_connector_dpms,
 .fill_modes = drm_helper_probe_single_connector_modes,
 .detect = analogix_dp_detect,
 .destroy = analogix_dp_connector_destroy,
 .reset = drm_atomic_helper_connector_reset,
 .atomic_duplicate_state = 
drm_atomic_helper_connector_duplicate_state,
 .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
EXPORT_SYMBOL(analog

[PATCH v4 0/16] Add Analogix Core Display Port Driver

2015-09-21 Thread Thierry Reding

g users. For example you could leave out the connector
> >registration and let the drivers do that. Similarly since the helpers
> >are only hooked up at registration time you could probably find a way to
> >share the low-level code but again leave it up to the drivers to glue it
> >all together at registration time (drivers could wrap the low-level code
> >with atomic or non-atomic callbacks).
> 
> Wow, sounds good, but I'm not sure I understand this rightly. Do you
> mean that I could support two kinds of callbacks in analogix_dp_core
> driver, and export them out. And move the connector registration code
> into the helper driver (like exynos_dp.c), so helper driver could chose to
> use the atomic or non-atomic callbacks. like:
> 
> -- analogix_dp_core.c
> 
> ...
> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
> .dpms = drm_atomic_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = analogix_dp_detect,
> .destroy = analogix_dp_connector_destroy,
> .reset = drm_atomic_helper_connector_reset,
> .atomic_duplicate_state =
> drm_atomic_helper_connector_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
> EXPORT_SYMBOL(analogix_dp_connector_atomic_funcs);
> 
> struct drm_connector_funcs analogix_dp_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = analogix_dp_detect,
> .destroy = analogix_dp_connector_destroy,
> };
> EXPORT_SYMBOL(analogix_dp_connector_funcs);
> 
> struct drm_connector_helper_funcs analogix_dp_connector_helper_funcs = {
> .get_modes = analogix_dp_get_modes,
> .best_encoder = analogix_dp_best_encoder,
> };
> EXPORT_SYMBOL(analogix_dp_connector_helper_funcs);
> ...
> 
> -- exynos_dp
> 
> ret = drm_connector_init(dp->drm_dev, connector,
> &analogix_dp_connector_atomic_funcs,
>  DRM_MODE_CONNECTOR_eDP);
> if (ret) {
> DRM_ERROR("Failed to initialize connector with drm\n");
> return ret;
> }
> 
> drm_connector_helper_add(connector,
> &analogix_dp_connector_helper_funcs);
> drm_connector_register(connector);
> drm_mode_connector_attach_encoder(connector, encoder);
> 
> -- analogix_dp-rockchip
> 
> ret = drm_connector_init(dp->drm_dev, connector,
>  &analogix_dp_connector_funcs,
>  DRM_MODE_CONNECTOR_eDP);
> if (ret) {
> DRM_ERROR("Failed to initialize connector with drm\n");
> return ret;
> }
> 
> drm_connector_helper_add(connector,
> &analogix_dp_connector_helper_funcs);
> drm_mode_connector_attach_encoder(connector, encoder);
> 
> 
> Are those code corresponding to your suggestion.   :)

Yes, that looks about right. You could also move the implementations
into the Exynos and Rockchip drivers, respectively, if they're only used
from one place. Then you can simply export the low-level analogix_dp_*()
functions. That might give you even more flexibility, but the above
would probably work well enough.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/1b50ec3d/attachment-0001.sig>

[PATCH v4 0/16] Add Analogix Core Display Port Driver

maybe would upstream
>> in further.(https://chromium-review.googlesource.com/#/c/284560/1)
>>
>>
>>> That said, there's another option that would allow you to side-step both
>>> of the above problems at the same time. If you turn the common code into
>>> a helper library that should give you enough flexibility to integrate it
>>> into all existing users. For example you could leave out the connector
>>> registration and let the drivers do that. Similarly since the helpers
>>> are only hooked up at registration time you could probably find a way to
>>> share the low-level code but again leave it up to the drivers to glue it
>>> all together at registration time (drivers could wrap the low-level code
>>> with atomic or non-atomic callbacks).
>> Wow, sounds good, but I'm not sure I understand this rightly. Do you
>> mean that I could support two kinds of callbacks in analogix_dp_core
>> driver, and export them out. And move the connector registration code
>> into the helper driver (like exynos_dp.c), so helper driver could chose to
>> use the atomic or non-atomic callbacks. like:
>>
>> -- analogix_dp_core.c
>> 
>> ...
>> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
>>  .dpms = drm_atomic_helper_connector_dpms,
>>  .fill_modes = drm_helper_probe_single_connector_modes,
>>  .detect = analogix_dp_detect,
>>  .destroy = analogix_dp_connector_destroy,
>>  .reset = drm_atomic_helper_connector_reset,
>>  .atomic_duplicate_state =
>> drm_atomic_helper_connector_duplicate_state,
>>  .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>> EXPORT_SYMBOL(analogix_dp_connector_atomic_funcs);
>>
>> struct drm_connector_funcs analogix_dp_connector_funcs = {
>>  .dpms = drm_helper_connector_dpms,
>>  .fill_modes = drm_helper_probe_single_connector_modes,
>>  .detect = analogix_dp_detect,
>>  .destroy = analogix_dp_connector_destroy,
>> };
>> EXPORT_SYMBOL(analogix_dp_connector_funcs);
>>
>> struct drm_connector_helper_funcs analogix_dp_connector_helper_funcs = {
>>  .get_modes = analogix_dp_get_modes,
>>  .best_encoder = analogix_dp_best_encoder,
>> };
>> EXPORT_SYMBOL(analogix_dp_connector_helper_funcs);
>> ...
>>
>> -- exynos_dp
>> 
>>  ret = drm_connector_init(dp->drm_dev, connector,
>> &analogix_dp_connector_atomic_funcs,
>>   DRM_MODE_CONNECTOR_eDP);
>>  if (ret) {
>>  DRM_ERROR("Failed to initialize connector with drm\n");
>>  return ret;
>>  }
>>
>>  drm_connector_helper_add(connector,
>> &analogix_dp_connector_helper_funcs);
>>  drm_connector_register(connector);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>
>> -- analogix_dp-rockchip
>> 
>>  ret = drm_connector_init(dp->drm_dev, connector,
>>   &analogix_dp_connector_funcs,
>>   DRM_MODE_CONNECTOR_eDP);
>>  if (ret) {
>>  DRM_ERROR("Failed to initialize connector with drm\n");
>>  return ret;
>>  }
>>
>>  drm_connector_helper_add(connector,
>> &analogix_dp_connector_helper_funcs);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>
>>
>> Are those code corresponding to your suggestion.   :)
> Yes, that looks about right. You could also move the implementations
> into the Exynos and Rockchip drivers, respectively, if they're only used
> from one place. Then you can simply export the low-level analogix_dp_*()
> functions. That might give you even more flexibility, but the above
> would probably work well enough.

Wow, much better, so I just need to export two low-level functions,

  * analogix_dp_detect()
  * analogix_dp_get_modes()

Pretty cool.

Thanks,
- Yakir

> Thierry

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/5407d3db/attachment-0001.html>

[RFC 3/5] ASoC: codec: hdmi drm codec driver

Add a generic codec to interface audio with DRM drivers

Signed-off-by: Arnaud Pouliquen 
---
 include/sound/hdmi_drm.h|  16 ++
 sound/soc/codecs/Kconfig|   4 ++
 sound/soc/codecs/Makefile   |   2 +
 sound/soc/codecs/hdmi_drm.c | 125 
 4 files changed, 147 insertions(+)
 create mode 100644 include/sound/hdmi_drm.h
 create mode 100644 sound/soc/codecs/hdmi_drm.c

diff --git a/include/sound/hdmi_drm.h b/include/sound/hdmi_drm.h
new file mode 100644
index 000..0146b88
--- /dev/null
+++ b/include/sound/hdmi_drm.h
@@ -0,0 +1,16 @@
+/*
+ * Interface for HDMI DRM  codec
+ *
+ * Author: Arnaud Pouliquen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __HDMI_DRM__H__
+#define __HDMI_DRM__H__
+
+int hdmi_drm_codec_register(struct device *dev);
+void hdmi_drm_codec_unregister(struct device *dev);
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0c9733e..922af30 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -80,6 +80,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_HDMI_CODEC
+   select SND_SOC_HDMI_DRM_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM1792A if SPI_MASTER
select SND_SOC_PCM3008
@@ -445,6 +446,9 @@ config SND_SOC_DMIC
 config SND_SOC_HDMI_CODEC
tristate "HDMI stub CODEC"

+config SND_SOC_HDMI_DRM_CODEC
+   tristate "HDMI DRM CODEC"
+
 config SND_SOC_ES8328
tristate "Everest Semi ES8328 CODEC"

diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 4a32077..c92aaf7 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -73,6 +73,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-hdmi-codec-objs := hdmi.o
+snd-soc-hdmi-drm-codec-objs := hdmi_drm.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm1792a-codec-objs := pcm1792a.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -265,6 +266,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
+obj-$(CONFIG_SND_SOC_HDMI_DRM_CODEC) += snd-soc-hdmi-drm-codec.o
 obj-$(CONFIG_SND_SOC_PCM1681)  += snd-soc-pcm1681.o
 obj-$(CONFIG_SND_SOC_PCM1792A) += snd-soc-pcm1792a-codec.o
 obj-$(CONFIG_SND_SOC_PCM3008)  += snd-soc-pcm3008.o
diff --git a/sound/soc/codecs/hdmi_drm.c b/sound/soc/codecs/hdmi_drm.c
new file mode 100644
index 000..2df9a8f
--- /dev/null
+++ b/sound/soc/codecs/hdmi_drm.c
@@ -0,0 +1,125 @@
+/*
+ * ALSA SoC codec driver for DRM HDMI device.
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Arnaud Pouliquen 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct hdmi_drm_dai_data {
+   struct drm_bridge *bridge;
+};
+
+static const struct snd_soc_dapm_widget hdmi_drm_widgets[] = {
+   SND_SOC_DAPM_OUTPUT("TX"),
+};
+
+static const struct snd_soc_dapm_route hdmi_drm_routes[] = {
+   { "TX", NULL, "Playback" },
+};
+
+int hdmi_drm_dai_prepare(struct snd_pcm_substream *substream,
+struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv = snd_soc_dai_get_drvdata(dai);
+
+   dev_err(dai->dev, "%s: enter for bridge %p\n", __func__, priv->bridge);
+   drm_audio_bridge_pre_enable(priv->bridge);
+   return 0;
+}
+
+int hdmi_drm_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv = snd_soc_dai_get_drvdata(dai);
+
+   dev_err(dai->dev, "%s: enter\n", __func__);
+   switch (cmd) {
+   case SNDRV_PCM_TRIGGER_START:
+   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+   case SNDRV_PCM_TRIGGER_RESUME:
+   drm_audio_bridge_enable(priv->bridge);
+   break;
+
+   case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+   case SNDRV_PCM_TRIGGER_STOP:
+   case SNDRV_PCM_TRIGGER_SUSPEND:
+   drm_audio_bridge_disable(priv->bridge);
+   break;
+   }
+
+   return 0;
+}
+
+static int st_hdmi_dai_probe(struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv;
+
+   dev_err(dai->dev, "%s: enter\n", __func__);
+   priv = devm_kzalloc(dai->dev, sizeof(*priv), GFP_KERNEL);
+
+   priv->bridge = of_drm_find_bridge(dai->dev->of_node);
+
+   dev_err(dai->dev, "%s: bridge %p\n", __func__, priv->bridge);
+
+   snd_soc_dai_set_drvdata(dai, priv);
+
+   return 0;
+}
+
+static const struct snd_soc_dai_ops hdmi_drm_codec_ops = {
+   .prepa

[RFC 0/5] another generic audio hdmi codec proposal

I 'm working on HDMI implementation for sti platform. 
As some discussions are on going for audio on HDMI. Here is the begin of my 
work...

This patch set is a tentative to implement a generic code for the HDMI audio.
Main concept are aligned with solution proposeded for TI platform. 
 -  ASoC codec driver registered by DRM driver
 -  ASOC driver is a generic driver.
 -  compatible with simple card

 Difference is that i propose a DRM generic interface based on bridge structure.
 Advantage is that all data exchanges are done through the DRM API.

 I think also that some helper functions could been used for N and CTS 
parameters calculation,
 as suggested by Russell King in a previous mail.

 I full aware that some features (like ELD and info frame) are partially or not 
implemented in my patches. 
 This patch set is more a skeleton than a full implementation...
 I just post it to suggest a possible DRM API.

Arnaud Pouliquen (5):
  video: hdmi: add help function for N and cts
  drm: add helper functionto add audio capabilities for bridge
  ASoC: codec:  hdmi drm codec driver
  drm: sti: connect audio driver
  DT: sti: add audio HDMI dai link in audio card

 arch/arm/boot/dts/stih410.dtsi   |   4 +-
 arch/arm/boot/dts/stihxxx-b2120.dtsi |  21 +
 arch/arm/configs/multi_v7_defconfig  |   1 +
 drivers/gpu/drm/drm_bridge.c | 114 +++
 drivers/gpu/drm/sti/sti_hdmi.c   | 146 +++---
 drivers/gpu/drm/sti/sti_hdmi.h   |   3 +
 drivers/video/hdmi.c | 148 +++
 include/drm/drm_crtc.h   |  31 
 include/linux/hdmi.h |  24 ++
 include/sound/hdmi_drm.h |  16 
 sound/soc/codecs/Kconfig |   4 +
 sound/soc/codecs/Makefile|   2 +
 sound/soc/codecs/hdmi_drm.c  | 125 +
 13 files changed, 625 insertions(+), 14 deletions(-)
 create mode 100644 include/sound/hdmi_drm.h
 create mode 100644 sound/soc/codecs/hdmi_drm.c

-- 
1.9.1

[PATCH 00/38] Fixes related to incorrect usage of unsigned types

Hi,

This is set of independent patches. The only connection between
them is that they try to address problems spotted by proposed
coccinelle semantic patch unsigned_lesser_than_zero.cocci[1].

Semantic patch finds comparisons of types:
unsigned < 0
unsigned >= 0
The former is always false, the latter is always true.
Such comparisons are useless, so theoretically they could be
safely removed, but their presence quite often indicates bugs.

This patchset contains mainly real bug fixes(patches 01-25),
usually type fixes.

Patches 26-37 removes unnecessary checks. Semantic patch found
much more such places (more than 80), but since every case needs
some analysis I have decided to leave them for antoher patchset.

The last patch should be probably replaced with something better,
I guess it should be treated rather as bug report.

The patches are based on linux-next (20150918).

Patches were only compile tested, so please look at them carefully.

I have sent all patches to linux-kernel mailing list. Individual
patches + cover letter went also to apropriate addresses,
according to get_maintainers.pl script.

One more thing. To fullfill different maintaner/subsystem requirements
I have decided to prefix patch subjects with prefixes present in
last 10 commits for affected files. I am not sure if this is the
best solution, if there are any better solutions please let me know :)

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Regards
Andrzej


Andrzej Hajda (38):
  arm-cci: fix handling cpumask_any_but return value
  bus: arm-ccn: fix handling cpumask_any_but return value
  drm/i915: fix handling gen8_emit_flush_coherentl3_wa result
  IB/ehca: fix handling idr_alloc result
  staging: lustre: fix handling lustre_posix_acl_xattr_filter result
  tty: serial: lpc32xx_hs: fix handling platform_get_irq result
  usb: host: ehci-msm: fix handling platform_get_irq result
  openvswitch: fix handling result of ipv6_skip_exthdr
  selftests/timers: fix write return value handlng
  hwrng: fix handling platform_get_irq
  HSI: omap_ssi: fix handling ida_simple_get result
  HSI: omap_ssi_port: fix handling of_get_named_gpio result
  ARM: shmobile: apmu: correct type of CPU id
  clk: vt8500: fix sign of possible PLL values
  drm/layerscape: fix handling fsl_dcu_drm_plane_index result
  gpu: ipu-v3: fix div_ratio type
  isdn: hisax: fix frame calculation
  net/ibm/emac: fix type of phy_mode
  net: stmmac: fix type of entry variable
  net: brcm80211: fix range check
  mwifiex: fix comparison expression
  orinoco: fix checking for default value
  rndis_wlan: fix checking for default value
  rtc: opal: fix type of token
  staging: media: davinci_vpfe: fix ipipe_mode type
  staging: lustre: remove invalid check
  usbnet: remove invalid check
  video/omap: remove invalid check
  Input: touchscreen: atmel: remove invalid check
  leds: flash: remove invalid check
  leds: tca6507: remove invalid check
  fs/cachefiles: remove invalid checks
  mm/memblock.c: remove invalid check
  perf: remove invalid check
  ptrace: remove invalid check
  MIPS: remove invalid check
  zlib_deflate/deftree: change always true condition to 1
  drm/radeon: simplify boot level calculation

 arch/arm/mach-shmobile/platsmp-apmu.c   |  2 +-
 arch/mips/mm/sc-mips.c  |  4 ++--
 arch/sh/kernel/ptrace_32.c  |  3 +--
 arch/sh/kernel/ptrace_64.c  |  4 ++--
 drivers/bus/arm-cci.c   |  2 +-
 drivers/bus/arm-ccn.c   |  2 +-
 drivers/char/hw_random/xgene-rng.c  |  7 ---
 drivers/clk/clk-vt8500.c|  6 +++---
 drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 11 +--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  3 ++-
 drivers/gpu/drm/i915/intel_lrc.c|  7 ---
 drivers/gpu/drm/radeon/kv_dpm.c | 11 +--
 drivers/gpu/ipu-v3/ipu-csi.c|  2 +-
 drivers/hsi/controllers/omap_ssi.c  |  7 +++
 drivers/hsi/controllers/omap_ssi_port.c |  8 
 drivers/input/touchscreen/atmel_mxt_ts.c|  2 +-
 drivers/isdn/hisax/hfc4s8s_l1.c | 10 +-
 drivers/leds/led-class-flash.c  |  2 +-
 drivers/leds/leds-tca6507.c |  2 +-
 drivers/net/ethernet/ibm/emac/core.h|  2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   |  2 +-
 drivers/net/usb/lan78xx.c   |  5 -
 drivers/net/usb/smsc75xx.c  |  5 -
 drivers/net/usb/smsc95xx.c  |  5 -
 drivers/net/wireless/brcm80211/brcmsmac/main.c  |  2 +-
 drivers/net/wireless/mwifiex/11n_rxreorder.c|  4 ++--
 drivers/net/wireless/orinoco/cfg.c  |  6 +++---
 drivers/net/wireless/rndis_wlan.c   |  2 +-
 drivers/

[RFC 4/5] drm: sti: connect audio driver

Add management of the audio bridge

Signed-off-by: Arnaud Pouliquen 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 146 +
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 2 files changed, 137 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 06595e9..d324e0a 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -17,6 +17,8 @@
 #include 
 #include 

+#include 
+
 #include "sti_hdmi.h"
 #include "sti_hdmi_tx3g4c28phy.h"
 #include "sti_hdmi_tx3g0c55phy.h"
@@ -34,6 +36,8 @@
 #define HDMI_DFLT_CHL0_DAT  0x0110
 #define HDMI_DFLT_CHL1_DAT  0x0114
 #define HDMI_DFLT_CHL2_DAT  0x0118
+#define HDMI_AUDIO_CFG  0x0200
+#define HDMI_SPDIF_FIFO_STATUS  0x0204
 #define HDMI_SW_DI_1_HEAD_WORD  0x0210
 #define HDMI_SW_DI_1_PKT_WORD0  0x0214
 #define HDMI_SW_DI_1_PKT_WORD1  0x0218
@@ -43,6 +47,9 @@
 #define HDMI_SW_DI_1_PKT_WORD5  0x0228
 #define HDMI_SW_DI_1_PKT_WORD6  0x022C
 #define HDMI_SW_DI_CFG  0x0230
+#define HDMI_SAMPLE_FLAT_MASK   0x0244
+#define HDMI_AUDN   0x0400
+#define HDMI_AUD_CTS0x0404
 #define HDMI_SW_DI_2_HEAD_WORD  0x0600
 #define HDMI_SW_DI_2_PKT_WORD0  0x0604
 #define HDMI_SW_DI_2_PKT_WORD1  0x0608
@@ -52,6 +59,7 @@
 #define HDMI_SW_DI_2_PKT_WORD5  0x0618
 #define HDMI_SW_DI_2_PKT_WORD6  0x061C

+
 #define HDMI_IFRAME_SLOT_AVI1
 #define HDMI_IFRAME_SLOT_AUDIO  2

@@ -109,6 +117,27 @@

 #define HDMI_STA_SW_RST BIT(1)

+#define HDMI_AUD_CFG_8CHBIT(0)
+#define HDMI_AUD_CFG_SPDIF_DIV_2  BIT(1)
+#define HDMI_AUD_CFG_SPDIF_DIV_3  BIT(2)
+#define HDMI_AUD_CFG_SPDIF_CLK_DIV_4 (BIT(1) | BIT(1))
+#define HDMI_AUD_CFG_CTS_CLK_128FS  BIT(17)
+#define HDMI_AUD_CFG_CH12_VALID BIT(28)
+#define HDMI_AUD_CFG_CH34_VALID BIT(29)
+#define HDMI_AUD_CFG_CH56_VALID BIT(30)
+#define HDMI_AUD_CFG_CH78_VALID BIT(31)
+
+/* sample flat mask */
+#define HDMI_SAMPLE_FLAT_NO 0
+#define HDMI_SAMPLE_FLAT_SP0 BIT(0)
+#define HDMI_SAMPLE_FLAT_SP1 BIT(1)
+#define HDMI_SAMPLE_FLAT_SP2 BIT(2)
+#define HDMI_SAMPLE_FLAT_SP3 BIT(3)
+#define HDMI_SAMPLE_FLAT_ALL (HDMI_SAMPLE_FLAT_SP0 \
+ | HDMI_SAMPLE_FLAT_SP1 \
+ | HDMI_SAMPLE_FLAT_SP2 \
+ | HDMI_SAMPLE_FLAT_SP3)
+
 #define HDMI_INFOFRAME_HEADER_TYPE(x)(((x) & 0xff) <<  0)
 #define HDMI_INFOFRAME_HEADER_VERSION(x) (((x) & 0xff) <<  8)
 #define HDMI_INFOFRAME_HEADER_LEN(x) (((x) & 0x0f) << 16)
@@ -380,19 +409,13 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi 
*hdmi)
  */
 static int hdmi_audio_infoframe_config(struct sti_hdmi *hdmi)
 {
-   struct hdmi_audio_infoframe infofame;
+   struct hdmi_audio_infoframe *infoframe;
u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
int ret;

-   ret = hdmi_audio_infoframe_init(&infofame);
-   if (ret < 0) {
-   DRM_ERROR("failed to setup audio infoframe: %d\n", ret);
-   return ret;
-   }
-
-   infofame.channels = 2;
+   infoframe = &hdmi->audio.infoframe;

-   ret = hdmi_audio_infoframe_pack(&infofame, buffer, sizeof(buffer));
+   ret = hdmi_audio_infoframe_pack(infoframe, buffer, sizeof(buffer));
if (ret < 0) {
DRM_ERROR("failed to pack audio infoframe: %d\n", ret);
return ret;
@@ -404,6 +427,56 @@ static int hdmi_audio_infoframe_config(struct sti_hdmi 
*hdmi)
 }

 /**
+ * set audio frame rate
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ *
+ */
+static int hdmi_audio_set_infoframe(struct sti_hdmi *hdmi,
+   struct hdmi_audio_infoframe *info)
+{
+   struct hdmi_audio_n_cts n_cts;
+   int ret, audio_cfg;
+
+   hdmi->audio.infoframe = *info;
+
+   if (!hdmi->enabled)
+   return 0;
+
+   /* update HDMI registers according to configuration */
+   audio_cfg = HDMI_AUD_CFG_SPDIF_DIV_3 | HDMI_AUD_CFG_CTS_CLK_128FS;
+
+   switch (info->channels) {
+   case 8:
+   audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
+   case 6:
+   audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
+   case 4:
+   audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
+   case 2:
+   audio_cfg = HDMI_AUD_CFG_CH12_VALID;
+   break;
+   default:
+   DRM_ERROR("ERROR: Unsupported number of channels (%d)!\n",
+ info->channels);
+   return -EINVAL;
+   }
+
+   hdmi_write(hdmi, audio_cfg, HDMI_AUDIO_CFG);
+
+   /* update N parameter */
+   ret = hdmi_audio_compute_n_cts(info->sample_frequency,
+  hdmi->mode.clock * 1000, &n_cts);
+
+   DRM_DEBUG_DRIVER("n= %d, cts = %d\n",

[RFC 1/5] video: hdmi: add help function for N and CTS

Add helper function to compute CTS and N parameters base on 
table described in HDMI specification 1.4b

Signed-off-by: Arnaud Pouliquen 
---
 drivers/video/hdmi.c | 148 +++
 include/linux/hdmi.h |   8 +++
 2 files changed, 156 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..9c487fb 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1242,3 +1242,151 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, 
void *buffer)
return ret;
 }
 EXPORT_SYMBOL(hdmi_infoframe_unpack);
+
+/*
+ * audio clock regeneration (acr) parameters
+ * N and CTS computation are based on HDMI specification 1.4b
+ */
+
+enum audio_rate {
+   HDMI_AUDIO_N_CTS_32KHZ,
+   HDMI_AUDIO_N_CTS_44_1KHZ,
+   HDMI_AUDIO_N_CTS_48KHZ,
+};
+
+struct hdmi_audio_acr {
+   unsigned long pixel_clk;
+   struct hdmi_audio_n_cts n_cts;
+};
+
+static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
+   { /*32 kHz*/
+   {  25175, {  4576,  28125 } }, /* 25,20/1.001  MHz */
+   {  25200, {  4096,  25200 } }, /* 25.20MHz */
+   {  27000, {  4096,  27000 } }, /* 27.00MHz */
+   {  27027, {  4096,  27027 } }, /* 27.00*1.001  MHz */
+   {  54000, {  4096,  54000 } }, /* 54.00MHz */
+   {  54054, {  4096,  54054 } }, /* 54.00*1.001  MHz */
+   {  74176, { 11648, 310938 } }, /* 74.25/1.001  MHz */
+   {  74250, {  4096,  74250 } }, /* 74.25MHz */
+   { 148352, { 11648, 421875 } }, /* 148.50/1.001 MHz */
+   { 148500, {  4096, 148500 } }, /* 148.50   MHz */
+   { 296703, {  5824, 421875 } }, /* 297/1.001MHz */
+   { 297000, {  3072, 222750 } }, /* 297  MHz */
+   },
+   { /*44.1 kHz, 88.2 kHz  176.4 kHz*/
+   {  25175, {  7007,  31250 } }, /* 25,20/1.001  MHz */
+   {  25200, {  6272,  28000 } }, /* 25.20MHz */
+   {  27000, {  6272,  3 } }, /* 27.00MHz */
+   {  27027, {  6272,  30030 } }, /* 27.00*1.001  MHz */
+   {  54000, {  6272,  6 } }, /* 54.00MHz */
+   {  54054, {  6272,  60060 } }, /* 54.00*1.001  MHz */
+   {  74176, { 17836, 234375 } }, /* 74.25/1.001  MHz */
+   {  74250, {  6272,  82500 } }, /* 74.25MHz */
+   { 148352, {  8918, 234375 } }, /* 148.50/1.001 MHz */
+   { 148500, {  6272, 165000 } }, /* 148.50   MHz */
+   { 296703, {  4459, 234375 } }, /* 297/1.001MHz */
+   { 297000, {  4704, 247500 } }, /* 297  MHz */
+   },
+   { /*48 kHz, 96 kHz  192 kHz*/
+   {  25175, {  6864,  28125 } }, /* 25,20/1.001  MHz */
+   {  25200, {  6144,  25200 } }, /* 25.20MHz */
+   {  27000, {  6144,  27000 } }, /* 27.00MHz */
+   {  27027, {  6144,  27027 } }, /* 27.00*1.001  MHz */
+   {  54000, {  6144,  54000 } }, /* 54.00MHz */
+   {  54054, {  6144,  54054 } }, /* 54.00*1.001  MHz */
+   {  74176, { 11648, 140625 } }, /* 74.25/1.001  MHz */
+   {  74250, {  6144,  74250 } }, /* 74.25MHz */
+   { 148352, {  5824, 140625 } }, /* 148.50/1.001 MHz */
+   { 148500, {  6144, 148500 } }, /* 148.50   MHz */
+   { 296703, {  5824, 281250 } }, /* 297/1.001MHz */
+   { 297000, {  5120, 247500 } }, /* 297  MHz */
+   }
+};
+
+/**
+ * hdmi_compute_n_cts() - compute N and CTS parameters
+ * @audio_clk: audio frame clock frequency in KHz
+ * @pixel_clk: pixel cloack frequency in kHz
+ * @n_cts: N and CTS parameter returned to user
+ *
+ * Values computed are based on table described in HDMI specification 1.4b
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+
+int hdmi_audio_compute_n_cts(unsigned int audio_fs, unsigned long pixel_clk,
+struct hdmi_audio_n_cts *n_cts)
+{
+   int audio_freq_id, i;
+   int ratio = 1;
+   const struct hdmi_audio_acr  *acr_table;
+   const struct hdmi_audio_n_cts *predef_n_cts = NULL;
+
+   switch (audio_fs) {
+   case 32000:
+   audio_freq_id = HDMI_AUDIO_N_CTS_32KHZ;
+   n_cts->n = 4096;
+   break;
+
+   case 44100:
+   audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+   n_cts->n = 6272;
+   break;
+
+   case 48000:
+   audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
+   n_cts->n = 6144;
+   break;
+
+   case 88200:
+   audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+   ratio = 2;
+   n_cts->n = 6272 * 2;
+   break;
+
+   case 96000:
+   audio_freq_id = HDMI_AUDIO_N_C

[RFC 2/5] drm: add helper functions to add bridge audio capabilities

Extend bridge capabilities for audio to enable to connect an audio driver to a
DRM driver with audio capabilities

Signed-off-by: Arnaud Pouliquen 
---
 drivers/gpu/drm/drm_bridge.c | 114 +++
 include/drm/drm_crtc.h   |  31 
 include/linux/hdmi.h |  16 ++
 3 files changed, 161 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 6b8f721..2284ac9 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -328,6 +328,120 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
 EXPORT_SYMBOL(of_drm_find_bridge);
 #endif

+/**
+ * DOC: audio bridge callbacks
+ *
+ * The drm_audio_bridge_funcs ops are populated by the bridge driver that have
+ * audio capabilities (a.e HDMI)
+ * The drm internals(atomic and crtc helpers) use the helpers defined in
+ * drm_bridge.c
+ * These helpers call a specific drm_audio_bridge_funcs ops for all the bridges
+ * during encoder configuration.
+ *
+ * When creating a bridge driver, one can implement drm_audio_bridge_funcs op
+ * with the help of these rough rules:
+ *
+ * pre_enable: this contains things needed to be done for the bridge before
+ * audio is enabled by its source.
+ *
+ * enable: this contains things needed to be done for the audio bridge once its
+ * source is enabled. In other words, enable is called once the source is
+ * ready to start stream rendering.
+ *
+ * disable: this contains things needed to be done for audio bridge when to
+ * disable the audio part for the bridge, assuming that its source is still
+ * enabled.
+ *
+ * post_disable: this contains things needed to be done for the bridge once
+ * its source is disabled.
+ *
+ * mode_set: this sets up the mode for the audio bridge. It assumes that its
+ * source (an encoder or a bridge) has set the mode too.
+ */
+
+/**
+ * drm_audio_bridge_pre_enable - calls 'pre_enable' drm_audio_bridge_funcs ops
+ *   for audio bridges in the encoder chain.
+ * @bridge: bridge control structure
+ *
+ * Calls 'pre_enable' drm_audio_bridge_funcs op for  audio bridge in the
+ * encoder chain.
+ *
+ */
+
+void drm_audio_bridge_pre_enable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return;
+
+   if (bridge->audio_funcs->pre_enable)
+   bridge->audio_funcs->pre_enable(bridge);
+}
+EXPORT_SYMBOL(drm_audio_bridge_pre_enable);
+
+/**
+ * drm_audio_bridge_disable - calls 'disable' drm_audio_bridge_funcs op for
+ *audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ *
+ * Calls 'disable' drm_audio_bridge_funcs op for bridges with audio in the
+ * encoder chain.
+ *
+ */
+void drm_audio_bridge_disable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return;
+
+   if (bridge->audio_funcs->disable)
+   bridge->audio_funcs->disable(bridge);
+}
+EXPORT_SYMBOL(drm_audio_bridge_disable);
+
+/**
+ * drm_audio_bridge_mode_set - set audio mode for audio bridge in the
+ *  encoder chain
+ * @bridge: bridge control structure
+ * @mode: desired audio mode to be set for the audio bridge
+ *
+ * Calls 'mode_set' drm_audio_bridge_funcs op for audio bridge in the
+ * encoder chain.
+ *
+ */
+void drm_audio_bridge_mode_set(struct drm_bridge *bridge,
+  struct hdmi_audio_mode *mode)
+{
+   if (!bridge)
+   return;
+
+   if (bridge->audio_funcs->mode_set)
+   bridge->audio_funcs->mode_set(bridge, mode);
+}
+EXPORT_SYMBOL(drm_audio_bridge_mode_set);
+
+/**
+ * drm_audio_bridge_enable - calls 'enable' drm_audio_bridge_funcs op for all 
bridges
+ *in the encoder chain.
+ * @bridge: bridge control structure
+ *
+ * Calls 'enable' drm_audio_bridge_funcs op for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. These are called
+ * after completing the encoder's commit op.
+ *
+ * Note that the bridge passed should be the one closest to the encoder
+ */
+void drm_audio_bridge_enable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return;
+
+   if (bridge->audio_funcs->mode_set)
+   bridge->audio_funcs->enable(bridge);
+
+}
+EXPORT_SYMBOL(drm_audio_bridge_enable);
+
+
 MODULE_AUTHOR("Ajay Kumar ");
 MODULE_DESCRIPTION("DRM bridge infrastructure");
 MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3b4d8a4..5074019 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -583,6 +583,7 @@ struct drm_encoder_funcs {
  * @possible_clones: bitmask of potential sibling encoders for cloning
  * @crtc: currently bound CRTC
  * @bridge: bridge associated to the encoder
+ * @abridge: optional audio bridge associated to the encoder (HDMI)
  * @funcs: control functions
  * @helper_private: mid-layer private data
  *
@@ -601,6 +602,7 @@ struc

[RFC 5/5] DT: sti: add audio HDMI dai link in audio card

Add the HDMI dai link to support audio for HDMi output

Signed-off-by: Arnaud Pouliquen 
---
 arch/arm/boot/dts/stih410.dtsi   |  4 ++--
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 21 +
 arch/arm/configs/multi_v7_defconfig  |  1 +
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 7ee7dc0..3881016 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -186,8 +186,9 @@
 <&clk_s_d2_quadfs 0>;
};

-   sti-hdmi at 8d04000 {
+   sti_hdmi: sti-hdmi at 8d04000 {
compatible = "st,stih407-hdmi";
+   #sound-dai-cells = <0>;
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
interrupts = ;
@@ -210,7 +211,6 @@
reset-names = "hdmi";
resets = <&softreset 
STIH407_HDMI_TX_PHY_SOFTRESET>;
ddc = <&hdmiddc>;
-
};

sti-hda at 8d02000 {
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 3ad9c82..80fed19 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -81,6 +81,9 @@
audio_controller: sti-asoc-platform {
status = "okay";
};
+   sti_uni_player0: sti-uni-player at 0 {
+   status = "okay";
+   };
sti_uni_player2: sti-uni-player at 2 {
status = "okay";
};
@@ -93,6 +96,12 @@
sti_uni_reader1: sti-uni-reader at 1 {
status = "okay";
};
+
+   sti-display-subsystem {
+   sti_hdmi: sti-hdmi at 8d04000 {
+   status = "okay";
+   };
+   };
};

sound {
@@ -125,6 +134,18 @@
sound-dai = <&sti_sasg_codec 0>;
};
};
+   simple-audio-card,dai-link at 2 {
+   /* HDMI */
+   format = "i2s";
+   mclk-fs = <128>;
+   cpu {
+   sound-dai = <&sti_uni_player0>;
+   };
+
+   codec {
+   sound-dai = <&sti_hdmi>;
+   };
+   };
};

 };
diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 2a44694..6f43666 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -461,6 +461,7 @@ CONFIG_SND_ATMEL_SOC=m
 CONFIG_SND_ATMEL_SOC_WM8904=m
 CONFIG_SND_SOC_SH4_FSI=m
 CONFIG_SND_SOC_RCAR=m
+CONFIG_SND_SOC_HDMI_DRM_CODEC=y
 CONFIG_SND_SOC_STI=y
 CONFIG_SND_SOC_STI_SAS=y
 CONFIG_SND_SOC_TEGRA=m
-- 
1.9.1

[alsa-devel] [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Clemens Ladisch

Jyri Sarha wrote:
> On 09/21/15 12:37, Russell King - ARM Linux wrote:
>> ALSA documentation (which may be out of date) says that the hw_params
>> callback can be called multiple times during stream setup.  Do we want
>> to be repeatedly programming the HDMI infoframe with different settings,
>> potentially confusing the attached device, or would it be better to do
>> it slightly later (in the prepare callback) after the parameters have
>> been fully negotiated?
>
> If it is possible that hw_params() can be called multiple times, at
> least it does not happen very often. I wonder if it would ever happen
> again after a successful hw_params() call.

It is certainly allowed, and it happens regularly when using OSS
emulation.  AFAIK PulseAudio does something similar when enumerating
devices.

> But there is no downside in using prepare callback.

The prepare callback also can be called multiple times.  This certainly
happens when the stream is stopped/restarted multiple times.

If something does not need to be done again when a stream is restarted,
then it should be done in the hw_params callback.

Regards,
Clemens

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-21 Thread Mark Brown

On Mon, Sep 21, 2015 at 04:41:20PM +0300, Jyri Sarha wrote:
> On 09/21/15 12:31, Russell King - ARM Linux wrote:

> >The device may accept 32 bit I2S, but it would have to be truncated to
> >24 bit before transmitting it to the sink.  This should be mentioned
> >somewhere.

> There is ".sig_bits = 24" in hdmi_i2s_dai, but I can add an explicit comment
> about it.

> We needed 32bit format in practice until Peter got 24_LE properly working
> with McASP. I just thought the may still be some platforms out there that
> can not produce 24bit i2s samples for some reason, but work just fine with
> 32bit samples. Those platforms would be limited to less than 24bit precision
> without 32bit formats. But as said, it is not critical to us any more and I
> can drop the 32bit formats as well.

Yes, this is currently a bit messy - we should really be able to allow
S24_LE and S32 to interoperate better without drivers having to know
about it since physically they are essentially compatible in memory.
I'm pretty much OK with it for now since even with that framework
support it should be harmless.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/2c2cf636/attachment.sig>

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

--- Comment #6 from Jeff Nelson  ---
I too am experiencing this issue.
I have two Dell P2715Q monitors connected to my Radeon Fury X and the highest
resolution I can achieve is 1920x1080i.

Looking through xrandr, it also confirms that the 3840x2160 resolution is not
available on either monitor.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/a6a2d4a9/attachment.html>

[PATCH 00/10] drm/exynos: add pm_runtime support

On 09/04/2015 10:15 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This series adds proper runtime PM suport to CRTCs and Encoders, so
> now instead of relying on 'suspended' or 'enabled' flags to track when
> the CRTC or Encoder is enabled we let the pm_runtime subsystem do it for us
> and remove all the flags. This is a important step to the atomic 
> suspend/resume
> support that will land in drm anytime soon.
> 
> Please review!
> 
>   Gustavo

The title is quite misleading, exynos_drm has already pm_runtime support :)
Could you explain more why do you want to change it, what are requirements of
atomic pm? What is wrong with the current one?

If I remember correctly one of arguments for replacing pm callbacks in
components by one centralized callback in exynos_drm_drv was to avoid issues
with non-deterministic order of calling components suspend callback.
Are there any recent changes in PM, DRM which invalidates the reason above?

On the other side your patchset adds implicit dependency on PM_SLEEP config
option, it should be avoided or at least it should be explicit.

Regards
Andrzej

[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

2015-09-21 Thread Philipp Zabel

Hi Rob,

thank you for the comments.

Am Freitag, den 18.09.2015, 15:33 -0500 schrieb Rob Herring:
[...]
> > +The display-subsystem node binds together all individual device nodes that
> > +comprise the DISP subsystem.
> > +
> > +Required properties:
> > +
> > +- compatible: "mediatek,-disp"
> 
> > +- components: Should contain a list of phandles pointing to the DISP 
> > function
> > +  block device nodes.
> > +- component-names: Should contain the name of the function block pointed to
> > +  by the components phandle of the same index.
> 
> NAK. Group these nodes under a parent node, use of-graph or just don't
> put this into DT. Don't invent a new way.

Ok. The reason I haven't grouped all the display nodes together in the
first place is that they aren't contiguous in the register space. So
instead of:

ovl at 1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
};
...
ufoe at 1401a000 {
compatible = "mediatek,mt8173-disp-ufoe";
};

pwm at 1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
};

larb at 14021000 {
compatible = "mediatek,mt8173-smi-larb";
};

od at 14023000 {
compatible = "mediatek,mt8173-disp-od";
};

We'd have:

display-subsystem at 1400c00 {
compatible = "mediatek,mt8173-disp", "simple-bus";

ovl at 1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
};
...
ufoe at 1401a000 {
compatible = "mediatek,mt8173-disp-ufoe";
};

od at 14023000 {
compatible = "mediatek,mt8173-disp-od";
};
};

pwm at 1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
};

larb at 14021000 {
compatible = "mediatek,mt8173-smi-larb";
};

Note how the display-subsystem node overlaps the larb node. Is that
acceptable?

[...]
> > diff --git 
> > a/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt 
> > b/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
> > new file mode 100644
> > index 000..e892ef1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
> > @@ -0,0 +1,29 @@
> > +Mediatek DSI Device
> > +===
> > +
> > +The Mediatek DSI function block is a sink of the display subsystem and can
> > +drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
> > +channel output.
> > +
> > +Required properties:
> > +- compatible: "mediatek,-dsi"
> > +- reg: Physical base address and length of the controller's registers
> > +- clocks: device clocks
> > +  See Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> > details.
> > +- clock-names: must contain "engine" and "digital".
> 
> This leaves wondering which one is used for DSI bit clock.

The MIPI_TX0 module controls the MIPI D-PHY. It contains a PLL that
provides the bit clock to the DSI module.

>From the documentation, it looks to me like the AP_PLL_CON0[6] bit in
the mediatek,mt8173-apmixedsys region gates the 26 MHz reference clock
to MIPI_TX. It is enabled by default. Currently there is no gate clock
registered for that bit.
Can somebody confirm that this gate clock should be added to the
mediatek,mt8173-apmixedsys bindings?

> > +
> > +Example:
> > +
> > +dsi0: dsi at 1401b000 {
> > +   compatible = "mediatek,mt8173-dsi";
> > +   reg = <0 0x1401b000 0 0x1000>,  /* DSI0 */
> > + <0 0x10215000 0 0x1000>;  /* MIPI_TX0 */

Thinking about it, MIPI_TX0 is for PHY control. Should this be moved
into its own node and the phy bindings used to let the DSI driver find
it?

> > +   clocks = <&mmsys MM_DSI0_ENGINE>, <&mmsys MM_DSI0_DIGITAL>;
> > +   clock-names = "engine", "digital";
> > +
> > +   port {
> 
> Missing from the binding description.

Thanks, I'll fix that next round.

> > +   dsi0_out: endpoint {
> > +   remote-endpoint = <&panel_in>;
> > +   };
> > +   };
> > +};

best regards
Philipp

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-21 Thread Russell King - ARM Linux

On Sat, Sep 19, 2015 at 10:54:51AM -0700, Mark Brown wrote:
> On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:
> > +#define SPDIF_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | 
> > SNDRV_PCM_FMTBIT_S16_BE |\
> > +SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
> > +
> > +#define I2S_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | 
> > SNDRV_PCM_FMTBIT_S16_BE |\
> > +SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
> > +SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
> > +SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)
> 
> I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
> doesn't feel like something that's going to be a property of all HDMI
> devices, and the specific sets of formats above cause me to raise a bit
> of an eyebrow.  Should this be an interface where the HDMI chip
> registers multiple interfaces if it has them instead of automatically
> getting this split as is?

The inclusion of the 32-bit formats does raise an eyebrow here too.
Audio transmission across the HDMI link is S/PDIF, supporting up to
24-bit uncompressed audio (aka L-PCM).

The device may accept 32 bit I2S, but it would have to be truncated to
24 bit before transmitting it to the sink.  This should be mentioned
somewhere.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Russell King - ARM Linux

On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.

What is the reason for doing this early?

ALSA documentation (which may be out of date) says that the hw_params
callback can be called multiple times during stream setup.  Do we want
to be repeatedly programming the HDMI infoframe with different settings,
potentially confusing the attached device, or would it be better to do
it slightly later (in the prepare callback) after the parameters have
been fully negotiated?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 3/6] virtio-gpu: wait for cursor updates finish

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 4e160ef..97e5274 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -90,6 +90,9 @@ static int virtio_gpu_crtc_cursor_set(struct drm_crtc *crtc,
   cpu_to_le32(64),
   cpu_to_le32(64),
   0, 0, &fence);
+   reservation_object_add_excl_fence(qobj->tbo.resv,
+ &fence->f);
+   virtio_gpu_object_wait(qobj, false);

output->cursor.hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_UPDATE_CURSOR);
output->cursor.resource_id = cpu_to_le32(qobj->hw_res_handle);
-- 
1.8.3.1

[PATCH v2 1/6] virtio-gpu: add virtio_gpu_queue_ctrl_buffer_locked

Add virtio_gpu_queue_ctrl_buffer_locked function, which does the same as
virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock.  The
caller must hold the lock instead.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 1698669f..5b9bc24 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -293,8 +293,8 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct 
*work)
wake_up(&vgdev->cursorq.ack_queue);
 }

-static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
-   struct virtio_gpu_vbuffer *vbuf)
+static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev,
+  struct virtio_gpu_vbuffer *vbuf)
 {
struct virtqueue *vq = vgdev->ctrlq.vq;
struct scatterlist *sgs[3], vcmd, vout, vresp;
@@ -320,7 +320,6 @@ static int virtio_gpu_queue_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
incnt++;
}

-   spin_lock(&vgdev->ctrlq.qlock);
 retry:
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
if (ret == -ENOSPC) {
@@ -331,13 +330,23 @@ retry:
} else {
virtqueue_kick(vq);
}
-   spin_unlock(&vgdev->ctrlq.qlock);

if (!ret)
ret = vq->num_free;
return ret;
 }

+static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
+   struct virtio_gpu_vbuffer *vbuf)
+{
+   int rc;
+
+   spin_lock(&vgdev->ctrlq.qlock);
+   rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+   spin_unlock(&vgdev->ctrlq.qlock);
+   return rc;
+}
+
 static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
   struct virtio_gpu_vbuffer *vbuf)
 {
-- 
1.8.3.1

[PATCH v2 2/6] virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer

Add helper function to handle the submission of fenced control requests.
Make sure we initialize the fence while holding the virtqueue lock, so
requests can't be reordered.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_fence.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c| 40 +-
 2 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 1da6326..793ad9f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -81,7 +81,7 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_fence_driver *drv = &vgdev->fence_drv;
unsigned long irq_flags;

-   *fence = kmalloc(sizeof(struct virtio_gpu_fence), GFP_KERNEL);
+   *fence = kmalloc(sizeof(struct virtio_gpu_fence), GFP_ATOMIC);
if ((*fence) == NULL)
return -ENOMEM;

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 5b9bc24..ee25e9a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -347,6 +347,38 @@ static int virtio_gpu_queue_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
return rc;
 }

+static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device *vgdev,
+  struct virtio_gpu_vbuffer *vbuf,
+  struct virtio_gpu_ctrl_hdr *hdr,
+  struct virtio_gpu_fence **fence)
+{
+   struct virtqueue *vq = vgdev->ctrlq.vq;
+   int rc;
+
+again:
+   spin_lock(&vgdev->ctrlq.qlock);
+
+   /*
+* Make sure we have enouth space in the virtqueue.  If not
+* wait here until we have.
+*
+* Without that virtio_gpu_queue_ctrl_buffer_nolock might have
+* to wait for free space, which can result in fence ids being
+* submitted out-of-order.
+*/
+   if (vq->num_free < 3) {
+   spin_unlock(&vgdev->ctrlq.qlock);
+   wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= 3);
+   goto again;
+   }
+
+   if (fence)
+   virtio_gpu_fence_emit(vgdev, hdr, fence);
+   rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+   spin_unlock(&vgdev->ctrlq.qlock);
+   return rc;
+}
+
 static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
   struct virtio_gpu_vbuffer *vbuf)
 {
@@ -499,9 +531,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct 
virtio_gpu_device *vgdev,
cmd_p->r.x = x;
cmd_p->r.y = y;

-   if (fence)
-   virtio_gpu_fence_emit(vgdev, &cmd_p->hdr, fence);
-   virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+   virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence);
 }

 static void
@@ -524,9 +554,7 @@ virtio_gpu_cmd_resource_attach_backing(struct 
virtio_gpu_device *vgdev,
vbuf->data_buf = ents;
vbuf->data_size = sizeof(*ents) * nents;

-   if (fence)
-   virtio_gpu_fence_emit(vgdev, &cmd_p->hdr, fence);
-   virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+   virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence);
 }

 static void virtio_gpu_cmd_get_display_info_cb(struct virtio_gpu_device *vgdev,
-- 
1.8.3.1

[PATCH v2 4/6] virtio-gpu: add 3d/virgl support

Add the bits needed for opengl rendering support: query
capabilities, new virtio commands, drm ioctls.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/Makefile|   3 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  10 +
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  60 
 drivers/gpu/drm/virtio/virtgpu_gem.c   |  41 +++
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 572 +
 drivers/gpu/drm/virtio/virtgpu_kms.c   | 135 +++-
 drivers/gpu/drm/virtio/virtgpu_ttm.c   |   1 +
 drivers/gpu/drm/virtio/virtgpu_vq.c| 265 +++
 include/uapi/drm/Kbuild|   1 +
 include/uapi/drm/virtgpu_drm.h | 167 ++
 include/uapi/linux/virtio_gpu.h| 112 ++-
 11 files changed, 1364 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/virtio/virtgpu_ioctl.c
 create mode 100644 include/uapi/drm/virtgpu_drm.h

diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 2ee1602..da7bf19 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -6,6 +6,7 @@ ccflags-y := -Iinclude/drm

 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
-   virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o
+   virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
+   virtgpu_ioctl.o

 obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 7d9610a..957e455 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -73,6 +73,9 @@ static struct virtio_device_id id_table[] = {
 };

 static unsigned int features[] = {
+#ifdef __LITTLE_ENDIAN
+   VIRTIO_GPU_FEATURE_VIRGL,
+#endif
 };
 static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
@@ -114,6 +117,8 @@ static struct drm_driver driver = {
.set_busid = drm_virtio_set_busid,
.load = virtio_gpu_driver_load,
.unload = virtio_gpu_driver_unload,
+   .open = virtio_gpu_driver_open,
+   .postclose = virtio_gpu_driver_postclose,

.dumb_create = virtio_gpu_mode_dumb_create,
.dumb_map_offset = virtio_gpu_mode_dumb_mmap,
@@ -125,8 +130,13 @@ static struct drm_driver driver = {
 #endif

.gem_free_object = virtio_gpu_gem_free_object,
+   .gem_open_object = virtio_gpu_gem_object_open,
+   .gem_close_object = virtio_gpu_gem_object_close,
.fops = &virtio_gpu_driver_fops,

+   .ioctls = virtio_gpu_ioctls,
+   .num_ioctls = DRM_VIRTIO_NUM_IOCTLS,
+
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6d4db2d..2719108 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -146,6 +146,21 @@ struct virtio_gpu_queue {
struct work_struct dequeue_work;
 };

+struct virtio_gpu_drv_capset {
+   uint32_t id;
+   uint32_t max_version;
+   uint32_t max_size;
+};
+
+struct virtio_gpu_drv_cap_cache {
+   struct list_head head;
+   void *caps_cache;
+   uint32_t id;
+   uint32_t version;
+   uint32_t size;
+   atomic_t is_valid;
+};
+
 struct virtio_gpu_device {
struct device *dev;
struct drm_device *ddev;
@@ -179,7 +194,13 @@ struct virtio_gpu_device {
struct idr  ctx_id_idr;
spinlock_t ctx_id_idr_lock;

+   bool has_virgl_3d;
+
struct work_struct config_changed_work;
+
+   struct virtio_gpu_drv_capset *capsets;
+   uint32_t num_capsets;
+   struct list_head cap_cache;
 };

 struct virtio_gpu_fpriv {
@@ -193,6 +214,8 @@ extern struct drm_ioctl_desc 
virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
 /* virtio_kms.c */
 int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags);
 int virtio_gpu_driver_unload(struct drm_device *dev);
+int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
+void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file 
*file);

 /* virtio_gem.c */
 void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj);
@@ -203,6 +226,10 @@ int virtio_gpu_gem_create(struct drm_file *file,
  uint64_t size,
  struct drm_gem_object **obj_p,
  uint32_t *handle_p);
+int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
+  struct drm_file *file);
+void virtio_gpu_gem_object_close(struct drm_gem_object *obj,
+struct drm_file *file);
 struct virtio_gpu_object *virtio_gpu_alloc_object(struct drm_device *dev,
  size_t size, bool kernel,

[PATCH v2 6/6] virtio-gpu: mark as a render gpu

From: Dave Airlie 

Also add DRM_RENDER_ALLOW to the ioctls.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  2 +-
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 18 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 1245d09..e00298e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops 
= {


 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | 
DRIVER_RENDER,
.set_busid = drm_virtio_set_busid,
.load = virtio_gpu_driver_load,
.unload = virtio_gpu_driver_unload,
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index d5c9e02..d297f38 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -540,33 +540,33 @@ copy_exit:

 struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS] = {
DRM_IOCTL_DEF_DRV(VIRTGPU_MAP, virtio_gpu_map_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_EXECBUFFER, virtio_gpu_execbuffer_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_GETPARAM, virtio_gpu_getparam_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_CREATE,
  virtio_gpu_resource_create_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_INFO, virtio_gpu_resource_info_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

/* make transfer async to the main ring? - no sure, can we
   thread these in the underlying GL */
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_FROM_HOST,
  virtio_gpu_transfer_from_host_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_TO_HOST,
  virtio_gpu_transfer_to_host_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_WAIT, virtio_gpu_wait_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF_DRV(VIRTGPU_GET_CAPS, virtio_gpu_get_caps_ioctl,
- DRM_AUTH|DRM_UNLOCKED),
+ DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
-- 
1.8.3.1

[PATCH v2 5/6] virtio-gpu: add basic prime support

From: Dave Airlie 

This is enough to enable DRI3.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/Makefile|  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c   | 13 +-
 drivers/gpu/drm/virtio/virtgpu_drv.h   | 12 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c | 72 ++
 4 files changed, 97 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/virtio/virtgpu_prime.c

diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index da7bf19..3fb8eac 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -7,6 +7,6 @@ ccflags-y := -Iinclude/drm
 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
-   virtgpu_ioctl.o
+   virtgpu_ioctl.o virtgpu_prime.o

 obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 957e455..1245d09 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops 
= {


 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.set_busid = drm_virtio_set_busid,
.load = virtio_gpu_driver_load,
.unload = virtio_gpu_driver_unload,
@@ -128,6 +128,17 @@ static struct drm_driver driver = {
.debugfs_init = virtio_gpu_debugfs_init,
.debugfs_cleanup = virtio_gpu_debugfs_takedown,
 #endif
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_pin = virtgpu_gem_prime_pin,
+   .gem_prime_unpin = virtgpu_gem_prime_unpin,
+   .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
+   .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
+   .gem_prime_vmap = virtgpu_gem_prime_vmap,
+   .gem_prime_vunmap = virtgpu_gem_prime_vunmap,
+   .gem_prime_mmap = virtgpu_gem_prime_mmap,

.gem_free_object = virtio_gpu_gem_free_object,
.gem_open_object = virtio_gpu_gem_object_open,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 2719108..79f0abe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -359,6 +359,18 @@ int virtio_gpu_object_get_sg_table(struct 
virtio_gpu_device *qdev,
 void virtio_gpu_object_free_sg_table(struct virtio_gpu_object *bo);
 int virtio_gpu_object_wait(struct virtio_gpu_object *bo, bool no_wait);

+/* virtgpu_prime.c */
+int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
+void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
+struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
+struct drm_device *dev, struct dma_buf_attachment *attach,
+struct sg_table *sgt);
+void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
+void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
+struct vm_area_struct *vma);
+
 static inline struct virtio_gpu_object*
 virtio_gpu_object_ref(struct virtio_gpu_object *bo)
 {
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
new file mode 100644
index 000..724c231
--- /dev/null
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2014 Canonical
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.

[PATCH] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin

2015-09-21 Thread Thierry Reding

On Wed, Sep 16, 2015 at 01:41:38PM -0700, Douglas Anderson wrote:
> There's a member in 'struct dw_hdmi' called cable_plugin.  It's never
> set to anything anywhere so thus is always false.  There's a bit of code
> checking it, but since it's always false this must be dead code.
> Eliminate it.
> 
> Note: if someone wants to figure out the intention of the original code
> and implement whatever feature / fix was needed then we can drop this
> patch.  The 'cable_plugin' member has been unused since the code was
> first added in (9aaf880 imx-drm: Add mx6 hdmi transmitter support).
> 
> Signed-off-by: Douglas Anderson 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 9 -
>  1 file changed, 9 deletions(-)

Except for the CHROMIUM: prefix this looks good to me:

Reviewed-by: Thierry Reding 

Russell, do you have patches to this driver queued for v4.4 and plan to
pick this up into your tree or should I take it?

Thierry

> 
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 0083d4e..ba90885 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -115,7 +115,6 @@ struct dw_hdmi {
>   int vic;
>  
>   u8 edid[HDMI_EDID_LEN];
> - bool cable_plugin;
>  
>   bool phy_enabled;
>   struct drm_display_mode previous_mode;
> @@ -1203,12 +1202,6 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi 
> *hdmi)
>   hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
>  }
>  
> -static void hdmi_enable_overflow_interrupts(struct dw_hdmi *hdmi)
> -{
> - hdmi_writeb(hdmi, 0, HDMI_FC_MASK2);
> - hdmi_writeb(hdmi, 0, HDMI_IH_MUTE_FC_STAT2);
> -}
> -
>  static void hdmi_disable_overflow_interrupts(struct dw_hdmi *hdmi)
>  {
>   hdmi_writeb(hdmi, HDMI_IH_MUTE_FC_STAT2_OVERFLOW_MASK,
> @@ -1285,8 +1278,6 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   hdmi_tx_hdcp_config(hdmi);
>  
>   dw_hdmi_clear_overflow(hdmi);
> - if (hdmi->cable_plugin && hdmi->sink_is_hdmi)
> - hdmi_enable_overflow_interrupts(hdmi);
>  
>   return 0;
>  }
> -- 
> 2.6.0.rc0.131.gf624c3d
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/fe62e035/attachment.sig>

[PATCH v4 0/16] Add Analogix Core Display Port Driver

Hi Heiko,

On 09/02/2015 10:15 AM, Yakir Yang wrote:
> Hi Heiko,
>
> å¨ 09/02/2015 05:47 AM, Heiko Stuebner åé:
>> Hi Yakir,
>>
>> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
>>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP 
>>> controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM ;)
>>>
>>> Beyond that, there are three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are 
>>> different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp 
>>> debug
>>> register).
>>>
>>> I have verified this series on two kinds of rockchip platform board, 
>>> one
>>> is rk3288 sdk board which connect with a 2K display port monitor, 
>>> the other
>>> is google jerry chromebook which connect with a eDP screen 
>>> "cnm,n116bgeea2",
>>> both of them works rightlly.
>> it looks like during the rebase something did go wrong and I found 
>> some issues
>> I mentioned in the replies to individual patches.
>>
>> I did prepare a branch based on mainline [0] with both the old and 
>> the new edp
>> driver - rk3288_veyron_defconfig build both drivers into the image.
>>
>> While the old driver still works, I wasn't able to make the new one 
>> work yet
>> ... the drm core does find the connector, but not that anything is 
>> connected
>> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
>> interesting before then.
>
> Many thanks for your comment and debug, I would rebase on your
> "edp-with-veyron" branch and fix the broken, make sure v6 would
> work rightly at least in your side and my side.

Just like we talk off line, I guess there are two tricky questions which 
make analogix_dp just crash/failed on rockchip platform:

-  One is how to reach a agreement with the common way to register 
connector. There would be a conflict with Exynos & IMX & Rockchip.
  On analogix_dp thread, Exynos want to register connector when that 
connector is ready.
  On dw_hdmi thread, IMX want to register connector when all 
component is already.
  So Exynos & IMX & Rockchip should reach a common way to register 
connector to fix this issue.

-  The other is atomic API.
   The rockchip drm haven't implemented the atomic API, but the 
original exynos_dp have used the atomic API on connector helper 
function. That's why analogix_dp just keep crash on your side.

I have prepared the v5 version, although those would work directly on 
rockchip side, but I could upload some HACK patches to gerrit  to make 
this works,  hope we can keep the discussion going forward.

Thanks,
- Yakir

>
> - Yakir
>
>>
>> Heiko
>>
>> [0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron
>>
>>
>>
>>
>
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/cb96a9a4/attachment.html>

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

Hi Thierry & Rob,

Sorry, apologize for the delay in replying  :-)


On 09/07/2015 04:20 PM, Thierry Reding wrote:
> On Sun, Sep 06, 2015 at 11:59:08AM +0800, Yakir Yang wrote:
>> Hi Thierry,
>>
>> å¨ 09/03/2015 05:04 PM, Thierry Reding åé:
>>> On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote:
>>>> Hi Rob,
>>>>
>>>> å¨ 09/03/2015 04:17 AM, Rob Herring åé:
>>>>> On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang  wrote:
>>>>>> Some edp screen do not have hpd signal, so we can't just return
>>>>>> failed when hpd plug in detect failed.
>>>>> This is a property of the panel (or connector perhaps), so this
>>>>> property should be located there. At least, it is a common issue and
>>>>> not specific to this chip. We could have an HDMI connector and failed
>>>>> to hook up HPD for example. A connector node is also where hpd-gpios
>>>>> should be located instead (and are already defined by
>>>>> ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
>>>>> binding, too.
>>>> Yep, I agree with your front point, it is a property of panel, not specific
>>>> to eDP controller, so this code should handle in connector logic.
>>>  From your description it sounds more like this is in fact a property of
>>> the panel. Or maybe I should say "quirk". If the panel doesn't generate
>>> the HPD signal, then that should be a property of the panel, not the
>>> connector. The eDP specification mandates that connectors have a HPD
>>> signal, though it allows the "HPD conductor in the connector cable" to
>>> be omitted if not used by the source. I'd consider the cable to belong
>>> to the panel rather than the connector, so absence of HPD, either
>>> because the cable doesn't have the conductor or because the panel does
>>> not generate the signal, should be a quirk of the panel.
>>>
>>> That said you could have a panel that supports HPD connected via a cable
>>> that doesn't transmit it, so this would be a per-board variant and hence
>>> should be a device tree property rather than hard-coded in some panel
>>> driver.
>>>
>>> Conversely, if the panel isn't capable of generating an HPD signal, then
>>> I don't think it would be appropriate to make it a DT property. It would
>>> be better to hard-code it in the driver, lest someone forget to set the
>>> property in DT and get stuck with a device that isn't operational.
>> Oh, you're right, if it's a cable quirk, then DT property would be okay, if
>> it
>> is a problem of panel, then maybe hard-code in driver would be better.
>>
>> After look up for the document of panel "innolux,n116bge", I haven't see
>> any description of hot plug signal, and even not found in PIN ASSIGNMENT.
>> So I believe it's a panel problem, that's to say it should handle in panel
>> driver.
> The datasheet that I have for that panel lists HPD as pin 17. Also I
> used to have a setup with that panel and I distinctly remember hotplug
> working just fine. Perhaps this is an issue with a specific variant of
> the panel? Or perhaps this is indeed a problem with the cable that's
> connecting the panel to the board. It could be one of those cases where
> they left out the HPD conductor to save money.

You're right, I guess I just download the wrong datasheet "N116BGE-L41.pdf"
which the video interfaces is "LVDS", thanks for you point out.

And I double checked with the guys who work with this screen vendor, he said
that it's the fault that vendor missed HPD pin on the screen board, and 
vendor
have fixed this problem later.

But there are still some machine didn't contain the HPD signal, and you also
mention that in some cases where vendor would left out the HPD conductor,
so I still wish to support those "quirk" screen in the later version. 
But I wish
you could share your opinion whether this could exist in the mainline
kernel.

If the answer is no, okay, I would remove this from the next versions. 
but If
the answer is yes, wow, I may still can use the DT property to satisfied 
this
demand (I guess it's okay to keep the DT property way from previous 
discussion).

Thanks,
- Yakir

>
> Thierry
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/fe488f9b/attachment-0001.html>

[PATCH v4 0/16] Add Analogix Core Display Port Driver

2015-09-21 Thread Thierry Reding

On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> Hi Heiko,
> 
> On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >Hi Heiko,
> >
> >å¨ 09/02/2015 05:47 AM, Heiko Stuebner åé:
> >>Hi Yakir,
> >>
> >>Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >>>controller
> >>>share the same IP, so a lot of parts can be re-used. I split the common
> >>>code into bridge directory, then rk3288 and exynos only need to keep
> >>>some platform code. Cause I can't find the exact IP name of exynos dp
> >>>controller, so I decide to name dp core driver with "analogix" which I
> >>>find in rk3288 eDP TRM ;)
> >>>
> >>>Beyond that, there are three light registers setting differents bewteen
> >>>exynos and rk3288.
> >>>1. RK3288 have five special pll resigters which not indicata in exynos
> >>>dp controller.
> >>>2. The address of DP_PHY_PD(dp phy power manager register) are
> >>>different
> >>>between rk3288 and exynos.
> >>>3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >>>debug
> >>>register).
> >>>
> >>>I have verified this series on two kinds of rockchip platform board,
> >>>one
> >>>is rk3288 sdk board which connect with a 2K display port monitor, the
> >>>other
> >>>is google jerry chromebook which connect with a eDP screen
> >>>"cnm,n116bgeea2",
> >>>both of them works rightlly.
> >>it looks like during the rebase something did go wrong and I found some
> >>issues
> >>I mentioned in the replies to individual patches.
> >>
> >>I did prepare a branch based on mainline [0] with both the old and the
> >>new edp
> >>driver - rk3288_veyron_defconfig build both drivers into the image.
> >>
> >>While the old driver still works, I wasn't able to make the new one work
> >>yet
> >>... the drm core does find the connector, but not that anything is
> >>connected
> >>to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> >>interesting before then.
> >
> >Many thanks for your comment and debug, I would rebase on your
> >"edp-with-veyron" branch and fix the broken, make sure v6 would
> >work rightly at least in your side and my side.
> 
> Just like we talk off line, I guess there are two tricky questions which
> make analogix_dp just crash/failed on rockchip platform:
> 
> -  One is how to reach a agreement with the common way to register
> connector. There would be a conflict with Exynos & IMX & Rockchip.
>  On analogix_dp thread, Exynos want to register connector when that
> connector is ready.
>  On dw_hdmi thread, IMX want to register connector when all component is
> already.
>  So Exynos & IMX & Rockchip should reach a common way to register
> connector to fix this issue.
> 
> -  The other is atomic API.
>   The rockchip drm haven't implemented the atomic API, but the original
> exynos_dp have used the atomic API on connector helper function. That's why
> analogix_dp just keep crash on your side.

There's really no reason not to convert Rockchip to atomic. It will have
to happen eventually anyway.

That said, there's another option that would allow you to side-step both
of the above problems at the same time. If you turn the common code into
a helper library that should give you enough flexibility to integrate it
into all existing users. For example you could leave out the connector
registration and let the drivers do that. Similarly since the helpers
are only hooked up at registration time you could probably find a way to
share the low-level code but again leave it up to the drivers to glue it
all together at registration time (drivers could wrap the low-level code
with atomic or non-atomic callbacks).

This option may also have the benefit of loosening the coupling between
DRM drivers and the helper code for this IP, which may be handy in case
the drivers diverge again in the future, or ease transitions to new API.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/29eafa21/attachment.sig>

[PATCH v2 4/6] virtio-gpu: add 3d/virgl support

2015-09-21 Thread Michael S. Tsirkin

On Mon, Sep 21, 2015 at 11:40:15AM +0200, Gerd Hoffmann wrote:
> Add the bits needed for opengl rendering support: query
> capabilities, new virtio commands, drm ioctls.
> 
> Signed-off-by: Dave Airlie 
> Signed-off-by: Gerd Hoffmann 


Looks good to me overall.
Some minor comments below.

I had to fix dri-devel mailing list address.
Hope I did it correctly.


> ---
>  drivers/gpu/drm/virtio/Makefile|   3 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c   |  10 +
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  60 
>  drivers/gpu/drm/virtio/virtgpu_gem.c   |  41 +++
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 572 
> +
>  drivers/gpu/drm/virtio/virtgpu_kms.c   | 135 +++-
>  drivers/gpu/drm/virtio/virtgpu_ttm.c   |   1 +
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 265 +++
>  include/uapi/drm/Kbuild|   1 +
>  include/uapi/drm/virtgpu_drm.h | 167 ++
>  include/uapi/linux/virtio_gpu.h| 112 ++-
>  11 files changed, 1364 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/virtio/virtgpu_ioctl.c
>  create mode 100644 include/uapi/drm/virtgpu_drm.h
> 
> diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
> index 2ee1602..da7bf19 100644
> --- a/drivers/gpu/drm/virtio/Makefile
> +++ b/drivers/gpu/drm/virtio/Makefile
> @@ -6,6 +6,7 @@ ccflags-y := -Iinclude/drm
>  
>  virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
>   virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
> - virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o
> + virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
> + virtgpu_ioctl.o
>  
>  obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 7d9610a..957e455 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -73,6 +73,9 @@ static struct virtio_device_id id_table[] = {
>  };
>  
>  static unsigned int features[] = {
> +#ifdef __LITTLE_ENDIAN
> + VIRTIO_GPU_FEATURE_VIRGL,
> +#endif
>  };

Why is virgl LE specific? Just curious.

>  static struct virtio_driver virtio_gpu_driver = {
>   .feature_table = features,
> @@ -114,6 +117,8 @@ static struct drm_driver driver = {
>   .set_busid = drm_virtio_set_busid,
>   .load = virtio_gpu_driver_load,
>   .unload = virtio_gpu_driver_unload,
> + .open = virtio_gpu_driver_open,
> + .postclose = virtio_gpu_driver_postclose,
>  
>   .dumb_create = virtio_gpu_mode_dumb_create,
>   .dumb_map_offset = virtio_gpu_mode_dumb_mmap,
> @@ -125,8 +130,13 @@ static struct drm_driver driver = {
>  #endif
>  
>   .gem_free_object = virtio_gpu_gem_free_object,
> + .gem_open_object = virtio_gpu_gem_object_open,
> + .gem_close_object = virtio_gpu_gem_object_close,
>   .fops = &virtio_gpu_driver_fops,
>  
> + .ioctls = virtio_gpu_ioctls,
> + .num_ioctls = DRM_VIRTIO_NUM_IOCTLS,
> +
>   .name = DRIVER_NAME,
>   .desc = DRIVER_DESC,
>   .date = DRIVER_DATE,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6d4db2d..2719108 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -146,6 +146,21 @@ struct virtio_gpu_queue {
>   struct work_struct dequeue_work;
>  };
>  
> +struct virtio_gpu_drv_capset {
> + uint32_t id;
> + uint32_t max_version;
> + uint32_t max_size;
> +};
> +
> +struct virtio_gpu_drv_cap_cache {
> + struct list_head head;
> + void *caps_cache;
> + uint32_t id;
> + uint32_t version;
> + uint32_t size;
> + atomic_t is_valid;
> +};
> +
>  struct virtio_gpu_device {
>   struct device *dev;
>   struct drm_device *ddev;
> @@ -179,7 +194,13 @@ struct virtio_gpu_device {
>   struct idr  ctx_id_idr;
>   spinlock_t ctx_id_idr_lock;
>  
> + bool has_virgl_3d;
> +
>   struct work_struct config_changed_work;
> +
> + struct virtio_gpu_drv_capset *capsets;
> + uint32_t num_capsets;
> + struct list_head cap_cache;
>  };
>  
>  struct virtio_gpu_fpriv {
> @@ -193,6 +214,8 @@ extern struct drm_ioctl_desc 
> virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
>  /* virtio_kms.c */
>  int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags);
>  int virtio_gpu_driver_unload(struct drm_device *dev);
> +int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
> +void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file 
> *file);
>  
>  /* virtio_gem.c */
>  void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj);
> @@ -203,6 +226,10 @@ int virtio_gpu_gem_create(struct drm_file *file,
> uint64_t size,
> struct drm_gem_object **obj_p,
> uint32_t *handle_p);
> +int virtio_

block device backed by DRM buffer object

2015-09-21 Thread Steven Newbury

I have a mostly* headless server containing a Radeon discrete GPU. Â It
occured to me that having a GiB or two of high speed memory sitting
unused is pretty wasteful. Not an original thought; indeed there's a
Gentoo wiki which describes how to map the memory as a mtd device:
Â
http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap

There's also a driver (cudaram) written by Piotr JaroszyÅski which
allocates memory through CUDA and maps it to a block device:

http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia.htm
l

The Gentoo method is extremely limited, and of course isn't exactly
safe, although using pci-stub would probably help. Â There's no
arbitration between the DRM driver and the mtd phram driver. Â Most of
all, it can only expose the memory mapped into the PCI aperture, likely
somewhat less than the full VMEM.

The second method obviously requires the proprietary NVidia driver and
an NVidia gfx card, but it's good proof of concept at utilising a
driver managed buffer object as a block device.

I'm looking into creating a volatile block device driver which
allocates VMEM from DRM, what if any is the right API to use? Â The DRM
userspace API is well documented, but I'd like to make this a kernel
module, so using a userspace API would seem inappropriate at best.
Â Ideally I'd like to create something like the bcache flash_vol_create
interface except expose a /sys/fs/drm-block/card0/vol_create (where
drm-block is a placeholder for the proposed driver name) for each DRM
device in the system, and likewise persistence through udev.

So is there an API I can (mis-)use for this? Â Any suggestions?

* There's a screen attached for maintainence, but it usually turned
off.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/1e91d1d6/attachment.sig>

[PATCH] drm/nouveau: remove unused function

2015-09-21 Thread Samuel Pitoiset



On 09/15/2015 09:45 AM, Sudip Mukherjee wrote:
> On Wed, Sep 02, 2015 at 12:08:08PM +0530, Sudip Mukherjee wrote:
>> coverity.com reported that memset was using a buffer of size 0, on
>> checking the code it turned out that the function was not being used. So
>> remove it.
>>
>> Signed-off-by: Sudip Mukherjee 
>> ---
> A gentle ping.

Good catch!

Thanks for reporting this, but the commit message should be something like:
"bios: remove unused nvbios_pmuTp() function"

The next time, don't forget to send patches to 
nouveau at lists.freedesktop.org. ;)

This patch is:
Reviewed-by: Samuel Pitoiset 

>
> regards
> sudip
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

block device backed by DRM buffer object

2015-09-21 Thread Christian König

In general a rather interesting idea and actually shouldn't be to hard 
to implement.

The crux is that allocating memory is device driver dependent, so there 
isn't a general purpose API for doing so.

Additional to that the CPU invisible VRAM is only accessible by the GPU 
so you at least need to be able to submit DMA commands to copy the data 
back and forth.

For an experiment I suggest you do this with Radeon first and if that 
works generalize from there.

Regards,
Christian.

On 21.09.2015 13:33, Steven Newbury wrote:
> I have a mostly* headless server containing a Radeon discrete GPU.  It
> occured to me that having a GiB or two of high speed memory sitting
> unused is pretty wasteful. Not an original thought; indeed there's a
> Gentoo wiki which describes how to map the memory as a mtd device:
>   
> http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap
>
> There's also a driver (cudaram) written by Piotr JaroszyÅski which
> allocates memory through CUDA and maps it to a block device:
>
> http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia.htm
> l
>
> The Gentoo method is extremely limited, and of course isn't exactly
> safe, although using pci-stub would probably help.  There's no
> arbitration between the DRM driver and the mtd phram driver.  Most of
> all, it can only expose the memory mapped into the PCI aperture, likely
> somewhat less than the full VMEM.
>
> The second method obviously requires the proprietary NVidia driver and
> an NVidia gfx card, but it's good proof of concept at utilising a
> driver managed buffer object as a block device.
>
> I'm looking into creating a volatile block device driver which
> allocates VMEM from DRM, what if any is the right API to use?  The DRM
> userspace API is well documented, but I'd like to make this a kernel
> module, so using a userspace API would seem inappropriate at best.
>   Ideally I'd like to create something like the bcache flash_vol_create
> interface except expose a /sys/fs/drm-block/card0/vol_create (where
> drm-block is a placeholder for the proposed driver name) for each DRM
> device in the system, and likewise persistence through udev.
>
> So is there an API I can (mis-)use for this?  Any suggestions?
>
> * There's a screen attached for maintainence, but it usually turned
> off.
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150921/ce666361/attachment.html>

[PATCH 03/38] drm/i915: fix handling gen8_emit_flush_coherentl3_wa result

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/intel_lrc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fe06accb0..ff9a481 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1254,9 +1254,10 @@ static int gen8_init_indirectctx_bb(struct 
intel_engine_cs *ring,

/* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
if (IS_BROADWELL(ring->dev)) {
-   index = gen8_emit_flush_coherentl3_wa(ring, batch, index);
-   if (index < 0)
-   return index;
+   int rc = gen8_emit_flush_coherentl3_wa(ring, batch, index);
+   if (rc < 0)
+   return rc;
+   index = rc;
}

/* WaClearSlmSpaceAtContextSwitch:bdw,chv */
-- 
1.9.1

[PATCH 15/38] drm/layerscape: fix handling fsl_dcu_drm_plane_index result

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 82be6b8..d1e300d 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -58,7 +58,8 @@ static void fsl_dcu_drm_plane_atomic_disable(struct drm_plane 
*plane,
 struct drm_plane_state *old_state)
 {
struct fsl_dcu_drm_device *fsl_dev = plane->dev->dev_private;
-   unsigned int index, value, ret;
+   unsigned int value;
+   int index, ret;

index = fsl_dcu_drm_plane_index(plane);
if (index < 0)
-- 
1.9.1

[PATCH 38/38] drm/radeon: simplify boot level calculation