[RFC 0/2] drm/bridge: panel and chaining

[Ajay kumar]

On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA <
ajaykumar.rs at samsung.com> wrote:

>
>
>
>
> --- *Original Message* ---
>
> *Sender* : Sean Paul
>
> *Date* : Apr 30, 2014 02:34 (GMT+05:30)
>
> *Title* : Re: [RFC 0/2] drm/bridge: panel and chaining
>
>
> On Tue, Apr 29, 2014 at 3:57 PM, Rob Clark wrote:
> > So I thought it would be easier to explain what I had in mind regarding
> > Ajay's patchset (to add panel support) in patch form.  Originally Thierry
> > had some concerns with adding panel support in bridges ad-hoc.  So this
> > idea adds the support of chaining multiple bridges, one of which may be
> > a panal adapter (maybe I should have called it drm_panel_adapter_bridge).
> > There are a few rough edges and TODOs, it isn't trying to be complete
> > yet.
> >
> > So the one question is about that hunk I had to move in ptn3460 from
> > pre_enable() to enable().  If that really needs to come before the
> > encoder and after the panel, then we should go for a slightly different
> > approach instead: add a 'struct drm_bridge *next' ptr in 'struct
> > drm_bridge'.  Then each bridge implementation is responsible to call
> > the next in the chain (if not null) at the appropriate points.  That
> > gives a bit more flexibility to bridges to have something both pre and
> > post the downstream bridge/panel in each of the pre/enable/disable/post
> > steps.
>
> Arbitrarily chaining bridges seems like a more robust solution to me
> than the composite bridge.
>
> For the panel case, I wonder if we could change drm_bridge_init to
> accept a panel, then we could just chain the panel calls off the
> various places the bridge hooks are invoked in the drm layer.
>

This idea originated from Rob itself. He wanted to move out drm_panel calls
from both ptn3460 and ps8622 drivers and he wanted them at a common place.
But Daniel suggested that having a chain of bridges is good. That is how
composite_bridge was formed.

I still think we are addressing a very simple problem in a complex manner.
I tried testing this patchset on my board, with some tweaks(explained in
PATCH 2/2]),
and I could get it working. This code basically adds 3 bridge structures to
handle the calls,
but in actual hardware you can map them to only one bridge device.
I am still not sure what's the problem in just having the panel calls around
the bridge calls in drm core?


> Feel free to ignore if this has already been explored on the other
> thread (which I haven't been following).
>
> Sean
>
>
>
> >
> >
> > Rob Clark (2):
> >   drm/bridge: add composite and panel bridges
> >   drm/bridge/ptn3460: add panel support
> >
> >  drivers/gpu/drm/bridge/Makefile  |   2 +
> >  drivers/gpu/drm/bridge/drm_bridge_util.c | 251
> +++
> >  drivers/gpu/drm/bridge/drm_bridge_util.h |  29 
> >  drivers/gpu/drm/bridge/ptn3460.c |  39 -
> >  include/drm/bridge/ptn3460.h |   6 +-
> >  5 files changed, 319 insertions(+), 8 deletions(-)
> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c
> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
> >
> > --
> > 1.9.0
> >
> > ___
> > 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/20140430/3d43c1f4/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: 201404302024637_QKNMBDIF.gif
Type: image/gif
Size: 14036 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/3d43c1f4/attachment-0001.gif>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #39 from farmboy0+freedesktop at googlemail.com ---
I've double and triple checked to make sure I am making no mistake but the
behaviour I see with Antichamber and the v2 and v3 branches is the same as
reported in comment 21.

-- 
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/20140430/02f48422/attachment.html>

[RFC 2/2] drm/bridge/ptn3460: add panel support

[Ajay kumar]

Rob,



> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ptn3460.c | 39
> +--
> include/drm/bridge/ptn3460.h |  6 --
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
> b/drivers/gpu/drm/bridge/ptn3460.c
> index b171901..e3e6b46 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -26,6 +26,7 @@
> #include "drm_crtc_helper.h"
>
> #include "bridge/ptn3460.h"
> +#include "drm_bridge_util.h"
>
> #define PTN3460_EDID_ADDR 0x0
> #define PTN3460_EDID_EMULATION_ADDR 0x84
> @@ -112,7 +113,6 @@ static int ptn3460_select_edid(struct ptn3460_bridge
> *ptn_bridge)
> static void ptn3460_pre_enable(struct drm_bridge *bridge)
> {
> struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> - int ret;
>
> if (ptn_bridge->enabled)
> return;
> @@ -132,6 +132,15 @@ static void ptn3460_pre_enable(struct drm_bridge
> *bridge)
> * time specified in the chip's datasheet to make sure we're really up.
> */
> msleep(90);
> +}
> +
> +static void ptn3460_enable(struct drm_bridge *bridge)
> +{
> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> + int ret;
> +
> + if (ptn_bridge->enabled)
> + return;
No need to move it into enable. We should keep this entirely inside
pre_enable itself.

>
> ret = ptn3460_select_edid(ptn_bridge);
> if (ret)
> @@ -140,10 +149,6 @@ static void ptn3460_pre_enable(struct drm_bridge
> *bridge)
> ptn_bridge->enabled = true;
> }
>
> -static void ptn3460_enable(struct drm_bridge *bridge)
> -{
> -}
> -
> static void ptn3460_disable(struct drm_bridge *bridge)
> {
> struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> @@ -265,7 +270,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
> };
>
> int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> - struct i2c_client *client, struct device_node *node)
> + struct i2c_client *client, struct device_node *node,
> + struct drm_panel *panel)
> {
> int ret;
> struct drm_bridge *bridge;
> @@ -324,6 +330,27 @@ int ptn3460_init(struct drm_device *dev, struct
> drm_encoder *encoder,
> goto err;
> }
>
> + if (panel) {
> + struct drm_bridge *cbridge, *pbridge;
> +
> + pbridge = drm_panel_bridge_init(panel);
> + if (IS_ERR(pbridge)) {
> + ret = PTR_ERR(pbridge);
> + goto err;
> + }
> +
> + /* panel sequence is after ptn4360 bridge bridge in
> + * enable path, before in disable path:
> + */
> + cbridge = drm_composite_bridge_init(bridge, pbridge);
> + if (IS_ERR(cbridge)) {
> + ret = PTR_ERR(cbridge);
> + goto err;
> + }
> +
> + bridge = cbridge;
> + }
> +
We cannot have this here. Because, at this point the drm_panel probe
would not have happened and the drm_panel would not have got added
into the panel_list itself!

Instead, the panel discovery should be moved into "detect" callback of the
ptn3460 connector. I tried this, and it causes one more problem.
We cannot make a call to drm_panel_bridge_init/drm_composite_bridge_init
sicne both of them call "drm_bridge_init", and drm_bridge_init tries to acquire
dev->mode_config.mutex via drm_modeset_lock_all(dev), and the same lock
is already held by drm core!

I could somehow test your patchset on a board with ptn3460 by commenting
the locking part inside drm_bridge_init, and it works only with all these hacks.

> bridge->driver_private = ptn_bridge;
> encoder->bridge = bridge;
>
> diff --git a/include/drm/bridge/ptn3460.h b/include/drm/bridge/ptn3460.h
> index ff62344..9a557da 100644
> --- a/include/drm/bridge/ptn3460.h
> +++ b/include/drm/bridge/ptn3460.h
> @@ -16,18 +16,20 @@
>
> struct drm_device;
> struct drm_encoder;
> +struct drm_panel;
> struct i2c_client;
> struct device_node;
>
> #if defined(CONFIG_DRM_PTN3460) || defined(CONFIG_DRM_PTN3460_MODULE)
>
> int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> - struct i2c_client *client, struct device_node *node);
> + struct i2c_client *client, struct device_node *node,
> + struct drm_panel *panel);
> #else
>
> static inline int ptn3460_init(struct drm_device *dev,
> struct drm_encoder *encoder, struct i2c_client *client,
> - struct device_node *node)
> + struct device_node *node, struct drm_panel *panel)
> {
> return 0;
> }
> --
> 1.9.0
>
>
>
>
>
>

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi Thierry,

On Monday 28 April 2014 23:25:50 Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
> > On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> > > On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > > > Hi YoungJun,
> > > > 
> > > > Thank you for the patch.
> > > > 
> > > > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> > > >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> > > >> driver.
> > > >> 
> > > >> Changelog v2:
> > > >> - Declares delay, size properties in probe routine instead of DT
> > > >> Changelog v3:
> > > >> - Moves CPU timings relevant properties from FIMD DT
> > > >> 
> > > >>(commented by Laurent Pinchart, Andrzej Hajda)
> > > >> 
> > > >> Signed-off-by: YoungJun Cho 
> > > >> Acked-by: Inki Dae 
> > > >> Acked-by: Kyungmin Park 
> > > >> ---
> > > >> 
> > > >>   drivers/gpu/drm/panel/Kconfig |7 +
> > > >>   drivers/gpu/drm/panel/Makefile|1 +
> > > >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
> > > >>   3 files changed, 577 insertions(+)
> > > >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > > 
> > > > [snip]
> > > > 
> > > >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> > > >> index 000..1282678
> > > >> --- /dev/null
> > > >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> @@ -0,0 +1,569 @@
> > > > 
> > > > [snip]
> > > > 
> > > >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> > > >> +{
> > > >> +  struct drm_connector *connector = panel->connector;
> > > >> +  struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> > > >> +  struct drm_display_mode *mode;
> > > >> +
> > > >> +  mode = drm_mode_create(connector->dev);
> > > >> +  if (!mode) {
> > > >> +  DRM_ERROR("failed to create a new display mode\n");
> > > >> +  return 0;
> > > >> +  }
> > > >> +
> > > >> +  drm_display_mode_from_videomode(>vm, mode);
> > > >> +  mode->width_mm = ctx->width_mm;
> > > >> +  mode->height_mm = ctx->height_mm;
> > > >> +  connector->display_info.width_mm = mode->width_mm;
> > > >> +  connector->display_info.height_mm = mode->height_mm;
> > > >> +
> > > >> +  mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > >> +  mode->private = (void *)>cpu_timings;
> > > > 
> > > > Wouldn't it make sense to create a new get_interface_params (or
> > > > similar)
> > > > operation for drm_panel to query interface configuration parameters
> > > > instead of shoving it in the mode private field ?
> > > 
> > > You mean "new get_interface_params operation" is different from
> > > get_modes() ?
> > > 
> > > Till now, struct drm_display_mode and most of mode relevant APIs are
> > > only for video interface.
> > > And CPU interface also needs video mode configurations.
> > > 
> > > I have a plan to implement the CPU interface relevant APIs like video
> > > mode ones, but I think they should be used under current DRM mode APIs
> > > like fill_modes, get_modes and so on.
> > > So after that implementation, this private field will be replaced by
> > > new ones.
> > > 
> > > Could you explain it in more detail?
> > 
> > The idea is that the interface parameters (RD/WR signals timings in this
> > case, but this could also include MIPI DSI lane configuration or any
> > other kind of physical interface parameters) are distinct from the video
> > modes.
> 
> We already have the lanes field in struct mipi_dsi_device.

Seems I've missed the addition of mipi_dsi_device to DRM.

> I think in general I'd prefer to not spread these parameters around too
> wildly. If this is a general requirement for DBI devices, perhaps what we
> need is struct mipi_dbi_device?

That could be done, but I'm not sure we should expose the nature of the panel 
device (i.e. "I'm a mipi_dsi_device") to the display controller. I would be 
worried about using container_of() on panel->dev to get a mipi_dsi_device 
pointer, as we would then need a strict guarantee that the panel->dev pointer 
is embedded directly in a mipi_dsi_device. This might be doable for DSI, but 
other kind of panels might be connected to different control busses (I'm 
thinking about I2C and SPI in particular) and still need to expose video 
interface parameters to the display controller driver.

-- 
Regards,

Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/def4ed3f/attachment.sig>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #38 from Tom Stellard  ---
(In reply to comment #37)
> Hi,
> 
> I'm new to this and doing something wrong. Do I need to compile the patched
> LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa
> 10.1 also not quite sure, how to force my system to use the modified
> stuf without breaking things.

I would recommend using the LLVM branch plus the latest Mesa code from git.  To
avoid breaking your current system, you can install LLVM to a non-standard path
and then pass the --with-llvm-prefix=/path/to/llvm to mesa's configure script.

-- 
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/20140430/5f80cc96/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #76 from Alex Deucher  ---
(In reply to comment #75)
> Created attachment 98258 [details] [review]
> Tahiti Fix

+for (i = 0; i < rdev->config.si.max_texture_channel_caches; i++)
+cgts_tcc_disable &= ~(1 << (16 + i));

this should be:

+for (i = 0; i < rdev->config.cik.max_texture_channel_caches; i++)
+cgts_tcc_disable &= ~(1 << (16 + i));

-- 
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/20140430/1f0cdb26/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #37 from filipp.andjelo at gmail.com ---
Hi,

I'm new to this and doing something wrong. Do I need to compile the patched
LLVM and the latest Mesa from git? Or is it sufficient to recompile Mesa
10.1 also not quite sure, how to force my system to use the modified stuf
without breaking things.

-- 
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/20140430/b408cd20/attachment.html>

[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume

[Rahul Sharma]

From: Rahul Sharma 

While testing S2R on exynos board, system is hanging and
rebooting due to nested mutex_lock calls in exynos drm
resume callback. Changing the order of the calls is fixing
the issue.

Signed-off-by: Rahul Sharma 
---
Based on exynos-drm-next branch in Inki Dae's tree.
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb7dfee..2bb6233 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev)
connector->funcs->dpms(connector, connector->dpms);
}

-   drm_helper_resume_force_mode(dev);
drm_modeset_unlock_all(dev);
+   drm_helper_resume_force_mode(dev);

return 0;
 }
-- 
1.7.9.5

[PATCH 2/2] radeon: add Mullins pci ids

[Alex Deucher]

From: Samuel Li 

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 radeon/r600_pci_ids.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/radeon/r600_pci_ids.h b/radeon/r600_pci_ids.h
index 37fb61c..de25f16 100644
--- a/radeon/r600_pci_ids.h
+++ b/radeon/r600_pci_ids.h
@@ -425,6 +425,23 @@ CHIPSET(0x983D, KABINI_983D, KABINI)
 CHIPSET(0x983E, KABINI_983E, KABINI)
 CHIPSET(0x983F, KABINI_983F, KABINI)

+CHIPSET(0x9850, MULLINS_9850, MULLINS)
+CHIPSET(0x9851, MULLINS_9851, MULLINS)
+CHIPSET(0x9852, MULLINS_9852, MULLINS)
+CHIPSET(0x9853, MULLINS_9853, MULLINS)
+CHIPSET(0x9854, MULLINS_9854, MULLINS)
+CHIPSET(0x9855, MULLINS_9855, MULLINS)
+CHIPSET(0x9856, MULLINS_9856, MULLINS)
+CHIPSET(0x9857, MULLINS_9857, MULLINS)
+CHIPSET(0x9858, MULLINS_9858, MULLINS)
+CHIPSET(0x9859, MULLINS_9859, MULLINS)
+CHIPSET(0x985A, MULLINS_985A, MULLINS)
+CHIPSET(0x985B, MULLINS_985B, MULLINS)
+CHIPSET(0x985C, MULLINS_985C, MULLINS)
+CHIPSET(0x985D, MULLINS_985D, MULLINS)
+CHIPSET(0x985E, MULLINS_985E, MULLINS)
+CHIPSET(0x985F, MULLINS_985F, MULLINS)
+
 CHIPSET(0x1304, KAVERI_1304, KAVERI)
 CHIPSET(0x1305, KAVERI_1305, KAVERI)
 CHIPSET(0x1306, KAVERI_1306, KAVERI)
-- 
1.8.3.1

[PATCH 1/2] radeon: add Mullins chip family

[Alex Deucher]

From: Samuel Li 

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 radeon/radeon_surface.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 15127d4..109bd6b 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -80,6 +80,7 @@ enum radeon_family {
 CHIP_KAVERI,
 CHIP_KABINI,
 CHIP_HAWAII,
+CHIP_MULLINS,
 CHIP_LAST,
 };

-- 
1.8.3.1

[PATCH 0/2] libdrm_radeon support for Mullins

[Alex Deucher]

This adds support for the new Mullins and Beema APUs.

Samuel Li (2):
  radeon: add Mullins chip family
  radeon: add Mullins pci ids

 radeon/r600_pci_ids.h   | 17 +
 radeon/radeon_surface.c |  1 +
 2 files changed, 18 insertions(+)

-- 
1.8.3.1

[PATCH 8/8] drm/radeon: add pci ids for Mullins

[Alex Deucher]

From: Samuel Li 

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 include/drm/drm_pciids.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 49376ae..6dfd64b 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -637,6 +637,22 @@
{0x1002, 0x983d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_KABINI|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x983e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_KABINI|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x983f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_KABINI|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9851, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9852, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9853, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9854, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9855, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9856, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9857, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9858, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9859, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x985F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_MULLINS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9900, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9901, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9903, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
-- 
1.8.3.1

[PATCH 7/8] drm/radeon: add Mullins VCE support

[Alex Deucher]

From: Leo Liu 

VCE 2.0 just like the other CIK parts.

Signed-off-by: Leo Liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_vce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index ced53dd..f73324c 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -66,6 +66,7 @@ int radeon_vce_init(struct radeon_device *rdev)
case CHIP_BONAIRE:
case CHIP_KAVERI:
case CHIP_KABINI:
+   case CHIP_MULLINS:
fw_name = FIRMWARE_BONAIRE;
break;

-- 
1.8.3.1

[PATCH 6/8] drm/radeon: modesetting updates for Mullins.

[Alex Deucher]

From: Samuel Li 

Uses the same code as Kabini.

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index fb187c7..640f6a7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1720,8 +1720,9 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
}
/* otherwise, pick one of the plls */
if ((rdev->family == CHIP_KAVERI) ||
-   (rdev->family == CHIP_KABINI)) {
-   /* KB/KV has PPLL1 and PPLL2 */
+   (rdev->family == CHIP_KABINI) ||
+   (rdev->family == CHIP_MULLINS)) {
+   /* KB/KV/ML has PPLL1 and PPLL2 */
pll_in_use = radeon_get_pll_use_mask(crtc);
if (!(pll_in_use & (1 << ATOM_PPLL2)))
return ATOM_PPLL2;
-- 
1.8.3.1

[PATCH 5/8] drm/radeon: dpm updates for KV/KB

[Alex Deucher]

- Use vddc/sclk dep table for voltage if available
- Fix UVD DPM setup
- Patch voltage tables properly for non-UVD blocks
- Fix DPM + UVD/VCE on Mullins

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/kv_dpm.c | 117 +---
 1 file changed, 97 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c
index 370..3f6e817 100644
--- a/drivers/gpu/drm/radeon/kv_dpm.c
+++ b/drivers/gpu/drm/radeon/kv_dpm.c
@@ -546,6 +546,52 @@ static int kv_set_divider_value(struct radeon_device *rdev,
return 0;
 }

+static u32 kv_convert_vid2_to_vid7(struct radeon_device *rdev,
+  struct sumo_vid_mapping_table 
*vid_mapping_table,
+  u32 vid_2bit)
+{
+   struct radeon_clock_voltage_dependency_table *vddc_sclk_table =
+   >pm.dpm.dyn_state.vddc_dependency_on_sclk;
+   u32 i;
+
+   if (vddc_sclk_table && vddc_sclk_table->count) {
+   if (vid_2bit < vddc_sclk_table->count)
+   return vddc_sclk_table->entries[vid_2bit].v;
+   else
+   return vddc_sclk_table->entries[vddc_sclk_table->count 
- 1].v;
+   } else {
+   for (i = 0; i < vid_mapping_table->num_entries; i++) {
+   if (vid_mapping_table->entries[i].vid_2bit == vid_2bit)
+   return vid_mapping_table->entries[i].vid_7bit;
+   }
+   return 
vid_mapping_table->entries[vid_mapping_table->num_entries - 1].vid_7bit;
+   }
+}
+
+static u32 kv_convert_vid7_to_vid2(struct radeon_device *rdev,
+  struct sumo_vid_mapping_table 
*vid_mapping_table,
+  u32 vid_7bit)
+{
+   struct radeon_clock_voltage_dependency_table *vddc_sclk_table =
+   >pm.dpm.dyn_state.vddc_dependency_on_sclk;
+   u32 i;
+
+   if (vddc_sclk_table && vddc_sclk_table->count) {
+   for (i = 0; i < vddc_sclk_table->count; i++) {
+   if (vddc_sclk_table->entries[i].v == vid_7bit)
+   return i;
+   }
+   return vddc_sclk_table->count - 1;
+   } else {
+   for (i = 0; i < vid_mapping_table->num_entries; i++) {
+   if (vid_mapping_table->entries[i].vid_7bit == vid_7bit)
+   return vid_mapping_table->entries[i].vid_2bit;
+   }
+
+   return 
vid_mapping_table->entries[vid_mapping_table->num_entries - 1].vid_2bit;
+   }
+}
+
 static u16 kv_convert_8bit_index_to_voltage(struct radeon_device *rdev,
u16 voltage)
 {
@@ -556,9 +602,9 @@ static u16 kv_convert_2bit_index_to_voltage(struct 
radeon_device *rdev,
u32 vid_2bit)
 {
struct kv_power_info *pi = kv_get_pi(rdev);
-   u32 vid_8bit = sumo_convert_vid2_to_vid7(rdev,
-
>sys_info.vid_mapping_table,
-vid_2bit);
+   u32 vid_8bit = kv_convert_vid2_to_vid7(rdev,
+  >sys_info.vid_mapping_table,
+  vid_2bit);

return kv_convert_8bit_index_to_voltage(rdev, (u16)vid_8bit);
 }
@@ -1362,13 +1408,20 @@ static int kv_update_uvd_dpm(struct radeon_device 
*rdev, bool gate)
struct radeon_uvd_clock_voltage_dependency_table *table =
>pm.dpm.dyn_state.uvd_clock_voltage_dependency_table;
int ret;
+   u32 mask;

if (!gate) {
-   if (!pi->caps_uvd_dpm || table->count || 
pi->caps_stable_p_state)
+   if (table->count)
pi->uvd_boot_level = table->count - 1;
else
pi->uvd_boot_level = 0;

+   if (!pi->caps_uvd_dpm || pi->caps_stable_p_state) {
+   mask = 1 << pi->uvd_boot_level;
+   } else {
+   mask = 0x1f;
+   }
+
ret = kv_copy_bytes_to_smc(rdev,
   pi->dpm_table_start +
   offsetof(SMU7_Fusion_DpmTable, 
UvdBootLevel),
@@ -1377,11 +1430,9 @@ static int kv_update_uvd_dpm(struct radeon_device *rdev, 
bool gate)
if (ret)
return ret;

-   if (!pi->caps_uvd_dpm ||
-   pi->caps_stable_p_state)
-   kv_send_msg_to_smc_with_parameter(rdev,
- 
PPSMC_MSG_UVDDPM_SetEnabledMask,
- (1 << 
pi->uvd_boot_level));
+   kv_send_msg_to_smc_with_parameter(rdev,
+ 

[PATCH 4/8] drm/radeon: add Mullins dpm support.

[Alex Deucher]

From: Samuel Li 

Generic dpm support similar to Kabini. Mullins specific features
will be worked on later.

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/kv_dpm.c| 20 ++--
 drivers/gpu/drm/radeon/radeon_pm.c |  1 +
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c
index 16ec9d5..370 100644
--- a/drivers/gpu/drm/radeon/kv_dpm.c
+++ b/drivers/gpu/drm/radeon/kv_dpm.c
@@ -639,7 +639,7 @@ static int kv_force_lowest_valid(struct radeon_device *rdev)

 static int kv_unforce_levels(struct radeon_device *rdev)
 {
-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
return kv_notify_message_to_smu(rdev, PPSMC_MSG_NoForcedLevel);
else
return kv_set_enabled_levels(rdev);
@@ -1617,7 +1617,7 @@ static void kv_dpm_powergate_acp(struct radeon_device 
*rdev, bool gate)
if (pi->acp_power_gated == gate)
return;

-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
return;

pi->acp_power_gated = gate;
@@ -1786,7 +1786,7 @@ int kv_dpm_set_power_state(struct radeon_device *rdev)
}
}

-   if (rdev->family == CHIP_KABINI) {
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS) {
if (pi->enable_dpm) {
kv_set_valid_clock_range(rdev, new_ps);
kv_update_dfs_bypass_settings(rdev, new_ps);
@@ -1862,7 +1862,7 @@ void kv_dpm_reset_asic(struct radeon_device *rdev)
 {
struct kv_power_info *pi = kv_get_pi(rdev);

-   if (rdev->family == CHIP_KABINI) {
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS) {
kv_force_lowest_valid(rdev);
kv_init_graphics_levels(rdev);
kv_program_bootup_state(rdev);
@@ -1941,7 +1941,7 @@ static int kv_force_dpm_highest(struct radeon_device 
*rdev)
break;
}

-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
return kv_send_msg_to_smc_with_parameter(rdev, 
PPSMC_MSG_DPM_ForceState, i);
else
return kv_set_enabled_level(rdev, i);
@@ -1961,7 +1961,7 @@ static int kv_force_dpm_lowest(struct radeon_device *rdev)
break;
}

-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
return kv_send_msg_to_smc_with_parameter(rdev, 
PPSMC_MSG_DPM_ForceState, i);
else
return kv_set_enabled_level(rdev, i);
@@ -2118,7 +2118,7 @@ static void kv_apply_state_adjust_rules(struct 
radeon_device *rdev,
else
pi->battery_state = false;

-   if (rdev->family == CHIP_KABINI) {
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS) {
ps->dpm0_pg_nb_ps_lo = 0x1;
ps->dpm0_pg_nb_ps_hi = 0x0;
ps->dpmx_nb_ps_lo = 0x1;
@@ -2179,7 +2179,7 @@ static int kv_calculate_nbps_level_settings(struct 
radeon_device *rdev)
if (pi->lowest_valid > pi->highest_valid)
return -EINVAL;

-   if (rdev->family == CHIP_KABINI) {
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS) {
for (i = pi->lowest_valid; i <= pi->highest_valid; i++) {
pi->graphics_level[i].GnbSlow = 1;
pi->graphics_level[i].ForceNbPs1 = 0;
@@ -2324,7 +2324,7 @@ static void kv_program_nbps_index_settings(struct 
radeon_device *rdev,
struct kv_power_info *pi = kv_get_pi(rdev);
u32 nbdpmconfig1;

-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
return;

if (pi->sys_info.nb_dpm_enable) {
@@ -2631,7 +2631,7 @@ int kv_dpm_init(struct radeon_device *rdev)

 pi->sram_end = SMC_RAM_END;

-   if (rdev->family == CHIP_KABINI)
+   if (rdev->family == CHIP_KABINI || rdev->family == CHIP_MULLINS)
pi->high_voltage_t = 4001;

pi->enable_nb_dpm = true;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fac8ef..f30b842 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1300,6 +1300,7 @@ int radeon_pm_init(struct radeon_device *rdev)
case CHIP_KABINI:
case CHIP_KAVERI:
case CHIP_HAWAII:
+   case CHIP_MULLINS:
/* DPM requires the RLC, RV770+ dGPU requires SMC */
if (!rdev->rlc_fw)
rdev->pm.pm_method = PM_METHOD_PROFILE;
-- 
1.8.3.1

[PATCH 3/8] drm/radeon: add Mullins UVD support.

[Alex Deucher]

From: Samuel Li 

Has same version of UVD as other CIK parts.

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 5748bda..9d29187 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -99,6 +99,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
case CHIP_KABINI:
case CHIP_KAVERI:
case CHIP_HAWAII:
+   case CHIP_MULLINS:
fw_name = FIRMWARE_BONAIRE;
break;

-- 
1.8.3.1

[PATCH 2/8] drm/radeon: update cik init for Mullins.

[Alex Deucher]

From: Samuel Li 

Also add golden registers, update firmware loading functions.

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cik.c  | 71 +++
 drivers/gpu/drm/radeon/radeon_ucode.h |  1 +
 2 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 199eb19..fd69646 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -63,6 +63,12 @@ MODULE_FIRMWARE("radeon/KABINI_ce.bin");
 MODULE_FIRMWARE("radeon/KABINI_mec.bin");
 MODULE_FIRMWARE("radeon/KABINI_rlc.bin");
 MODULE_FIRMWARE("radeon/KABINI_sdma.bin");
+MODULE_FIRMWARE("radeon/MULLINS_pfp.bin");
+MODULE_FIRMWARE("radeon/MULLINS_me.bin");
+MODULE_FIRMWARE("radeon/MULLINS_ce.bin");
+MODULE_FIRMWARE("radeon/MULLINS_mec.bin");
+MODULE_FIRMWARE("radeon/MULLINS_rlc.bin");
+MODULE_FIRMWARE("radeon/MULLINS_sdma.bin");

 extern int r600_ih_ring_alloc(struct radeon_device *rdev);
 extern void r600_ih_ring_fini(struct radeon_device *rdev);
@@ -1473,6 +1479,43 @@ static const u32 hawaii_mgcg_cgcg_init[] =
0xd80c, 0xff000ff0, 0x0100
 };

+static const u32 godavari_golden_registers[] =
+{
+   0x55e4, 0xff607fff, 0xfc000100,
+   0x6ed8, 0x00010101, 0x0001,
+   0x9830, 0x, 0x,
+   0x98302, 0xf00f, 0x0400,
+   0x6130, 0x, 0x0001,
+   0x5bb0, 0x00f0, 0x0070,
+   0x5bc0, 0xf0311fff, 0x8030,
+   0x98f8, 0x73773777, 0x12010001,
+   0x98fc, 0x, 0x0010,
+   0x8030, 0x1f0f, 0x100a,
+   0x2f48, 0x73773777, 0x12010001,
+   0x2408, 0x000f, 0x000c007f,
+   0x8a14, 0xf03f, 0x0007,
+   0x8b24, 0x, 0x00ff0fff,
+   0x30a04, 0xff0f, 0x,
+   0x28a4c, 0x07ff, 0x0600,
+   0x4d8, 0x0fff, 0x0100,
+   0xd014, 0x0001, 0x00810001,
+   0xd814, 0x0001, 0x00810001,
+   0x3e78, 0x0001, 0x0002,
+   0xc768, 0x0008, 0x0008,
+   0xc770, 0x0f00, 0x0800,
+   0xc774, 0x0f00, 0x0800,
+   0xc798, 0x00ff, 0x00ff7fbf,
+   0xc79c, 0x00ff, 0x00ff7faf,
+   0x8c00, 0x00ff, 0x0001,
+   0x214f8, 0x01ff01ff, 0x0002,
+   0x21498, 0x007ff800, 0x0020,
+   0x2015c, 0x, 0x0f40,
+   0x88c4, 0x001f3ae3, 0x0082,
+   0x88d4, 0x001f, 0x0010,
+   0x30934, 0x, 0x
+};
+
+
 static void cik_init_golden_registers(struct radeon_device *rdev)
 {
switch (rdev->family) {
@@ -1504,6 +1547,20 @@ static void cik_init_golden_registers(struct 
radeon_device *rdev)
 kalindi_golden_spm_registers,
 (const 
u32)ARRAY_SIZE(kalindi_golden_spm_registers));
break;
+   case CHIP_MULLINS:
+   radeon_program_register_sequence(rdev,
+kalindi_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(kalindi_mgcg_cgcg_init));
+   radeon_program_register_sequence(rdev,
+godavari_golden_registers,
+(const 
u32)ARRAY_SIZE(godavari_golden_registers));
+   radeon_program_register_sequence(rdev,
+
kalindi_golden_common_registers,
+(const 
u32)ARRAY_SIZE(kalindi_golden_common_registers));
+   radeon_program_register_sequence(rdev,
+kalindi_golden_spm_registers,
+(const 
u32)ARRAY_SIZE(kalindi_golden_spm_registers));
+   break;
case CHIP_KAVERI:
radeon_program_register_sequence(rdev,
 spectre_mgcg_cgcg_init,
@@ -1834,6 +1891,15 @@ static int cik_init_microcode(struct radeon_device *rdev)
rlc_req_size = KB_RLC_UCODE_SIZE * 4;
sdma_req_size = CIK_SDMA_UCODE_SIZE * 4;
break;
+   case CHIP_MULLINS:
+   chip_name = "MULLINS";
+   pfp_req_size = CIK_PFP_UCODE_SIZE * 4;
+   me_req_size = CIK_ME_UCODE_SIZE * 4;
+   ce_req_size = CIK_CE_UCODE_SIZE * 4;
+   mec_req_size = CIK_MEC_UCODE_SIZE * 4;
+   rlc_req_size = ML_RLC_UCODE_SIZE * 4;
+   sdma_req_size = CIK_SDMA_UCODE_SIZE * 4;
+   break;
default: BUG();
}

@@ -3272,6 +3338,7 @@ static void cik_gpu_init(struct radeon_device *rdev)
gb_addr_config = BONAIRE_GB_ADDR_CONFIG_GOLDEN;
break;
case CHIP_KABINI:
+   case CHIP_MULLINS:
default:

[PATCH 1/8] drm/radeon: add Mullins chip family

[Alex Deucher]

From: Samuel Li 

Mullins is a new CI-based APU.

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_asic.c   | 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 1 +
 drivers/gpu/drm/radeon/radeon_family.h | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index b8a24a7..be20e62 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -2516,6 +2516,7 @@ int radeon_asic_init(struct radeon_device *rdev)
break;
case CHIP_KAVERI:
case CHIP_KABINI:
+   case CHIP_MULLINS:
rdev->asic = _asic;
/* set num crtcs */
if (rdev->family == CHIP_KAVERI) {
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 511fe26..0e770bb 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -99,6 +99,7 @@ static const char radeon_family_name[][16] = {
"KAVERI",
"KABINI",
"HAWAII",
+   "MULLINS",
"LAST",
 };

diff --git a/drivers/gpu/drm/radeon/radeon_family.h 
b/drivers/gpu/drm/radeon/radeon_family.h
index 9da5da4..4b7b87f 100644
--- a/drivers/gpu/drm/radeon/radeon_family.h
+++ b/drivers/gpu/drm/radeon/radeon_family.h
@@ -97,6 +97,7 @@ enum radeon_family {
CHIP_KAVERI,
CHIP_KABINI,
CHIP_HAWAII,
+   CHIP_MULLINS,
CHIP_LAST,
 };

-- 
1.8.3.1

[PATCH 0/8] Add support for Mullins and Beema

[Alex Deucher]

This patch set adds support for the new Mullins and
Beema APUs.

Alex Deucher (1):
  drm/radeon: dpm updates for KV/KB

Leo Liu (1):
  drm/radeon: add Mullins VCE support

Samuel Li (6):
  drm/radeon: add Mullins chip family
  drm/radeon: update cik init for Mullins.
  drm/radeon: add Mullins UVD support.
  drm/radeon: add Mullins dpm support.
  drm/radeon: modesetting updates for Mullins.
  drm/radeon: add pci ids for Mullins

 drivers/gpu/drm/radeon/atombios_crtc.c |   5 +-
 drivers/gpu/drm/radeon/cik.c   |  71 +
 drivers/gpu/drm/radeon/kv_dpm.c| 135 ++---
 drivers/gpu/drm/radeon/radeon_asic.c   |   1 +
 drivers/gpu/drm/radeon/radeon_device.c |   1 +
 drivers/gpu/drm/radeon/radeon_family.h |   1 +
 drivers/gpu/drm/radeon/radeon_pm.c |   1 +
 drivers/gpu/drm/radeon/radeon_ucode.h  |   1 +
 drivers/gpu/drm/radeon/radeon_uvd.c|   1 +
 drivers/gpu/drm/radeon/radeon_vce.c|   1 +
 include/drm/drm_pciids.h   |  16 
 11 files changed, 203 insertions(+), 31 deletions(-)

-- 
1.8.3.1

[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume

[Rahul Sharma]

From: Rahul Sharma 

While testing S2R on exynos board, system is hanging and
rebooting due to nested mutex_lock calls in exynos drm
resume callback. Changing the order of the calls is fixing
the issue.

Change-Id: I3f3ada8a413a414dca0bbac53cfc5fe3138af4d6
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb7dfee..2bb6233 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev)
connector->funcs->dpms(connector, connector->dpms);
}

-   drm_helper_resume_force_mode(dev);
drm_modeset_unlock_all(dev);
+   drm_helper_resume_force_mode(dev);

return 0;
 }
-- 
1.7.9.5

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #75 from Tom Stellard  ---
Created attachment 98258
  --> https://bugs.freedesktop.org/attachment.cgi?id=98258=edit
Tahiti Fix

Hristo, can you try this kernel patch?

-- 
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/20140430/01bd129c/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

[bugzilla-dae...@freedesktop.org]

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

Tom Stellard  changed:

   What|Removed |Added

  Attachment #92941|0   |1
is obsolete||

--- Comment #74 from Tom Stellard  ---
Created attachment 98257
  --> https://bugs.freedesktop.org/attachment.cgi?id=98257=edit
Fix v2

Pali, I have sent this patch to the mailing list for review, can you confirm
that it fixes the issue for you.

-- 
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/20140430/b4d593a5/attachment.html>

[RFC 0/3] DRM driver for the ATMEL High end LCD controller

[Jean-Jacques Hiblot]

Hi Tim,

On 04/24/2014 02:46 PM, Tim Niemeyer wrote:
> 
> Hi Boris
> 
> Am Donnerstag, den 24.04.2014, 14:14 +0200 schrieb Boris BREZILLON:
>> Hi Tim,
>>
>> On 23/04/2014 17:36, Tim Niemeyer wrote:
>>> Hi Jean-Jacques,
>>>
>>> Am Freitag, den 18.04.2014, 11:45 +0200 schrieb Jean-Jacques Hiblot:
 Hi,

 this patch serie implements a simple DRM driver for the ATMEL High end LCD
 controller found in the SAMA5 familly. It's based on the tilcdc driver.
 It uses the cma_helper for memory and fbdev stuff.
 Your comments are welcome !
>>> I applied your and Robert's patches on a 3.15-rc2 kernel and tried the
>>> framebuffer device on the sama5d31-ek. Seems to work.
>>>
 Supported features:
 * the base layer (the main framebuffer)
>>> Tested to show a little tux png, but it's appearing only after 
>>> 'echo 0 > /sys/devices/ahb.1/apb.2/f003.hlcdc/graphics/fb0/rotate'
>>> is there missing some initializing?
>>
>> Could you try to apply this http://code.bulix.org/f01kvh-86117 ?
> I can't see any difference with that.
> 
> I used fbv to display the tux. With CONFIG_FRAMEBUFFER_CONSOLE=n the
> display stays with a small atmel logo and u-Boot version information. If
> i set CONFIG_FRAMEBUFFER_CONSOLE=y, the display is black after kernel
> start and fbv just works as expected.
> 
I've been able to reproduce the problem. After some digging, I found
that trigerring a hotplug event with drm_kms_helper_hotplug_event() to
trigger a detection of the connectors at the end of atmel_hlcdc_load()
solves the issue. I don't know if this is a proper way to fix it though.


> Best Regards,
> Tim
> 
>> Best Regards,
>>
>> Boris
>>
>>>
 * a simple panel
 * a backlight driver
>>> Tested to set brightness to 0, 20 and 255. Works.
>>>
>>> Thanks for your work.
>>>
>>> Best Regards
>>> Tim
>>>
 * structure to 'easily' add other connectors (it comes from the tilcdc)

 On the todo list:
 * support overlays as drm_planes
 * support for the hardware cursor
 * support for the SiI9022 HDMI connector (present on sama5d36ek)


 Jean-Jacques Hiblot (3):
   atmel: drm: added drm driver for the atmel hlcd controller
   atmel: drm: dt: Added DT entry for the atmel hlcdc found in the sama5
   atmel: dt: Add supports for the lcdc support on the sama5d36ek

  arch/arm/boot/dts/sama5d36ek.dts   |  27 +-
  arch/arm/boot/dts/sama5d3_lcd.dtsi |  11 +
  drivers/gpu/drm/Kconfig|   2 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/atmel_hlcdc/Kconfig|  13 +
  drivers/gpu/drm/atmel_hlcdc/Makefile   |  12 +
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h  | 771 
 +
  .../gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.c|  92 +++
  .../gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.h|  25 +
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c | 702 
 +++
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.c  | 586 
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.h  | 124 
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_ovl.h  | 190 +
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.c| 459 
  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.h|  28 +
  15 files changed, 3042 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Kconfig
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Makefile
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.c
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.h
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.c
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.h
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_ovl.h
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.c
  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.h

 --
 1.9.1


 ___
 linux-arm-kernel mailing list
 linux-arm-kernel at lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
> 
> 

[RFC PATCH 4/4] drm/panel/ld9040: do not power off panel on removal

[Andrzej Hajda]

Panel is powered off already by connector during drm_panel_remove call.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/panel-ld9040.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
index 1f1f837..1def4b0 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -348,7 +348,6 @@ static int ld9040_remove(struct spi_device *spi)
 {
struct ld9040 *ctx = spi_get_drvdata(spi);

-   ld9040_power_off(ctx);
drm_panel_remove(>panel);

return 0;
-- 
1.8.3.2

[RFC PATCH 3/4] drm/exynos/dpi: add interface tracker support

[Andrzej Hajda]

exynos_dpi uses connector polling for tracking panel presence,
this solution introduces unnecessary 10s delay before panel activation.
Moreover it is unsafe, module unloading or driver unbinding can
cause system crash. interface_tracker support solves both problems.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 58 ++---
 1 file changed, 47 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 2b09c7c..4c6682f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
 #include 
 #include 

+#include 
 #include 

 #include 
@@ -21,6 +22,8 @@

 #include "exynos_drm_drv.h"

+static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode);
+
 struct exynos_dpi {
struct device *dev;
struct device_node *panel_node;
@@ -28,6 +31,7 @@ struct exynos_dpi {
struct drm_panel *panel;
struct drm_connector connector;
struct drm_encoder *encoder;
+   struct interface_tracker_block itb;

struct videomode *vm;
int dpms_mode;
@@ -41,15 +45,9 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
force)
struct exynos_dpi *ctx = connector_to_dpi(connector);

/* panels supported only by boot-loader are always connected */
-   if (!ctx->panel_node)
+   if (ctx->vm)
return connector_status_connected;

-   if (!ctx->panel) {
-   ctx->panel = of_drm_find_panel(ctx->panel_node);
-   if (ctx->panel)
-   drm_panel_attach(ctx->panel, >connector);
-   }
-
if (ctx->panel)
return connector_status_connected;

@@ -114,6 +112,28 @@ static struct drm_connector_helper_funcs 
exynos_dpi_connector_helper_funcs = {
.best_encoder = exynos_dpi_best_encoder,
 };

+void exynos_dpi_notifier(struct interface_tracker_block *itb,
+const void *object, unsigned long type, bool on,
+void *data)
+{
+   struct exynos_dpi *ctx = container_of(itb, struct exynos_dpi, itb);
+
+   mutex_lock(>connector.dev->mode_config.mutex);
+   if (on) {
+   ctx->panel = data;
+   drm_panel_attach(ctx->panel, >connector);
+   } else {
+   struct exynos_drm_display *display;
+
+   display = platform_get_drvdata(to_platform_device(ctx->dev));
+   exynos_dpi_dpms(display, DRM_MODE_DPMS_OFF);
+   drm_panel_detach(ctx->panel);
+   ctx->panel = NULL;
+   }
+   mutex_unlock(>connector.dev->mode_config.mutex);
+   drm_helper_hpd_irq_event(ctx->connector.dev);
+}
+
 static int exynos_dpi_create_connector(struct exynos_drm_display *display,
   struct drm_encoder *encoder)
 {
@@ -123,10 +143,7 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,

ctx->encoder = encoder;

-   if (ctx->panel_node)
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
-   else
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;

ret = drm_connector_init(encoder->dev, connector,
 _dpi_connector_funcs,
@@ -140,9 +157,27 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);

+   if (ctx->panel_node) {
+   ctx->itb.callback = exynos_dpi_notifier;
+   interface_tracker_register(ctx->panel_node,
+  INTERFACE_TRACKER_TYPE_DRM_PANEL,
+  >itb);
+   }
+
return 0;
 }

+static void exynos_dpi_display_remove(struct exynos_drm_display *display)
+{
+   struct exynos_dpi *ctx = display->ctx;
+
+   if (ctx->panel_node) {
+   interface_tracker_unregister(ctx->panel_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL,
+>itb);
+   }
+}
+
 static void exynos_dpi_poweron(struct exynos_dpi *ctx)
 {
if (ctx->panel)
@@ -178,6 +213,7 @@ static void exynos_dpi_dpms(struct exynos_drm_display 
*display, int mode)

 static struct exynos_drm_display_ops exynos_dpi_display_ops = {
.create_connector = exynos_dpi_create_connector,
+   .remove = exynos_dpi_display_remove,
.dpms = exynos_dpi_dpms
 };

-- 
1.8.3.2

[RFC PATCH 2/4] drm/panel: add interface tracker support

[Andrzej Hajda]

drm_panel framework allows only query for presence of given panel.
It also does not protect panel module from unloading and does not
provide solution for driver unbinding. interface_tracker
should solve both issues.

Signed-off-by: Andrzej Hajda 
---
---
 drivers/gpu/drm/drm_panel.c   | 5 +
 include/linux/interface_tracker.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..72a3c5c 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -22,6 +22,7 @@
  */

 #include 
+#include 
 #include 

 #include 
@@ -41,6 +42,8 @@ int drm_panel_add(struct drm_panel *panel)
mutex_lock(_lock);
list_add_tail(>list, _list);
mutex_unlock(_lock);
+   interface_tracker_ifup(panel->dev->of_node,
+  INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);

return 0;
 }
@@ -48,6 +51,8 @@ EXPORT_SYMBOL(drm_panel_add);

 void drm_panel_remove(struct drm_panel *panel)
 {
+   interface_tracker_ifdown(panel->dev->of_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
mutex_lock(_lock);
list_del_init(>list);
mutex_unlock(_lock);
diff --git a/include/linux/interface_tracker.h 
b/include/linux/interface_tracker.h
index e1eff00..0a08cba 100644
--- a/include/linux/interface_tracker.h
+++ b/include/linux/interface_tracker.h
@@ -6,6 +6,8 @@
 struct list_head;
 struct interface_tracker_block;

+#define INTERFACE_TRACKER_TYPE_DRM_PANEL 1
+
 typedef void (*interface_tracker_fn_t)(struct interface_tracker_block *itb,
   const void *object, unsigned long type,
   bool on, void *data);
-- 
1.8.3.2

[RFC PATCH 1/4] drivers/base: add interface tracker framework

[Andrzej Hajda]

interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound 
to.

Signed-off-by: Andrzej Hajda 
---
 drivers/base/Makefile |   2 +-
 drivers/base/interface_tracker.c  | 307 ++
 include/linux/interface_tracker.h |  27 
 3 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/interface_tracker.c
 create mode 100644 include/linux/interface_tracker.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e..5a45c41 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o
+  topology.o container.o interface_tracker.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/interface_tracker.c b/drivers/base/interface_tracker.c
new file mode 100644
index 000..3d36cba
--- /dev/null
+++ b/drivers/base/interface_tracker.c
@@ -0,0 +1,307 @@
+/*
+ * Generic framework for tracking kernel interfaces
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda 
+ *
+ * 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.
+ *
+ * interface_tracker is a generic framework which allows to track appearance
+ * and disappearance of different interfaces provided by kernel/driver code
+ * inside the kernel. Examples of such interfaces: clocks, phys, regulators,
+ * drm_panel...
+ * Interface is specified by a pair of object pointer and interface type. 
Object
+ * type depends on interface type, for example interface type drm_panel
+ * determines that object is a device_node. Object pointer is used
+ * to distinguish different interfaces of the same type and should identify
+ * object the interface is bound to. For example it could be DT node,
+ * struct device...
+ *
+ * The framework provides two functions for interface providers which should be
+ * called just after interface becomes available or just before interface
+ * removal. Interface consumers can register callback which will be called when
+ * the requested interface changes its state, if during callback registration
+ * the interface is already up, notification will be sent also.
+ *
+ * The framework allows nesting calls, for example it is possible to signal one
+ * interface in tracker callback of another interface. It is done by putting
+ * every request into the queue. If the queue is empty before adding
+ * the request, the queue will be processed after, if there is already another
+ * request in the queue it means the queue is already processed by different
+ * thread so no additional action is required. With this pattern only spinlock
+ * is necessary to protect the queue. However in case of removal of either
+ * callback or interface caller should be sure that his request has been
+ * processed so framework waits until the queue becomes empty, it is done using
+ * completion mechanism.
+ * The framework functions should not be called in atomic context. Callbacks
+ * should be aware that they can be called in any time between registration and
+ * unregistration, so they should use synchronization mechanisms carefully.
+ * Callbacks should also avoid to perform time consuming tasks, the framework
+ * serializes them, so it could stall other callbacks.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum interface_tracker_task_id {
+   interface_tracker_task_register,
+   interface_tracker_task_unregister,
+   interface_tracker_task_ifup,
+   interface_tracker_task_ifdown,
+};
+
+struct interface_tracker_task {
+   struct list_head list;
+   enum interface_tracker_task_id task_id;
+
+   const void *object;
+   unsigned long type;
+   union {
+   struct interface_tracker_block *itb;
+   void *data;
+   };
+};
+
+struct interface_tracker_node {
+   struct list_head list;
+   struct list_head itb_head;
+   const void *object;
+   unsigned long type;
+   void *data;
+   bool ifup;
+};
+
+static 

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Generic framework for tracking internal interfaces
==

Summary
---

interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound 
to.
For example it could be DT node, struct device,...

The framework provides two functions for interface providers which should be
called just after interface becomes available or just before interface
removal. Interface consumers can register callback which will be called
when requested interface changes its state, if during callback registration
the interface is already up, notification will be sent also.

The framework allows nesting calls, for example it is possible to signal one
interface in tracker callback of another interface. It is done by putting
every request into the queue. If the queue is empty before adding
the request, the queue will be processed after, if there is already another
request in the queue it means the queue is already processed by different
thread so no additional action is required. With this pattern only spinlock
is necessary to protect the queue. However in case of removal of either
callback or interface caller should be sure that his request has been
processed so framework waits until the queue becomes empty, it is done using
completion mechanism.

The framework functions should not be called in atomic context. Callbacks
should be aware that they can be called in any time between registration and
de-registration, so they should use synchronization mechanisms carefully.
Callbacks should also avoid to perform time consuming tasks, the framework
serializes them, so it could stall other callbacks.

Use cases
-

The interface is very generic, there are many situations it can be useful:

1. Replacement for subsystem specific methods of publishing/unpublishing
interfaces. Currently many frameworks allows only querying for presence of given
interface. In such cases client can defer probing or implement interface
polling, which is usually subobtimal. Additionally subsystems often do not
provide methods to signal to the consumers that they are about to be destroyed.

2. Monitoring for different interfaces provided by the same object. An example
should explain it better. Lets assume in device tree drm crtc device node have
video link to another node, so it knows only that there is something connected
to its RGB output. It can be a RGB panel (drm_panel framework), it can be an
image enhancer (SoC specific framework) or it can be some signal converter
(drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to
another node. Currently it is difficult to handle such situations in a generic
way. interface_tracker should make it simple: crtc should monitor all supported
interface types that appears at the device_node pointed by the phandle.

Potential use cases
---

Points mentioned above were the reasons for writing this framework. During
development I have realized that this framework can be also useful for other
tasks.

3. Replacement for deferred probing - if for some reason driver do not wants to
defer but it requires given resources it can use interface_tracker. It should be
possible to create an helper which will wait for appearance of all interfaces
from a given list, and 'continue' probe only when all resources becomes
available.

4. Replacement or helper for subsystem specific solutions:
- V4L2 subdev async registration,
- component framework.
Both frameworks solves a problem of tracking sub-components (un-)registration
by master device, it should be possible to do the same with interface_tracker
framework. Some additional helpers can be convienent to make the implementation
easier.

5. Cure the situation with sysfs 'unbind' property. Currently many drivers are
providers of different resources/interfaces: regulators, clocks, phys,
V4L2 subdevs, ... They are usually protected from module unloading by getting
module reference, but there is no protection from driver unbinding using sysfs
method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer
stays with the pointer to non-existing object, next time it tries to use it
system usually crashes. interface_tracker do not add any protection, but it adds
a way to signal to the consumer that given resource will disappear. It allows
to handle such situations more gently.

Potential issues/extensions
---

1. Scalability - the framework serializes all tasks and callbacks. In case there
are no many 

[PATCH] drm/radeon/dp: check for errors in dpcd reads

[Christian König]

Am 30.04.2014 15:27, schrieb Alex Deucher:
> Check to make sure the transaction succeeded before
> using the register value.  Fixes occasional link training
> problems.
>
> Noticed-by: Sergei Antonov 
> Signed-off-by: Alex Deucher 

Applied to my 3.15 queue.

Christian.

> ---
>   drivers/gpu/drm/radeon/atombios_dp.c | 44 
> 
>   1 file changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index bc0119f..54e4f52 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -366,11 +366,11 @@ static void radeon_dp_probe_oui(struct radeon_connector 
> *radeon_connector)
>   if (!(dig_connector->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
>   return;
>   
> - if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
> 3))
> + if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
> 3) == 3)
>   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
> buf[0], buf[1], buf[2]);
>   
> - if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
> buf, 3))
> + if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
> buf, 3) == 3)
>   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> buf[0], buf[1], buf[2]);
>   }
> @@ -419,21 +419,23 @@ int radeon_dp_get_panel_mode(struct drm_encoder 
> *encoder,
>   
>   if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
>   /* DP bridge chips */
> - drm_dp_dpcd_readb(_connector->ddc_bus->aux,
> -   DP_EDP_CONFIGURATION_CAP, );
> - if (tmp & 1)
> - panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
> - else if ((dp_bridge == ENCODER_OBJECT_ID_NUTMEG) ||
> -  (dp_bridge == ENCODER_OBJECT_ID_TRAVIS))
> - panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
> - else
> - panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
> + if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
> +   DP_EDP_CONFIGURATION_CAP, ) == 1) {
> + if (tmp & 1)
> + panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
> + else if ((dp_bridge == ENCODER_OBJECT_ID_NUTMEG) ||
> +  (dp_bridge == ENCODER_OBJECT_ID_TRAVIS))
> + panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
> + else
> + panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
> + }
>   } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>   /* eDP */
> - drm_dp_dpcd_readb(_connector->ddc_bus->aux,
> -   DP_EDP_CONFIGURATION_CAP, );
> - if (tmp & 1)
> - panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
> + if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
> +   DP_EDP_CONFIGURATION_CAP, ) == 1) {
> + if (tmp & 1)
> + panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
> + }
>   }
>   
>   return panel_mode;
> @@ -809,11 +811,15 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
>   else
>   dp_info.enc_id |= ATOM_DP_CONFIG_LINK_A;
>   
> - drm_dp_dpcd_readb(_connector->ddc_bus->aux, DP_MAX_LANE_COUNT, 
> );
> - if (ASIC_IS_DCE5(rdev) && (tmp & DP_TPS3_SUPPORTED))
> - dp_info.tp3_supported = true;
> - else
> + if (drm_dp_dpcd_readb(_connector->ddc_bus->aux, 
> DP_MAX_LANE_COUNT, )
> + == 1) {
> + if (ASIC_IS_DCE5(rdev) && (tmp & DP_TPS3_SUPPORTED))
> + dp_info.tp3_supported = true;
> + else
> + dp_info.tp3_supported = false;
> + } else {
>   dp_info.tp3_supported = false;
> + }
>   
>   memcpy(dp_info.dpcd, dig_connector->dpcd, DP_RECEIVER_CAP_SIZE);
>   dp_info.rdev = rdev;

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

[Inki Dae]

> -Original Message-
> From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel
> Kurtz
> Sent: Wednesday, April 30, 2014 3:21 PM
> To: Inki Dae
> Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
> Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before enabling
> iommu
> 
> On Wed, Apr 30, 2014 at 1:44 PM, Inki Dae  wrote:
> > Hi Daniel,
> >
> > Please use only text format. :)
> >
> >
> >>From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of
> >>Daniel Kurtz
> >>Sent: Wednesday, April 30, 2014 1:57 PM
> >>To: Inki Dae
> >>Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
> >>Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before
> >>enabling iommu
> >>
> >>
> >>
> >>On Tue, Apr 29, 2014 at 9:38 AM, Inki Dae  wrote:
> >>From: Akshu Agrawal 
> >>
> >>If any fimd channel was already active, initializing iommu will result
> >>in a PAGE FAULT (e.e. u-boot could have turned on the display and not
> >>disabled it before the kernel starts). This patch checks if any
> >>channel is active before initializing iommu and disables it.
> >>
> >>Changelog v2:
> >>- consider SoC without SHADOWCON register
> >>
> >>Signed-off-by: Akshu Agrawal 
> >>Signed-off-by: Prathyush K 
> >>Signed-off-by: Inki Dae 
> >>---
> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c |   70 +--
> ---
> >> 1 file changed, 50 insertions(+), 20 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>index 40fd6cc..ef21ce4 100644
> >>--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>@@ -143,6 +143,48 @@ static inline struct fimd_driver_data
> *drm_fimd_get_driver_data(
> >>return (struct fimd_driver_data *)of_id->data;  }
> >>
> >>+static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr) {
> >>+   struct fimd_context *ctx = mgr->ctx;
> >>+
> >>+   if (ctx->suspended)
> >>+   return;
> >>+
> >>
> >>Hi Inki,
> >>
> >>I think you need this to guarantee that the irq is actually enabled:
> >>
> >
> > Right, it needs to make sure that the irq is enabled.
> >
> >
> >>   drm_vblank_get(ctx->drm_dev, ctx->pipe);
> >>
> >>+   atomic_set(>wait_vsync_event, 1);
> >>+
> >>+   /*
> >>+* wait for FIMD to signal VSYNC interrupt or return after
> >>+* timeout which is set to 50ms (refresh rate of 20).
> >>+*/
> >>+   if (!wait_event_timeout(ctx->wait_vsync_queue,
> >>+   !atomic_read(>wait_vsync_event),
> >>+   HZ/20))
> >>+   DRM_DEBUG_KMS("vblank wait timed out.\n");
> >>
> >>   drm_vblank_put(ctx->drm_dev, ctx->pipe);
> >>
> >>+}
> >>+
> >>+
> >>+static void fimd_clear_channel(struct exynos_drm_manager *mgr) {
> >>+   struct fimd_context *ctx = mgr->ctx;
> >>+   int win, ch_enabled = 0;
> >>+
> >>+   DRM_DEBUG_KMS("%s\n", __FILE__);
> >>+
> >>+   /* Check if any channel is enabled. */
> >>+   for (win = 0; win < WINDOWS_NR; win++) {
> >>+   u32 val = readl(ctx->regs + SHADOWCON);
> >>+   if (val & SHADOWCON_CHx_ENABLE(win)) {
> >>+   val &= ~SHADOWCON_CHx_ENABLE(win);
> >>+   writel(val, ctx->regs + SHADOWCON);
> >>+   ch_enabled = 1;
> >>+   }
> >>+   }
> >>+
> >>+   /* Wait for vsync, as disable channel takes effect at next vsync
> */
> >>+   if (ch_enabled)
> >>+   fimd_wait_for_vblank(mgr); }
> >>+
> >> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
> >>struct drm_device *drm_dev, int pipe)  { @@
> >>-169,8 +211,15 @@ static int fimd_mgr_initialize(struct
> exynos_drm_manager *mgr,
> >>drm_dev->vblank_disable_allowed = true;
> >>
> >>/* attach this sub driver to iommu mapping if supported. */
> >>-   if (is_drm_iommu_supported(ctx->drm_dev))
> >>+   if (is_drm_iommu_supported(ctx->drm_dev)) {
> >>+   /*
> >>+* If any channel is already active, iommu will throw
> >>+* a PAGE FAULT when enabled. So clear any channel if
> enabled.
> >>+*/
> >>+   if (ctx->driver_data->has_shadowcon)
> >>+   fimd_clear_channel(mgr);
> >>
> >>We already disable all overlays at the end of fimd_probe() by calling
> fimd_clear_win().
> >>Perhaps all that was missing was just waiting until the next vblank to
> ensure that these clears have all completed?
> >>
> >
> > No, fimd_mgr_initialize() will be called at load() so the iommu unit for
> fimd ip will be tried to be enabled prior to fimd_clear_channel() call -
> before all dma channels are disabled. In this case, page fault could be
> incurred if fimd ip was already on by bootloader.
> 
> Right.  So, I suggest moving drm_iommu_attach_device() from mgr_initialize
> to 

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

[Inki Dae]

> -Original Message-
> From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel
> Kurtz
> Sent: Wednesday, April 30, 2014 3:21 PM
> To: Inki Dae
> Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
> Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before enabling
> iommu
> 
> On Wed, Apr 30, 2014 at 1:44 PM, Inki Dae  wrote:
> > Hi Daniel,
> >
> > Please use only text format. :)
> >
> >
> >>From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of
> >>Daniel Kurtz
> >>Sent: Wednesday, April 30, 2014 1:57 PM
> >>To: Inki Dae
> >>Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
> >>Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before
> >>enabling iommu
> >>
> >>
> >>
> >>On Tue, Apr 29, 2014 at 9:38 AM, Inki Dae  wrote:
> >>From: Akshu Agrawal 
> >>
> >>If any fimd channel was already active, initializing iommu will result
> >>in a PAGE FAULT (e.e. u-boot could have turned on the display and not
> >>disabled it before the kernel starts). This patch checks if any
> >>channel is active before initializing iommu and disables it.
> >>
> >>Changelog v2:
> >>- consider SoC without SHADOWCON register
> >>
> >>Signed-off-by: Akshu Agrawal 
> >>Signed-off-by: Prathyush K 
> >>Signed-off-by: Inki Dae 
> >>---
> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c |   70 +--
> ---
> >> 1 file changed, 50 insertions(+), 20 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>index 40fd6cc..ef21ce4 100644
> >>--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>@@ -143,6 +143,48 @@ static inline struct fimd_driver_data
> *drm_fimd_get_driver_data(
> >>return (struct fimd_driver_data *)of_id->data;  }
> >>
> >>+static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr) {
> >>+   struct fimd_context *ctx = mgr->ctx;
> >>+
> >>+   if (ctx->suspended)
> >>+   return;
> >>+
> >>
> >>Hi Inki,
> >>
> >>I think you need this to guarantee that the irq is actually enabled:
> >>
> >
> > Right, it needs to make sure that the irq is enabled.
> >
> >
> >>   drm_vblank_get(ctx->drm_dev, ctx->pipe);
> >>
> >>+   atomic_set(>wait_vsync_event, 1);
> >>+
> >>+   /*
> >>+* wait for FIMD to signal VSYNC interrupt or return after
> >>+* timeout which is set to 50ms (refresh rate of 20).
> >>+*/
> >>+   if (!wait_event_timeout(ctx->wait_vsync_queue,
> >>+   !atomic_read(>wait_vsync_event),
> >>+   HZ/20))
> >>+   DRM_DEBUG_KMS("vblank wait timed out.\n");
> >>
> >>   drm_vblank_put(ctx->drm_dev, ctx->pipe);
> >>
> >>+}
> >>+
> >>+
> >>+static void fimd_clear_channel(struct exynos_drm_manager *mgr) {
> >>+   struct fimd_context *ctx = mgr->ctx;
> >>+   int win, ch_enabled = 0;
> >>+
> >>+   DRM_DEBUG_KMS("%s\n", __FILE__);
> >>+
> >>+   /* Check if any channel is enabled. */
> >>+   for (win = 0; win < WINDOWS_NR; win++) {
> >>+   u32 val = readl(ctx->regs + SHADOWCON);
> >>+   if (val & SHADOWCON_CHx_ENABLE(win)) {
> >>+   val &= ~SHADOWCON_CHx_ENABLE(win);
> >>+   writel(val, ctx->regs + SHADOWCON);
> >>+   ch_enabled = 1;
> >>+   }
> >>+   }
> >>+
> >>+   /* Wait for vsync, as disable channel takes effect at next vsync
> */
> >>+   if (ch_enabled)
> >>+   fimd_wait_for_vblank(mgr); }
> >>+
> >> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
> >>struct drm_device *drm_dev, int pipe)  { @@
> >>-169,8 +211,15 @@ static int fimd_mgr_initialize(struct
> exynos_drm_manager *mgr,
> >>drm_dev->vblank_disable_allowed = true;
> >>
> >>/* attach this sub driver to iommu mapping if supported. */
> >>-   if (is_drm_iommu_supported(ctx->drm_dev))
> >>+   if (is_drm_iommu_supported(ctx->drm_dev)) {
> >>+   /*
> >>+* If any channel is already active, iommu will throw
> >>+* a PAGE FAULT when enabled. So clear any channel if
> enabled.
> >>+*/
> >>+   if (ctx->driver_data->has_shadowcon)
> >>+   fimd_clear_channel(mgr);
> >>
> >>We already disable all overlays at the end of fimd_probe() by calling
> fimd_clear_win().
> >>Perhaps all that was missing was just waiting until the next vblank to
> ensure that these clears have all completed?
> >>
> >
> > No, fimd_mgr_initialize() will be called at load() so the iommu unit for
> fimd ip will be tried to be enabled prior to fimd_clear_channel() call -
> before all dma channels are disabled. In this case, page fault could be
> incurred if fimd ip was already on by bootloader.
> 
> Right.  So, I suggest moving drm_iommu_attach_device() from mgr_initialize
> to 

[RFC 0/2] drm/bridge: panel and chaining

[Inki Dae]

Hi Rob,

> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
> Of Rob Clark
> Sent: Wednesday, April 30, 2014 4:58 AM
> To: dri-devel at lists.freedesktop.org
> Cc: Ajay Kumar
> Subject: [RFC 0/2] drm/bridge: panel and chaining
> 
> So I thought it would be easier to explain what I had in mind regarding
> Ajay's patchset (to add panel support) in patch form.  Originally Thierry
> had some concerns with adding panel support in bridges ad-hoc.  So this
> idea adds the support of chaining multiple bridges, one of which may be a
> panal adapter (maybe I should have called it drm_panel_adapter_bridge).
> There are a few rough edges and TODOs, it isn't trying to be complete yet.
> 
> So the one question is about that hunk I had to move in ptn3460 from
> pre_enable() to enable().  If that really needs to come before the encoder
> and after the panel, then we should go for a slightly different approach
> instead: add a 'struct drm_bridge *next' ptr in 'struct drm_bridge'.  Then
> each bridge implementation is responsible to call the next in the chain
> (if not null) at the appropriate points.  That gives a bit more
> flexibility to bridges to have something both pre and post the downstream
> bridge/panel in each of the pre/enable/disable/post steps.
> 

I think there would be better idea than chaining multiple bridges. For this,
we had already discussed it[1], and I had posted relevant patch[2] for RFC.

My idea was that encoder driver has one or two bridge objects - for panel
and lvds, and also image enhancer for crtc driver. The integrated drm_bridge
structure including callback set for them. Originally, it was called
"drm_hw_block" but would be reasonable to change to "drm_bridge" and
existing drm_bridge relevant codes should be removed.

The important thing in my approach is that the integrated drm_bridge
structure uses existing drm_panel infrastructure. The reason I did so was
for that bridge device drivers such as lvds and image enhancer could comply
with driver-model - now bridge drivers are non driver-model driver so
encoder drivers should call some function directly to initialize the bridge
driver. e.g. ptn3460_init function.

And also with this approach crtc drivers could control bridge device such as
image enhancer - Image enhancer can be placed between crtc and
encoder/connector, and actually Exynos SoC has such hardware.

For this, I'm planning to post next patch series, at least within this
cycle.

[1] http://www.spinics.net/lists/dri-devel/msg5.html
[2]http://www.spinics.net/lists/dri-devel/msg55658.html


Thanks,
Inki Dae

> 
> Rob Clark (2):
>   drm/bridge: add composite and panel bridges
>   drm/bridge/ptn3460: add panel support
> 
>  drivers/gpu/drm/bridge/Makefile  |   2 +
>  drivers/gpu/drm/bridge/drm_bridge_util.c | 251
> +++  drivers/gpu/drm/bridge/drm_bridge_util.h
> |  29 
>  drivers/gpu/drm/bridge/ptn3460.c |  39 -
>  include/drm/bridge/ptn3460.h |   6 +-
>  5 files changed, 319 insertions(+), 8 deletions(-)  create mode 100644
> drivers/gpu/drm/bridge/drm_bridge_util.c
>  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
> 
> --
> 1.9.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/2] drm/bridge: panel and chaining

[Rob Clark]

On Wed, Apr 30, 2014 at 1:46 PM, Sean Paul  wrote:
> On Wed, Apr 30, 2014 at 11:38 AM, Rob Clark  wrote:
>> On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar  wrote:
>>>
>>> On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA 
>>>  wrote:





 --- Original Message ---

 Sender : Sean Paul

 Date : Apr 30, 2014 02:34 (GMT+05:30)

 Title : Re: [RFC 0/2] drm/bridge: panel and chaining



 On Tue, Apr 29, 2014 at 3:57 PM, Rob Clark wrote:
 > So I thought it would be easier to explain what I had in mind regarding
 > Ajay's patchset (to add panel support) in patch form.  Originally Thierry
 > had some concerns with adding panel support in bridges ad-hoc.  So this
 > idea adds the support of chaining multiple bridges, one of which may be
 > a panal adapter (maybe I should have called it drm_panel_adapter_bridge).
 > There are a few rough edges and TODOs, it isn't trying to be complete
 > yet.
 >
 > So the one question is about that hunk I had to move in ptn3460 from
 > pre_enable() to enable().  If that really needs to come before the
 > encoder and after the panel, then we should go for a slightly different
 > approach instead: add a 'struct drm_bridge *next' ptr in 'struct
 > drm_bridge'.  Then each bridge implementation is responsible to call
 > the next in the chain (if not null) at the appropriate points.  That
 > gives a bit more flexibility to bridges to have something both pre and
 > post the downstream bridge/panel in each of the pre/enable/disable/post
 > steps.

 Arbitrarily chaining bridges seems like a more robust solution to me
 than the composite bridge.

 For the panel case, I wonder if we could change drm_bridge_init to
 accept a panel, then we could just chain the panel calls off the
 various places the bridge hooks are invoked in the drm layer.
>>>
>>>
>>> This idea originated from Rob itself. He wanted to move out drm_panel calls
>>> from both ptn3460 and ps8622 drivers and he wanted them at a common place.
>>> But Daniel suggested that having a chain of bridges is good. That is how
>>> composite_bridge was formed.
>>
>> so I'm thinking that, given what Sean and others have said, that the
>> chaining inside bridge implementation would give more flexibility.  By
>> which I mean:
>>
>>  struct drm_bridge {
>> +struct drm_bridge *next;/* the next in the chain */
>>   
>>  };
>>
>> and then in each bridge implementation would do something like this
>> for each fxn:
>>
>>  static void foo_bridge_pre_enable(...)
>>  {
>>   ... do stuff before ...
>> +if (bridge->next)
>> + bridge->next->pre_enable(...);
>>  ... do stuff after ...
>>  }
>>
>> it would mean now all bridge fxns are now required, even if they only
>> call next in chain.. we can toss in some helpers for that.
>>
>> For dealing with panels, and this gets into Inki's proposal, I think
>> we can just declare that panels themselves implement drm_bridge
>> interface if needed.  So drm_panel_funcs is for extra API's needed by
>> connector (like get_modes()) and everything else is part of
>> drm_bridge_funcs.
>>
>
> So if we do this, we can add panels off the end (or wherever) of the
> chain transparently, masquerading as bridges? That sounds like a
> pretty good solution to me.

yup, that is pretty much what I'm thinking.  Some difference in
implementation details, but I think it covers what Inki wants too

BR,
-R


> Sean
>
>
>> BR,
>> -R
>>
>>> I still think we are addressing a very simple problem in a complex manner.
>>> I tried testing this patchset on my board, with some tweaks(explained in 
>>> PATCH 2/2]),
>>> and I could get it working. This code basically adds 3 bridge structures to 
>>> handle the calls,
>>> but in actual hardware you can map them to only one bridge device.
>>> I am still not sure what's the problem in just having the panel calls around
>>> the bridge calls in drm core?
>>>

 Feel free to ignore if this has already been explored on the other
 thread (which I haven't been following).

 Sean



 >
 >
 > Rob Clark (2):
 >   drm/bridge: add composite and panel bridges
 >   drm/bridge/ptn3460: add panel support
 >
 >  drivers/gpu/drm/bridge/Makefile  |   2 +
 >  drivers/gpu/drm/bridge/drm_bridge_util.c | 251 
 > +++
 >  drivers/gpu/drm/bridge/drm_bridge_util.h |  29 
 >  drivers/gpu/drm/bridge/ptn3460.c |  39 -
 >  include/drm/bridge/ptn3460.h |   6 +-
 >  5 files changed, 319 insertions(+), 8 deletions(-)
 >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c
 >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
 >
 > --
 > 1.9.0
 >
 > ___
 > dri-devel mailing list
 

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

[Inki Dae]

Hi Daniel,

Please use only text format. :)


>From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel 
>Kurtz
>Sent: Wednesday, April 30, 2014 1:57 PM
>To: Inki Dae
>Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
>Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before enabling iommu
>
>
>
>On Tue, Apr 29, 2014 at 9:38 AM, Inki Dae  wrote:
>From: Akshu Agrawal 
>
>If any fimd channel was already active, initializing iommu will result
>in a PAGE FAULT (e.e. u-boot could have turned on the display and
>not disabled it before the kernel starts). This patch checks if any
>channel is active before initializing iommu and disables it.
>
>Changelog v2:
>- consider SoC without SHADOWCON register
>
>Signed-off-by: Akshu Agrawal 
>Signed-off-by: Prathyush K 
>Signed-off-by: Inki Dae 
>---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |   70 +-
> 1 file changed, 50 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>index 40fd6cc..ef21ce4 100644
>--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>@@ -143,6 +143,48 @@ static inline struct fimd_driver_data 
>*drm_fimd_get_driver_data(
>return (struct fimd_driver_data *)of_id->data;
> }
>
>+static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
>+{
>+   struct fimd_context *ctx = mgr->ctx;
>+
>+   if (ctx->suspended)
>+   return;
>+
>
>Hi Inki,
>
>I think you need this to guarantee that the irq is actually enabled:
>

Right, it needs to make sure that the irq is enabled.


>   drm_vblank_get(ctx->drm_dev, ctx->pipe);
>
>+   atomic_set(>wait_vsync_event, 1);
>+
>+   /*
>+* wait for FIMD to signal VSYNC interrupt or return after
>+* timeout which is set to 50ms (refresh rate of 20).
>+*/
>+   if (!wait_event_timeout(ctx->wait_vsync_queue,
>+   !atomic_read(>wait_vsync_event),
>+   HZ/20))
>+   DRM_DEBUG_KMS("vblank wait timed out.\n");
>
>   drm_vblank_put(ctx->drm_dev, ctx->pipe);
> 
>+}
>+
>+
>+static void fimd_clear_channel(struct exynos_drm_manager *mgr)
>+{
>+   struct fimd_context *ctx = mgr->ctx;
>+   int win, ch_enabled = 0;
>+
>+   DRM_DEBUG_KMS("%s\n", __FILE__);
>+
>+   /* Check if any channel is enabled. */
>+   for (win = 0; win < WINDOWS_NR; win++) {
>+   u32 val = readl(ctx->regs + SHADOWCON);
>+   if (val & SHADOWCON_CHx_ENABLE(win)) {
>+   val &= ~SHADOWCON_CHx_ENABLE(win);
>+   writel(val, ctx->regs + SHADOWCON);
>+   ch_enabled = 1;
>+   }
>+   }
>+
>+   /* Wait for vsync, as disable channel takes effect at next vsync */
>+   if (ch_enabled)
>+   fimd_wait_for_vblank(mgr);
>+}
>+
> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
>struct drm_device *drm_dev, int pipe)
> {
>@@ -169,8 +211,15 @@ static int fimd_mgr_initialize(struct exynos_drm_manager 
>*mgr,
>drm_dev->vblank_disable_allowed = true;
>
>/* attach this sub driver to iommu mapping if supported. */
>-   if (is_drm_iommu_supported(ctx->drm_dev))
>+   if (is_drm_iommu_supported(ctx->drm_dev)) {
>+   /*
>+* If any channel is already active, iommu will throw
>+* a PAGE FAULT when enabled. So clear any channel if enabled.
>+*/
>+   if (ctx->driver_data->has_shadowcon)
>+   fimd_clear_channel(mgr);
>
>We already disable all overlays at the end of fimd_probe() by calling 
>fimd_clear_win().
>Perhaps all that was missing was just waiting until the next vblank to ensure 
>that these clears have all completed?
>

No, fimd_mgr_initialize() will be called at load() so the iommu unit for fimd 
ip will be tried to be enabled prior to fimd_clear_channel() call - before all 
dma channels are disabled. In this case, page fault could be incurred if fimd 
ip was already on by bootloader. 

Thanks,
Inki Dae

>Best Regards,
>-Daniel
>
>drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
>+   }
>
>return 0;
> }
>@@ -324,25 +373,6 @@ static void fimd_disable_vblank(struct exynos_drm_manager 
>*mgr)
>}
> }
>
>-static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
>-{
>-   struct fimd_context *ctx = mgr->ctx;
>-
>-   if (ctx->suspended)
>-   return;
>-
>-   atomic_set(>wait_vsync_event, 1);
>-
>-   /*
>-* wait for FIMD to signal VSYNC interrupt or return after
>-* timeout which is set to 50ms (refresh rate of 20).
>-*/
>-   if (!wait_event_timeout(ctx->wait_vsync_queue,
>-   !atomic_read(>wait_vsync_event),
>-   HZ/20))
>-   

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #73 from Pali Roh?r  ---
@Tom Stellard, @Michel D?nzer: ping

-- 
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/20140430/0dd3d1cd/attachment.html>

[Bug 73931] rmmod radeon and kernel crash

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #10 from Pali Roh?r  ---
@Alex Deucher: ping

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm/exynos: fimd: clear channel before enabling iommu

[Daniel Kurtz]

On Wed, Apr 30, 2014 at 1:44 PM, Inki Dae  wrote:
> Hi Daniel,
>
> Please use only text format. :)
>
>
>>From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of 
>>Daniel Kurtz
>>Sent: Wednesday, April 30, 2014 1:57 PM
>>To: Inki Dae
>>Cc: David Airlie; dri-devel; Akshu Agrawal; Prathyush K
>>Subject: Re: [PATCH v2] drm/exynos: fimd: clear channel before enabling iommu
>>
>>
>>
>>On Tue, Apr 29, 2014 at 9:38 AM, Inki Dae  wrote:
>>From: Akshu Agrawal 
>>
>>If any fimd channel was already active, initializing iommu will result
>>in a PAGE FAULT (e.e. u-boot could have turned on the display and
>>not disabled it before the kernel starts). This patch checks if any
>>channel is active before initializing iommu and disables it.
>>
>>Changelog v2:
>>- consider SoC without SHADOWCON register
>>
>>Signed-off-by: Akshu Agrawal 
>>Signed-off-by: Prathyush K 
>>Signed-off-by: Inki Dae 
>>---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c |   70 
>> +-
>> 1 file changed, 50 insertions(+), 20 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>index 40fd6cc..ef21ce4 100644
>>--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>@@ -143,6 +143,48 @@ static inline struct fimd_driver_data 
>>*drm_fimd_get_driver_data(
>>return (struct fimd_driver_data *)of_id->data;
>> }
>>
>>+static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
>>+{
>>+   struct fimd_context *ctx = mgr->ctx;
>>+
>>+   if (ctx->suspended)
>>+   return;
>>+
>>
>>Hi Inki,
>>
>>I think you need this to guarantee that the irq is actually enabled:
>>
>
> Right, it needs to make sure that the irq is enabled.
>
>
>>   drm_vblank_get(ctx->drm_dev, ctx->pipe);
>>
>>+   atomic_set(>wait_vsync_event, 1);
>>+
>>+   /*
>>+* wait for FIMD to signal VSYNC interrupt or return after
>>+* timeout which is set to 50ms (refresh rate of 20).
>>+*/
>>+   if (!wait_event_timeout(ctx->wait_vsync_queue,
>>+   !atomic_read(>wait_vsync_event),
>>+   HZ/20))
>>+   DRM_DEBUG_KMS("vblank wait timed out.\n");
>>
>>   drm_vblank_put(ctx->drm_dev, ctx->pipe);
>>
>>+}
>>+
>>+
>>+static void fimd_clear_channel(struct exynos_drm_manager *mgr)
>>+{
>>+   struct fimd_context *ctx = mgr->ctx;
>>+   int win, ch_enabled = 0;
>>+
>>+   DRM_DEBUG_KMS("%s\n", __FILE__);
>>+
>>+   /* Check if any channel is enabled. */
>>+   for (win = 0; win < WINDOWS_NR; win++) {
>>+   u32 val = readl(ctx->regs + SHADOWCON);
>>+   if (val & SHADOWCON_CHx_ENABLE(win)) {
>>+   val &= ~SHADOWCON_CHx_ENABLE(win);
>>+   writel(val, ctx->regs + SHADOWCON);
>>+   ch_enabled = 1;
>>+   }
>>+   }
>>+
>>+   /* Wait for vsync, as disable channel takes effect at next vsync */
>>+   if (ch_enabled)
>>+   fimd_wait_for_vblank(mgr);
>>+}
>>+
>> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
>>struct drm_device *drm_dev, int pipe)
>> {
>>@@ -169,8 +211,15 @@ static int fimd_mgr_initialize(struct exynos_drm_manager 
>>*mgr,
>>drm_dev->vblank_disable_allowed = true;
>>
>>/* attach this sub driver to iommu mapping if supported. */
>>-   if (is_drm_iommu_supported(ctx->drm_dev))
>>+   if (is_drm_iommu_supported(ctx->drm_dev)) {
>>+   /*
>>+* If any channel is already active, iommu will throw
>>+* a PAGE FAULT when enabled. So clear any channel if enabled.
>>+*/
>>+   if (ctx->driver_data->has_shadowcon)
>>+   fimd_clear_channel(mgr);
>>
>>We already disable all overlays at the end of fimd_probe() by calling 
>>fimd_clear_win().
>>Perhaps all that was missing was just waiting until the next vblank to ensure 
>>that these clears have all completed?
>>
>
> No, fimd_mgr_initialize() will be called at load() so the iommu unit for fimd 
> ip will be tried to be enabled prior to fimd_clear_channel() call - before 
> all dma channels are disabled. In this case, page fault could be incurred if 
> fimd ip was already on by bootloader.

Right.  So, I suggest moving drm_iommu_attach_device() from
mgr_initialize to fimd_probe(), after clearing the windows and waiting
for vblank.

>
> Thanks,
> Inki Dae
>
>>Best Regards,
>>-Daniel
>>
>>drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
>>+   }
>>
>>return 0;
>> }
>>@@ -324,25 +373,6 @@ static void fimd_disable_vblank(struct 
>>exynos_drm_manager *mgr)
>>}
>> }
>>
>>-static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
>>-{
>>-   struct fimd_context *ctx = mgr->ctx;
>>-
>>-   if (ctx->suspended)
>>-   return;
>>-
>>-   

[Bug 75361] freeze in Mass Effect 3 (wine)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #25 from wdr  ---
Created attachment 98242
  --> https://bugs.freedesktop.org/attachment.cgi?id=98242=edit
mesa-git + llvm (si-spill-fixes-v3) + kernel 3.15-rc3 = gpu hung

-- 
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/20140430/9a7b3c8a/attachment.html>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Rahul Sharma]

Sure (5250, 5420). I will wait for the same to update DT patches, if any.

Regards,
Rahul Sharma.

On 30 April 2014 14:02, Tomasz Stanislawski  wrote:
> Hi Rahul,
> I will prepare we v3 version.
> Do you want me to add your patches for exynos5?50 to the patchset?
> Regards,
> Tomasz Stanislawski
>
> On 04/30/2014 08:37 AM, Rahul Sharma wrote:
>> Hi Tomasz,
>>
>> I have tested your patches for exynos5250 and 5420. Works fine. Are
>> you planning to post v3? If you want I can share hand with you for v3.
>>
>> Regards,
>> Rahul Sharma
>>
>> On 9 April 2014 17:17, Andreas Oberritter  wrote:
>>> Hello Andrzej,
>>>
>>> On 09.04.2014 10:37, Andrzej Hajda wrote:
> +static int exynos_phy_probe(struct platform_device *pdev)
> +{
> +const struct of_device_id *of_id = of_match_device(
> +of_match_ptr(exynos_phy_of_match), >dev);
> +const u32 *offsets = of_id->data;
> +int count;
> +struct device *dev = >dev;
> +struct phy **phys;
> +struct resource *res;
> +void __iomem *regs;
> +int i;
> +struct phy_provider *phy_provider;
> +
> +/* count number of phys to create */
> +for (count = 0; offsets[count] != ~0; ++count)
> +;

 count = ARRAY_SIZE(offsets) - 1;
>>>
>>> u32 *offsets is not an array.
>>>
>>> Regards,
>>> Andreas
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

[RFC 0/2] drm/bridge: panel and chaining

[Sean Paul]

On Wed, Apr 30, 2014 at 11:38 AM, Rob Clark  wrote:
> On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar  wrote:
>>
>> On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA 
>>  wrote:
>>>
>>>
>>>
>>>
>>>
>>> --- Original Message ---
>>>
>>> Sender : Sean Paul
>>>
>>> Date : Apr 30, 2014 02:34 (GMT+05:30)
>>>
>>> Title : Re: [RFC 0/2] drm/bridge: panel and chaining
>>>
>>>
>>>
>>> On Tue, Apr 29, 2014 at 3:57 PM, Rob Clark wrote:
>>> > So I thought it would be easier to explain what I had in mind regarding
>>> > Ajay's patchset (to add panel support) in patch form.  Originally Thierry
>>> > had some concerns with adding panel support in bridges ad-hoc.  So this
>>> > idea adds the support of chaining multiple bridges, one of which may be
>>> > a panal adapter (maybe I should have called it drm_panel_adapter_bridge).
>>> > There are a few rough edges and TODOs, it isn't trying to be complete
>>> > yet.
>>> >
>>> > So the one question is about that hunk I had to move in ptn3460 from
>>> > pre_enable() to enable().  If that really needs to come before the
>>> > encoder and after the panel, then we should go for a slightly different
>>> > approach instead: add a 'struct drm_bridge *next' ptr in 'struct
>>> > drm_bridge'.  Then each bridge implementation is responsible to call
>>> > the next in the chain (if not null) at the appropriate points.  That
>>> > gives a bit more flexibility to bridges to have something both pre and
>>> > post the downstream bridge/panel in each of the pre/enable/disable/post
>>> > steps.
>>>
>>> Arbitrarily chaining bridges seems like a more robust solution to me
>>> than the composite bridge.
>>>
>>> For the panel case, I wonder if we could change drm_bridge_init to
>>> accept a panel, then we could just chain the panel calls off the
>>> various places the bridge hooks are invoked in the drm layer.
>>
>>
>> This idea originated from Rob itself. He wanted to move out drm_panel calls
>> from both ptn3460 and ps8622 drivers and he wanted them at a common place.
>> But Daniel suggested that having a chain of bridges is good. That is how
>> composite_bridge was formed.
>
> so I'm thinking that, given what Sean and others have said, that the
> chaining inside bridge implementation would give more flexibility.  By
> which I mean:
>
>  struct drm_bridge {
> +struct drm_bridge *next;/* the next in the chain */
>   
>  };
>
> and then in each bridge implementation would do something like this
> for each fxn:
>
>  static void foo_bridge_pre_enable(...)
>  {
>   ... do stuff before ...
> +if (bridge->next)
> + bridge->next->pre_enable(...);
>  ... do stuff after ...
>  }
>
> it would mean now all bridge fxns are now required, even if they only
> call next in chain.. we can toss in some helpers for that.
>
> For dealing with panels, and this gets into Inki's proposal, I think
> we can just declare that panels themselves implement drm_bridge
> interface if needed.  So drm_panel_funcs is for extra API's needed by
> connector (like get_modes()) and everything else is part of
> drm_bridge_funcs.
>

So if we do this, we can add panels off the end (or wherever) of the
chain transparently, masquerading as bridges? That sounds like a
pretty good solution to me.

Sean


> BR,
> -R
>
>> I still think we are addressing a very simple problem in a complex manner.
>> I tried testing this patchset on my board, with some tweaks(explained in 
>> PATCH 2/2]),
>> and I could get it working. This code basically adds 3 bridge structures to 
>> handle the calls,
>> but in actual hardware you can map them to only one bridge device.
>> I am still not sure what's the problem in just having the panel calls around
>> the bridge calls in drm core?
>>
>>>
>>> Feel free to ignore if this has already been explored on the other
>>> thread (which I haven't been following).
>>>
>>> Sean
>>>
>>>
>>>
>>> >
>>> >
>>> > Rob Clark (2):
>>> >   drm/bridge: add composite and panel bridges
>>> >   drm/bridge/ptn3460: add panel support
>>> >
>>> >  drivers/gpu/drm/bridge/Makefile  |   2 +
>>> >  drivers/gpu/drm/bridge/drm_bridge_util.c | 251 
>>> > +++
>>> >  drivers/gpu/drm/bridge/drm_bridge_util.h |  29 
>>> >  drivers/gpu/drm/bridge/ptn3460.c |  39 -
>>> >  include/drm/bridge/ptn3460.h |   6 +-
>>> >  5 files changed, 319 insertions(+), 8 deletions(-)
>>> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c
>>> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
>>> >
>>> > --
>>> > 1.9.0
>>> >
>>> > ___
>>> > 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 v2] drm/exynos: fimd: clear channel before enabling iommu

[Daniel Kurtz]

On Tue, Apr 29, 2014 at 9:38 AM, Inki Dae  wrote:

> From: Akshu Agrawal 
>
> If any fimd channel was already active, initializing iommu will result
> in a PAGE FAULT (e.e. u-boot could have turned on the display and
> not disabled it before the kernel starts). This patch checks if any
> channel is active before initializing iommu and disables it.
>
> Changelog v2:
> - consider SoC without SHADOWCON register
>
> Signed-off-by: Akshu Agrawal 
> Signed-off-by: Prathyush K 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   70
> +-
>  1 file changed, 50 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 40fd6cc..ef21ce4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -143,6 +143,48 @@ static inline struct fimd_driver_data
> *drm_fimd_get_driver_data(
> return (struct fimd_driver_data *)of_id->data;
>  }
>
> +static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
> +{
> +   struct fimd_context *ctx = mgr->ctx;
> +
> +   if (ctx->suspended)
> +   return;
> +
>

Hi Inki,

I think you need this to guarantee that the irq is actually enabled:

drm_vblank_get(ctx->drm_dev, ctx->pipe);

+   atomic_set(>wait_vsync_event, 1);
> +
> +   /*
> +* wait for FIMD to signal VSYNC interrupt or return after
> +* timeout which is set to 50ms (refresh rate of 20).
> +*/
> +   if (!wait_event_timeout(ctx->wait_vsync_queue,
> +   !atomic_read(>wait_vsync_event),
> +   HZ/20))
> +   DRM_DEBUG_KMS("vblank wait timed out.\n");
>

drm_vblank_put(ctx->drm_dev, ctx->pipe);


> +}
> +
> +
> +static void fimd_clear_channel(struct exynos_drm_manager *mgr)
> +{
> +   struct fimd_context *ctx = mgr->ctx;
> +   int win, ch_enabled = 0;
> +
> +   DRM_DEBUG_KMS("%s\n", __FILE__);
> +
> +   /* Check if any channel is enabled. */
> +   for (win = 0; win < WINDOWS_NR; win++) {
> +   u32 val = readl(ctx->regs + SHADOWCON);
> +   if (val & SHADOWCON_CHx_ENABLE(win)) {
> +   val &= ~SHADOWCON_CHx_ENABLE(win);
> +   writel(val, ctx->regs + SHADOWCON);
> +   ch_enabled = 1;
> +   }
> +   }
> +
> +   /* Wait for vsync, as disable channel takes effect at next vsync */
> +   if (ch_enabled)
> +   fimd_wait_for_vblank(mgr);
> +}
> +
>  static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
> struct drm_device *drm_dev, int pipe)
>  {
> @@ -169,8 +211,15 @@ static int fimd_mgr_initialize(struct
> exynos_drm_manager *mgr,
> drm_dev->vblank_disable_allowed = true;
>
> /* attach this sub driver to iommu mapping if supported. */
> -   if (is_drm_iommu_supported(ctx->drm_dev))
> +   if (is_drm_iommu_supported(ctx->drm_dev)) {
> +   /*
> +* If any channel is already active, iommu will throw
> +* a PAGE FAULT when enabled. So clear any channel if
> enabled.
> +*/
> +   if (ctx->driver_data->has_shadowcon)
> +   fimd_clear_channel(mgr);
>

We already disable all overlays at the end of fimd_probe() by calling
fimd_clear_win().
Perhaps all that was missing was just waiting until the next vblank to
ensure that these clears have all completed?

Best Regards,
-Daniel

drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
> +   }
>
> return 0;
>  }
> @@ -324,25 +373,6 @@ static void fimd_disable_vblank(struct
> exynos_drm_manager *mgr)
> }
>  }
>
> -static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
> -{
> -   struct fimd_context *ctx = mgr->ctx;
> -
> -   if (ctx->suspended)
> -   return;
> -
> -   atomic_set(>wait_vsync_event, 1);
> -
> -   /*
> -* wait for FIMD to signal VSYNC interrupt or return after
> -* timeout which is set to 50ms (refresh rate of 20).
> -*/
> -   if (!wait_event_timeout(ctx->wait_vsync_queue,
> -   !atomic_read(>wait_vsync_event),
> -   HZ/20))
> -   DRM_DEBUG_KMS("vblank wait timed out.\n");
> -}
> -
>  static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
> struct exynos_drm_overlay *overlay)
>  {
> --
> 1.7.9.5
>
> ___
> 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/20140430/c1d69d45/attachment.html>

[Bug 75361] freeze in Mass Effect 3 (wine)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #24 from wdr  ---
Created attachment 98238
  --> https://bugs.freedesktop.org/attachment.cgi?id=98238=edit
dmesg wich errors

-- 
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/20140430/a6248242/attachment.html>

[Bug 75361] freeze in Mass Effect 3 (wine)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #23 from wdr  ---
mesa-git + llvm (si-spill-fixes-v3) + kernel 3.14 = gpu hung

-- 
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/20140430/913b76b1/attachment.html>

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem_gtt.c between commitcfa7c862982b
("drm/i915: Sanitize the enable_ppgtt module option once") from the
drm-intel-fixes tree tree and commit 5db6c735ead5 ("drm/i915: dmesg
output for VT-d testing") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem_gtt.c
index 154b0f8bb88d,496916298e8a..
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@@ -62,62 -48,13 +62,9 @@@ static int sanitize_enable_ppgtt(struc
}
  #endif

 -  /* Full ppgtt disabled by default for now due to issues. */
 -  if (full)
 -  return HAS_PPGTT(dev) && (i915.enable_ppgtt == 2);
 -  else
 -  return HAS_ALIASING_PPGTT(dev);
 +  return HAS_ALIASING_PPGTT(dev) ? 1 : 0;
  }

- #define GEN6_PPGTT_PD_ENTRIES 512
- #define I915_PPGTT_PT_ENTRIES (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
- typedef uint64_t gen8_gtt_pte_t;
- typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
- 
- /* PPGTT stuff */
- #define GEN6_GTT_ADDR_ENCODE(addr)((addr) | (((addr) >> 28) & 0xff0))
- #define HSW_GTT_ADDR_ENCODE(addr) ((addr) | (((addr) >> 28) & 0x7f0))
- 
- #define GEN6_PDE_VALID(1 << 0)
- /* gen6+ has bit 11-4 for physical addr bit 39-32 */
- #define GEN6_PDE_ADDR_ENCODE(addr)GEN6_GTT_ADDR_ENCODE(addr)
- 
- #define GEN6_PTE_VALID(1 << 0)
- #define GEN6_PTE_UNCACHED (1 << 1)
- #define HSW_PTE_UNCACHED  (0)
- #define GEN6_PTE_CACHE_LLC(2 << 1)
- #define GEN7_PTE_CACHE_L3_LLC (3 << 1)
- #define GEN6_PTE_ADDR_ENCODE(addr)GEN6_GTT_ADDR_ENCODE(addr)
- #define HSW_PTE_ADDR_ENCODE(addr) HSW_GTT_ADDR_ENCODE(addr)
- 
- /* Cacheability Control is a 4-bit value. The low three bits are stored in *
-  * bits 3:1 of the PTE, while the fourth bit is stored in bit 11 of the PTE.
-  */
- #define HSW_CACHEABILITY_CONTROL(bits)bits) & 0x7) << 1) | \
-(((bits) & 0x8) << (11 - 3)))
- #define HSW_WB_LLC_AGE3   HSW_CACHEABILITY_CONTROL(0x2)
- #define HSW_WB_LLC_AGE0   HSW_CACHEABILITY_CONTROL(0x3)
- #define HSW_WB_ELLC_LLC_AGE0  HSW_CACHEABILITY_CONTROL(0xb)
- #define HSW_WB_ELLC_LLC_AGE3  HSW_CACHEABILITY_CONTROL(0x8)
- #define HSW_WT_ELLC_LLC_AGE0  HSW_CACHEABILITY_CONTROL(0x6)
- #define HSW_WT_ELLC_LLC_AGE3  HSW_CACHEABILITY_CONTROL(0x7)
- 
- #define GEN8_PTES_PER_PAGE(PAGE_SIZE / sizeof(gen8_gtt_pte_t))
- #define GEN8_PDES_PER_PAGE(PAGE_SIZE / sizeof(gen8_ppgtt_pde_t))
- 
- /* GEN8 legacy style addressis defined as a 3 level page table:
-  * 31:30 | 29:21 | 20:12 |  11:0
-  * PDPE  |  PDE  |  PTE  | offset
-  * The difference as compared to normal x86 3 level page table is the PDPEs 
are
-  * programmed via register.
-  */
- #define GEN8_PDPE_SHIFT   30
- #define GEN8_PDPE_MASK0x3
- #define GEN8_PDE_SHIFT21
- #define GEN8_PDE_MASK 0x1ff
- #define GEN8_PTE_SHIFT12
- #define GEN8_PTE_MASK 0x1ff
- 
- #define PPAT_UNCACHED_INDEX   (_PAGE_PWT | _PAGE_PCD)
- #define PPAT_CACHED_PDE_INDEX 0 /* WB LLC */
- #define PPAT_CACHED_INDEX _PAGE_PAT /* WB LLCeLLC */
- #define PPAT_DISPLAY_ELLC_INDEX   _PAGE_PCD /* WT eLLC */

  static void ppgtt_bind_vma(struct i915_vma *vma,
   enum i915_cache_level cache_level,
@@@ -2041,14 -1971,10 +1981,18 @@@ int i915_gem_gtt_init(struct drm_devic
 gtt->base.total >> 20);
DRM_DEBUG_DRIVER("GMADR size = %ldM\n", gtt->mappable_end >> 20);
DRM_DEBUG_DRIVER("GTT stolen size = %zdM\n", gtt->stolen_size >> 20);
 +  /*
 +   * i915.enable_ppgtt is read-only, so do an early pass to validate the
 +   * user's requested state against the hardware/driver capabilities.  We
 +   * do this now so that we can print out any log messages once rather
 +   * than every time we check intel_enable_ppgtt().
 +   */
 +  i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt);
 +  DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt);
+ #ifdef CONFIG_INTEL_IOMMU
+   if (intel_iommu_gfx_mapped)
+   DRM_INFO("VT-d active for gfx access\n");
+ #endif

return 0;
  }
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/510b4a1f/attachment.sig>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Rahul Sharma]

Hi Tomasz,

I have tested your patches for exynos5250 and 5420. Works fine. Are
you planning to post v3? If you want I can share hand with you for v3.

Regards,
Rahul Sharma

On 9 April 2014 17:17, Andreas Oberritter  wrote:
> Hello Andrzej,
>
> On 09.04.2014 10:37, Andrzej Hajda wrote:
>>> +static int exynos_phy_probe(struct platform_device *pdev)
>>> +{
>>> +const struct of_device_id *of_id = of_match_device(
>>> +of_match_ptr(exynos_phy_of_match), >dev);
>>> +const u32 *offsets = of_id->data;
>>> +int count;
>>> +struct device *dev = >dev;
>>> +struct phy **phys;
>>> +struct resource *res;
>>> +void __iomem *regs;
>>> +int i;
>>> +struct phy_provider *phy_provider;
>>> +
>>> +/* count number of phys to create */
>>> +for (count = 0; offsets[count] != ~0; ++count)
>>> +;
>>
>> count = ARRAY_SIZE(offsets) - 1;
>
> u32 *offsets is not an array.
>
> Regards,
> Andreas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/2] drm/bridge: panel and chaining

[Rob Clark]

On Wed, Apr 30, 2014 at 11:13 AM, Ajay kumar  wrote:
>
> On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA 
>  wrote:
>>
>>
>>
>>
>>
>> --- Original Message ---
>>
>> Sender : Sean Paul
>>
>> Date : Apr 30, 2014 02:34 (GMT+05:30)
>>
>> Title : Re: [RFC 0/2] drm/bridge: panel and chaining
>>
>>
>>
>> On Tue, Apr 29, 2014 at 3:57 PM, Rob Clark wrote:
>> > So I thought it would be easier to explain what I had in mind regarding
>> > Ajay's patchset (to add panel support) in patch form.  Originally Thierry
>> > had some concerns with adding panel support in bridges ad-hoc.  So this
>> > idea adds the support of chaining multiple bridges, one of which may be
>> > a panal adapter (maybe I should have called it drm_panel_adapter_bridge).
>> > There are a few rough edges and TODOs, it isn't trying to be complete
>> > yet.
>> >
>> > So the one question is about that hunk I had to move in ptn3460 from
>> > pre_enable() to enable().  If that really needs to come before the
>> > encoder and after the panel, then we should go for a slightly different
>> > approach instead: add a 'struct drm_bridge *next' ptr in 'struct
>> > drm_bridge'.  Then each bridge implementation is responsible to call
>> > the next in the chain (if not null) at the appropriate points.  That
>> > gives a bit more flexibility to bridges to have something both pre and
>> > post the downstream bridge/panel in each of the pre/enable/disable/post
>> > steps.
>>
>> Arbitrarily chaining bridges seems like a more robust solution to me
>> than the composite bridge.
>>
>> For the panel case, I wonder if we could change drm_bridge_init to
>> accept a panel, then we could just chain the panel calls off the
>> various places the bridge hooks are invoked in the drm layer.
>
>
> This idea originated from Rob itself. He wanted to move out drm_panel calls
> from both ptn3460 and ps8622 drivers and he wanted them at a common place.
> But Daniel suggested that having a chain of bridges is good. That is how
> composite_bridge was formed.

so I'm thinking that, given what Sean and others have said, that the
chaining inside bridge implementation would give more flexibility.  By
which I mean:

 struct drm_bridge {
+struct drm_bridge *next;/* the next in the chain */
  
 };

and then in each bridge implementation would do something like this
for each fxn:

 static void foo_bridge_pre_enable(...)
 {
  ... do stuff before ...
+if (bridge->next)
+ bridge->next->pre_enable(...);
 ... do stuff after ...
 }

it would mean now all bridge fxns are now required, even if they only
call next in chain.. we can toss in some helpers for that.

For dealing with panels, and this gets into Inki's proposal, I think
we can just declare that panels themselves implement drm_bridge
interface if needed.  So drm_panel_funcs is for extra API's needed by
connector (like get_modes()) and everything else is part of
drm_bridge_funcs.

BR,
-R

> I still think we are addressing a very simple problem in a complex manner.
> I tried testing this patchset on my board, with some tweaks(explained in 
> PATCH 2/2]),
> and I could get it working. This code basically adds 3 bridge structures to 
> handle the calls,
> but in actual hardware you can map them to only one bridge device.
> I am still not sure what's the problem in just having the panel calls around
> the bridge calls in drm core?
>
>>
>> Feel free to ignore if this has already been explored on the other
>> thread (which I haven't been following).
>>
>> Sean
>>
>>
>>
>> >
>> >
>> > Rob Clark (2):
>> >   drm/bridge: add composite and panel bridges
>> >   drm/bridge/ptn3460: add panel support
>> >
>> >  drivers/gpu/drm/bridge/Makefile  |   2 +
>> >  drivers/gpu/drm/bridge/drm_bridge_util.c | 251 
>> > +++
>> >  drivers/gpu/drm/bridge/drm_bridge_util.h |  29 
>> >  drivers/gpu/drm/bridge/ptn3460.c |  39 -
>> >  include/drm/bridge/ptn3460.h |   6 +-
>> >  5 files changed, 319 insertions(+), 8 deletions(-)
>> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c
>> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
>> >
>> > --
>> > 1.9.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>>
>>
>>
>
>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Tomasz Stanislawski]

Hi Rahul,
I will prepare we v3 version.
Do you want me to add your patches for exynos5?50 to the patchset?
Regards,
Tomasz Stanislawski

On 04/30/2014 08:37 AM, Rahul Sharma wrote:
> Hi Tomasz,
> 
> I have tested your patches for exynos5250 and 5420. Works fine. Are
> you planning to post v3? If you want I can share hand with you for v3.
> 
> Regards,
> Rahul Sharma
> 
> On 9 April 2014 17:17, Andreas Oberritter  wrote:
>> Hello Andrzej,
>>
>> On 09.04.2014 10:37, Andrzej Hajda wrote:
 +static int exynos_phy_probe(struct platform_device *pdev)
 +{
 +const struct of_device_id *of_id = of_match_device(
 +of_match_ptr(exynos_phy_of_match), >dev);
 +const u32 *offsets = of_id->data;
 +int count;
 +struct device *dev = >dev;
 +struct phy **phys;
 +struct resource *res;
 +void __iomem *regs;
 +int i;
 +struct phy_provider *phy_provider;
 +
 +/* count number of phys to create */
 +for (count = 0; offsets[count] != ~0; ++count)
 +;
>>>
>>> count = ARRAY_SIZE(offsets) - 1;
>>
>> u32 *offsets is not an array.
>>
>> Regards,
>> Andreas
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 2/4] drm/plane-helper: Add drm_primary_helper_check_update() (v2)

[Matt Roper]

Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.

A few of the checks here were also updated based on suggestions by
Ville Syrj?l?.

v2:
  - Pass src/dest/clip rects and min/max scaling down to helper to avoid
duplication of effort between helper and drivers (suggested by
Ville).
  - Allow caller to specify whether the primary plane should be
updatable while the crtc is disabled.

Cc: Ville Syrj?l? 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_plane_helper.c | 123 -
 include/drm/drm_plane_helper.h |  24 +++-
 2 files changed, 116 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index b601233..11e8b82 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #define SUBPIXEL_MASK 0x

@@ -66,6 +67,77 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
 }

 /**
+ * drm_primary_helper_check_update() - Check primary plane update for validity
+ * @plane: plane object to update
+ * @crtc: owning CRTC of owning plane
+ * @fb: framebuffer to flip onto plane
+ * @src: source coordinates in 16.16 fixed point
+ * @dest: integer destination coordinates
+ * @clip: integer clipping coordinates
+ * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
+ * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
+ * @can_position: is it legal to position the primary plane such that it
+ *doesn't cover the entire crtc?
+ * @can_update_disabled: can the primary plane be updated while the crtc
+ *   is disabled?
+ * @visible: output parameter indicating whether plane is still visible after
+ *   clipping
+ *
+ * Checks that a desired primary plane update is valid.  Drivers that provide
+ * their own primary plane handling may still wish to call this function to
+ * avoid duplication of error checking code.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_primary_helper_check_update(struct drm_plane *plane,
+   struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_rect *src,
+   struct drm_rect *dest,
+   const struct drm_rect *clip,
+   int min_scale,
+   int max_scale,
+   bool can_position,
+   bool can_update_disabled,
+   bool *visible)
+{
+   int hscale, vscale;
+
+   if (!crtc->enabled && !can_update_disabled) {
+   DRM_DEBUG_KMS("Cannot update primary plane of a disabled 
CRTC.\n");
+   return -EINVAL;
+   }
+
+   /* Check scaling */
+   hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
+   vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
+   if (hscale < 0 || vscale < 0) {
+   DRM_DEBUG_KMS("Invalid scaling of primary plane\n");
+   return -ERANGE;
+   }
+
+   *visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
+   if (!visible)
+   /*
+* Primary plane isn't visible; some drivers can handle this
+* so we just return success here.  Drivers that can't
+* (including those that use the primary plane helper's
+* update function) will return an error from their
+* update_plane handler.
+*/
+   return 0;
+
+   if (!can_position && !drm_rect_equals(dest, clip)) {
+   DRM_DEBUG_KMS("Primary plane must cover entire CRTC\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_primary_helper_check_update);
+
+/**
  * drm_primary_helper_update() - Helper for primary plane update
  * @plane: plane object to update
  * @crtc: owning CRTC of owning plane
@@ -113,51 +185,42 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
.x = src_x >> 16,
.y = src_y >> 16,
};
+   struct drm_rect src = {
+   .x1 = src_x,
+   .y1 = src_y,
+   .x2 = src_x + src_w,
+   .y2 = src_y + src_h,
+   };
struct drm_rect dest = {
.x1 = crtc_x,
.y1 = crtc_y,
.x2 = crtc_x + crtc_w,
.y2 = crtc_y + crtc_h,
};
-   struct drm_rect clip = {
+   const struct drm_rect clip = {

[PATCH 1/4] drm: Check CRTC compatibility in setplane

[Matt Roper]

The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.

Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane helper).

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c | 7 +++
 drivers/gpu/drm/drm_plane_helper.c | 6 --
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 461d19b..b6d6c04 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2140,6 +2140,13 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
crtc = obj_to_crtc(obj);

+   /* Check whether this plane is usable on this CRTC */
+   if (!(plane->possible_crtcs & drm_crtc_mask(crtc))) {
+   DRM_DEBUG_KMS("Invalid crtc for plane\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
if (!fb) {
DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index d966afa..b601233 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -137,12 +137,6 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
return -EINVAL;
}

-   /* Primary planes are locked to their owning CRTC */
-   if (plane->possible_crtcs != drm_crtc_mask(crtc)) {
-   DRM_DEBUG_KMS("Cannot change primary plane CRTC\n");
-   return -EINVAL;
-   }
-
/* Disallow scaling */
src_w >>= 16;
src_h >>= 16;
-- 
1.8.5.1

[RFC v3 PATCH v2 10/16] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

Hi Sachin,

Thank you for comment.

I'll fix.

Thank you.
Best regards YJ

On 04/30/2014 12:26 AM, Sachin Kamat wrote:
> On 27 April 2014 07:20, YoungJun Cho  wrote:
>> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
>> from the one in Exynos4 SoC.
>>
>> In case of Exynos5420 SoC, there is no frequency band bit in 
>> DSIM_PLLCTRL_REG,
>> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
>> So this patch adds driver data to distinguish it.
>>
>> Changelog v2:
>> - Moves exynos_dsi_enable_clocks() after exynos_dsi_reset()
>>(commented by Andrzej Hajda)
>> - Splits D-PHY control setting routines from PLL setting one
>>(commented by Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho 
>> Acked-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |  154 
>> ++-
>>   1 file changed, 132 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 4a918ec..c18dba3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -17,6 +17,7 @@
>>
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>
>> @@ -54,9 +55,12 @@
>>
>>   /* FIFO memory AC characteristic register */
>>   #define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
>> -#define DSIM_PLLTMR_REG0x50/* PLL timer register */
>>   #define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register 
>> */
>>   #define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic 
>> register1 */
>> +#define DSIM_PHYCTRL_REG   0x5c
>> +#define DSIM_PHYTIMING_REG 0x64
>> +#define DSIM_PHYTIMING1_REG0x68
>> +#define DSIM_PHYTIMING2_REG0x6c
>>
>>   /* DSIM_STATUS */
>>   #define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
>> @@ -200,6 +204,21 @@
>>   #define DSIM_PLL_M(x)  ((x) << 4)
>>   #define DSIM_PLL_S(x)  ((x) << 1)
>>
>> +/* DSIM_PHYTIMING */
>> +#define DSIM_PHYTIMING_LPX(x)  ((x) << 8)
>> +#define DSIM_PHYTIMING_HS_EXIT(x)  ((x) << 0)
>> +
>> +/* DSIM_PHYTIMING1 */
>> +#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) << 24)
>> +#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) << 16)
>> +#define DSIM_PHYTIMING1_CLK_POST(x)((x) << 8)
>> +#define DSIM_PHYTIMING1_CLK_TRAIL(x)   ((x) << 0)
>> +
>> +/* DSIM_PHYTIMING2 */
>> +#define DSIM_PHYTIMING2_HS_PREPARE(x)  ((x) << 16)
>> +#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) << 8)
>> +#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) << 0)
>> +
>>   #define DSI_MAX_BUS_WIDTH  4
>>   #define DSI_NUM_VIRTUAL_CHANNELS   4
>>   #define DSI_TX_FIFO_SIZE   2048
>> @@ -233,6 +252,12 @@ struct exynos_dsi_transfer {
>>   #define DSIM_STATE_INITIALIZED BIT(1)
>>   #define DSIM_STATE_CMD_LPM BIT(2)
>>
>> +struct exynos_dsi_driver_data {
>
> Shouldn't this be static?
>
>> +   unsigned int plltmr_reg;
>> +
>
> nit: stray blank line
>
>> +   unsigned int has_freqband:1;
>> +};
>> +
>
> 
>
>> +static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>> +{
>> +   struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
>> +   u32 reg;
>> +
>> +   if (driver_data->has_freqband)
>> +   return;
>> +
>> +   /* B D-PHY */
>> +   reg = 0x0af & 0x1ff;
>
> Please use macros instead of magic numbers.
>

[RFC v3 PATCH 08/16] drm/exynos: fimd: support I80 interface

[YoungJun Cho]

Hi Sachin,

Thank you for comment.

I'll fix.

Thank you.
Best regards YJ

On 04/30/2014 12:35 AM, Sachin Kamat wrote:
> Hi YoungJun,
>
> On 27 April 2014 07:20, YoungJun Cho  wrote:
>> To support MIPI DSI command mode interface, FIMD should do followings:
>> - Sets LCD block configuration for I80 interface.
>> - Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
>> - Implements trigger feature which transfers image date if there is
>>page flip request, and implements TE handler to call trigger function.
>> - Sets CPU mode timings configuration.
>> - Sets ideal(pixel) clock is 2 times faster than the original one to
>>generate frame done IRQ prior to the next TE signal.
>
> <...>
>> +
>> +   reg = readl(timing_base + TRIGCON);
>> +   reg |= 1 << 0 | 1 << 1;
>
> What does this signify? Can't this be OR'd directly with 3?
>

[PATCH] drm/radeon/dp: check for errors in dpcd reads

[Alex Deucher]

Check to make sure the transaction succeeded before
using the register value.  Fixes occasional link training
problems.

Noticed-by: Sergei Antonov 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 44 
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index bc0119f..54e4f52 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -366,11 +366,11 @@ static void radeon_dp_probe_oui(struct radeon_connector 
*radeon_connector)
if (!(dig_connector->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
return;

-   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
3))
+   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI, buf, 
3) == 3)
DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
  buf[0], buf[1], buf[2]);

-   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
buf, 3))
+   if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_BRANCH_OUI, 
buf, 3) == 3)
DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
  buf[0], buf[1], buf[2]);
 }
@@ -419,21 +419,23 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,

if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
-   drm_dp_dpcd_readb(_connector->ddc_bus->aux,
- DP_EDP_CONFIGURATION_CAP, );
-   if (tmp & 1)
-   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
-   else if ((dp_bridge == ENCODER_OBJECT_ID_NUTMEG) ||
-(dp_bridge == ENCODER_OBJECT_ID_TRAVIS))
-   panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
-   else
-   panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
+   if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
+ DP_EDP_CONFIGURATION_CAP, ) == 1) {
+   if (tmp & 1)
+   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+   else if ((dp_bridge == ENCODER_OBJECT_ID_NUTMEG) ||
+(dp_bridge == ENCODER_OBJECT_ID_TRAVIS))
+   panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
+   else
+   panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
+   }
} else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
/* eDP */
-   drm_dp_dpcd_readb(_connector->ddc_bus->aux,
- DP_EDP_CONFIGURATION_CAP, );
-   if (tmp & 1)
-   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+   if (drm_dp_dpcd_readb(_connector->ddc_bus->aux,
+ DP_EDP_CONFIGURATION_CAP, ) == 1) {
+   if (tmp & 1)
+   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+   }
}

return panel_mode;
@@ -809,11 +811,15 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
else
dp_info.enc_id |= ATOM_DP_CONFIG_LINK_A;

-   drm_dp_dpcd_readb(_connector->ddc_bus->aux, DP_MAX_LANE_COUNT, 
);
-   if (ASIC_IS_DCE5(rdev) && (tmp & DP_TPS3_SUPPORTED))
-   dp_info.tp3_supported = true;
-   else
+   if (drm_dp_dpcd_readb(_connector->ddc_bus->aux, 
DP_MAX_LANE_COUNT, )
+   == 1) {
+   if (ASIC_IS_DCE5(rdev) && (tmp & DP_TPS3_SUPPORTED))
+   dp_info.tp3_supported = true;
+   else
+   dp_info.tp3_supported = false;
+   } else {
dp_info.tp3_supported = false;
+   }

memcpy(dp_info.dpcd, dig_connector->dpcd, DP_RECEIVER_CAP_SIZE);
dp_info.rdev = rdev;
-- 
1.8.3.1

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Greg Kroah-Hartman]

On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
> Generic framework for tracking internal interfaces
> ==
> 
> Summary
> ---
> 
> interface_tracker is a generic framework which allows to track appearance
> and disappearance of different interfaces provided by kernel/driver code 
> inside
> the kernel. Examples of such interfaces: clocks, phys, regulators, 
> drm_panel...
> Interface is specified by a pair of object pointer and interface type. Object
> type depends on interface type, for example interface type drm_panel 
> determines
> that object is a device_node. Object pointer is used to distinguish different
> interfaces of the same type and should identify object the interface is bound 
> to.
> For example it could be DT node, struct device,...
> 
> The framework provides two functions for interface providers which should be
> called just after interface becomes available or just before interface
> removal. Interface consumers can register callback which will be called
> when requested interface changes its state, if during callback registration
> the interface is already up, notification will be sent also.
> 
> The framework allows nesting calls, for example it is possible to signal one
> interface in tracker callback of another interface. It is done by putting
> every request into the queue. If the queue is empty before adding
> the request, the queue will be processed after, if there is already another
> request in the queue it means the queue is already processed by different
> thread so no additional action is required. With this pattern only spinlock
> is necessary to protect the queue. However in case of removal of either
> callback or interface caller should be sure that his request has been
> processed so framework waits until the queue becomes empty, it is done using
> completion mechanism.
> 
> The framework functions should not be called in atomic context. Callbacks
> should be aware that they can be called in any time between registration and
> de-registration, so they should use synchronization mechanisms carefully.
> Callbacks should also avoid to perform time consuming tasks, the framework
> serializes them, so it could stall other callbacks.
> 
> Use cases
> -
> 
> The interface is very generic, there are many situations it can be useful:
> 
> 1. Replacement for subsystem specific methods of publishing/unpublishing
> interfaces. Currently many frameworks allows only querying for presence of 
> given
> interface. In such cases client can defer probing or implement interface
> polling, which is usually subobtimal. Additionally subsystems often do not
> provide methods to signal to the consumers that they are about to be 
> destroyed.
> 
> 2. Monitoring for different interfaces provided by the same object. An example
> should explain it better. Lets assume in device tree drm crtc device node have
> video link to another node, so it knows only that there is something connected
> to its RGB output. It can be a RGB panel (drm_panel framework), it can be an
> image enhancer (SoC specific framework) or it can be some signal converter
> (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to
> another node. Currently it is difficult to handle such situations in a generic
> way. interface_tracker should make it simple: crtc should monitor all 
> supported
> interface types that appears at the device_node pointed by the phandle.
> 
> Potential use cases
> ---
> 
> Points mentioned above were the reasons for writing this framework. During
> development I have realized that this framework can be also useful for other
> tasks.
> 
> 3. Replacement for deferred probing - if for some reason driver do not wants 
> to
> defer but it requires given resources it can use interface_tracker. It should 
> be
> possible to create an helper which will wait for appearance of all interfaces
> from a given list, and 'continue' probe only when all resources becomes
> available.
> 
> 4. Replacement or helper for subsystem specific solutions:
> - V4L2 subdev async registration,
> - component framework.
> Both frameworks solves a problem of tracking sub-components (un-)registration
> by master device, it should be possible to do the same with interface_tracker
> framework. Some additional helpers can be convienent to make the 
> implementation
> easier.
> 
> 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are
> providers of different resources/interfaces: regulators, clocks, phys,
> V4L2 subdevs, ... They are usually protected from module unloading by getting
> module reference, but there is no protection from driver unbinding using sysfs
> method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer
> stays with the pointer to non-existing object, next time it tries to use it
> system usually crashes. interface_tracker do not add any protection, but it 
> adds
> a 

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

smattering of fixes, i915, exynos, tegra, msm, vmwgfx,

bit of framebuffer reference counting fallout fixes, i915 GM45 regression
fix, DVI regression fix, vmware info leak between processes fix.

Inki, I've cherry-picked and signed off some of the stuff from the exynos
fixes pull request, since I know Linus is already unhappy with me, please
put the rest of those in -next.

Dave.

The following changes since commit abaafc0af9f74f8e6212a3bf54fb907358b40ad7:

  Merge branch 'drm-fixes-3.15' of 
git://people.freedesktop.org/~deathsimple/linux into drm-next (2014-04-23 
07:39:12 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to b8eade24c9891b8f153c40cf310ef4696c873af9:

  drm/exynos: use %pad for dma_addr_t (2014-04-30 09:48:54 +1000)


Andrzej Hajda (1):
  drm/exynos: balance framebuffer refcount

Ben Widawsky (1):
  drm/i915: Allow full PPGTT with param override

Chris Wilson (2):
  drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
  drm/i915: Move all ring resets before setting the HWS page

Daniel Vetter (3):
  drm/i915: Don't check gmch state on inherited configs
  drm/tegra: restrict plane loops to legacy planes
  drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch 
platforms

Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2014-04-25' of 
git://anongit.freedesktop.org/drm-intel into drm-next
  Merge branch 'msm-fixes-3.15-rc3' of 
git://people.freedesktop.org/~robclark/linux into drm-next
  Merge tag 'drm/tegra/for-3.15-rc3' of 
git://anongit.freedesktop.org/tegra/linux into drm-next
  Merge branch 'vmwgfx-fixes-3.15' of 
git://people.freedesktop.org/~thomash/linux into drm-next

Jingoo Han (3):
  MAINTAINERS: update maintainer entry for Exynos DP driver
  drm/exynos: dsi: use IS_ERR() to check devm_ioremap_resource() results
  drm/exynos: use %pad for dma_addr_t

Micah Richert (1):
  drm/msm: fix memory leak

Paulo Zanoni (1):
  drm/i915: get power domain in case the BIOS enabled eDP VDD

Rob Clark (2):
  drm/msm: default to XR24 rather than AR24
  drm/msm/mdp4: cure for the cursor blues (v2)

Thomas Hellstrom (1):
  drm/vmwgfx: Make sure user-space can't DMA across buffer object 
boundaries v2

Ville Syrj?l? (1):
  drm/i915: Allow user modes to exceed DVI 165MHz limit

 MAINTAINERS|  6 
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  4 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
 drivers/gpu/drm/i915/i915_irq.c| 18 +++---
 drivers/gpu/drm/i915/i915_reg.h|  1 +
 drivers/gpu/drm/i915/intel_display.c   | 23 ++---
 drivers/gpu/drm/i915/intel_dp.c| 11 +-
 drivers/gpu/drm/i915/intel_drv.h   |  3 +-
 drivers/gpu/drm/i915/intel_fbdev.c | 10 ++
 drivers/gpu/drm/i915/intel_hdmi.c  |  9 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 54 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |  9 ++---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c|  4 +--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 21 
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h|  4 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c|  4 +--
 drivers/gpu/drm/msm/msm_fbdev.c|  5 +--
 drivers/gpu/drm/msm/msm_gem.c  |  4 ++-
 drivers/gpu/drm/tegra/dc.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 22 
 24 files changed, 166 insertions(+), 56 deletions(-)

[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Christoph Haag  ---
Created attachment 98201
  --> https://bugs.freedesktop.org/attachment.cgi?id=98201=edit
dmesg with GPU lockup

Yea, this is maybe going off topic, but I'm a bit tired, so here's the dmesg
with gpu lockup. 

It always happens when going to Sanctum2's advanced graphics setting, right
when enabling "Lichstrahlen" or light rays or whatever it's called in english.

The rest of the game seems to be fine as far as I have seen walking around for
a pretty short time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 73511] clinfo mises Max clock frequency on r600

[bugzilla-dae...@freedesktop.org]

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #9 from Tom Stellard  ---
I've committed these patches.  This will require a 3.14 or newer kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: