[PATCH] [libdrm] intel: Add decode for Gen7 3DSTATE_DEPTH_BUFFER
Signed-off-by: Chris Forbes
---
intel/intel_decode.c | 57 +++
intel/tests/gen7-3d.batch-ref.txt | 12 -
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index adda29a..0c3c943 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -2637,6 +2637,20 @@ static const char *get_965_depthformat(unsigned int
depthformat)
}
}
+static const char *get_gen7_depthformat(unsigned int depthformat)
+{
+ switch (depthformat) {
+ case 1:
+ return "z32float";
+ case 3:
+ return "z24x8";
+ case 5:
+ return "z16";
+ default:
+ return "unknown";
+ }
+}
+
static const char *get_965_element_component(uint32_t data, int component)
{
uint32_t component_control = (data >> (16 + (3 - component) * 4)) & 0x7;
@@ -3363,17 +3377,38 @@ decode_3d_965(struct drm_intel_decode *ctx)
instr_out(ctx, 3, "WM sampler state\n");
return len;
case 0x7805:
- /* Actually 3DSTATE_DEPTH_BUFFER on gen7. */
- if (ctx->gen == 7)
- break;
-
- instr_out(ctx, 0, "3DSTATE_URB\n");
- instr_out(ctx, 1,
- "VS entries %d, alloc size %d (1024bit row)\n",
- data[1] & 0x, ((data[1] >> 16) & 0x07f) + 1);
- instr_out(ctx, 2,
- "GS entries %d, alloc size %d (1024bit row)\n",
- (data[2] >> 8) & 0x3ff, (data[2] & 7) + 1);
+ if (ctx->gen >= 7) {
+ /* 3DSTATE_DEPTH_BUFFER on gen7. */
+ instr_out(ctx, 0, "3DSTATE_DEPTH_BUFFER\n");
+ instr_out(ctx, 1, "%s %s pitch = %d ZWr%s SWr%s
Hiz%s\n",
+ get_965_surfacetype(data[1] >> 29),
+ get_gen7_depthformat((data[1] >> 18) & 0x7),
+ (data[1] & 0x1) + 1,
+ data[1] & (1<<28) ? "On" : "Off",
+ data[1] & (1<<27) ? "On" : "Off",
+ data[1] & (1<<22) ? "On" : "Off"
+ );
+ instr_out(ctx, 2, "surface base address\n");
+ instr_out(ctx, 3, "width = %d height = %d lod = %d\n",
+ ((data[3] >> 4) & 0x3fff) + 1,
+ (data[3] >> 18) + 1,
+ data[3] & 0xf);
+ instr_out(ctx, 4, "depth = %d minlayer = %d\n",
+ (data[4] >> 21) + 1,
+ (data[4] >> 10) & 0x7ff);
+ instr_out(ctx, 5, "offsets\n");
+ instr_out(ctx, 6, "view extent = %d\n",
+ (data[6] >> 21));
+ } else {
+ /* 3DSTATE_URB on <= gen6. */
+ instr_out(ctx, 0, "3DSTATE_URB\n");
+ instr_out(ctx, 1,
+ "VS entries %d, alloc size %d (1024bit
row)\n",
+ data[1] & 0x, ((data[1] >> 16) & 0x07f) +
1);
+ instr_out(ctx, 2,
+ "GS entries %d, alloc size %d (1024bit
row)\n",
+ (data[2] >> 8) & 0x3ff, (data[2] & 7) + 1);
+ }
return len;
case 0x7808:
diff --git a/intel/tests/gen7-3d.batch-ref.txt
b/intel/tests/gen7-3d.batch-ref.txt
index cd2dfc4..db70625 100644
--- a/intel/tests/gen7-3d.batch-ref.txt
+++ b/intel/tests/gen7-3d.batch-ref.txt
@@ -173,12 +173,12 @@
0x123002b0: 0x:
0x123002b4: 0x:
0x123002b8: 0x78050005: 3DSTATE_DEPTH_BUFFER
-0x123002bc: 0xe004:dword 1
-0x123002c0: 0x:dword 2
-0x123002c4: 0x:dword 3
-0x123002c8: 0x:dword 4
-0x123002cc: 0x:dword 5
-0x123002d0: 0x:dword 6
+0x123002bc: 0xe004:NULL z32float pitch = 1 ZWrOff SWrOff HizOff
+0x123002c0: 0x:surface base address
+0x123002c4: 0x:width = 1 height = 1 lod = 0
+0x123002c8: 0x:depth = 1 minlayer = 0
+0x123002cc: 0x:offsets
+0x123002d0: 0x:view extent = 0
0x123002d4: 0x78070001: 3DSTATE_HIER_DEPTH_BUFFER
0x123002d8: 0x:pitch 1b
0x123002dc: 0x:pointer to HiZ buffer
--
2.1.3
[PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
Hi ZubairLK: On 2014å¹´11æ24æ¥ 22:22, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > On 24/11/14 14:17, Andy Yan wrote: >> Hi ZubairLK, Russel King, Greg Kroah-Hartman , Philipp Zabel and Daniel: >> Do you have any further opinions or suggestions about the >> the current patch set? > I have reviewed the patches as much as I could. > > They look good to me. > > But I don't know the inner details of DRM to be able to comment further. > > Please do cc me in further patches. Thanks very much for your carefully review work. And if you have further ideas , please let me know. > > Also, my mail client makes these patches look like the new series gets > cascaded in the older patch 8 series. > > It could be just my thunderbird. But please start a new thread when you send > a new series. I do these by taking Russell King's advice in PATCH#10(use the same reference message id). > > Thank-you > ZubairLK > >> On 2014å¹´11æ17æ¥ 18:53, Andy Yan wrote: >>> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) >>> use the interface compatible Designware HDMI IP, but they also have some >>> lightly differences, such as phy pll configuration, register width(imx hdmi >>> register is one byte, but rk3288 is 4 bytes width and can only be accessed >>> by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0 >>> support. > ___ > Linux-rockchip mailing list > Linux-rockchip at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
Hi ZubairLK, Russel King, Greg Kroah-Hartman , Philipp Zabel and Daniel:
Do you have any further opinions or suggestions about the
the current patch set?
On 2014å¹´11æ17æ¥ 18:53, Andy Yan wrote:
> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly differences, such as phy pll configuration, register width(imx hdmi
> register is one byte, but rk3288 is 4 bytes width and can only be accessed
> by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0
> support.
>
> To reuse the imx-hdmi driver, we make this patch set:
> (1): fix some CodingStyle warning to make checkpatch happy
> (2): convert imx-hdmi to drm_bridge
> (3): move imx-hdmi to bridge/dw_hdmi, and split platform specific code
> (4): extend dw_hdmi.c to support rk3288 hdmi
> (5): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c
>
> Changes in v12:
> - refactor of_node_put(ddc_node)
> - squash patch & from imx-hdmi>
> - add comment for the depend on patch
>
> Changes in v11:
> - squash patch
> - split form patch
> - split from patch
>
> Changes in v10:
> - split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)
> - add more display mode support mpll configuration for rk3288
>
> Changes in v9:
> - move some phy configuration to platform driver
>
> Changes in v8:
> - correct some spelling mistake
> - modify ddc-i2c-bus and interrupt description
> - Add documentation for rockchip dw hdmi
>
> Changes in v7:
> - remove unused variables from structure dw_hdmi
> - remove a wrong modification
> - add copyrights for dw_hdmi-imx.c
>
> Changes in v6:
> - rearrange the patch order
> - move some modification to patch#6
> - refactor register access without reg_shift
>
> Changes in v5:
> - refactor reg-io-width
>
> Changes in v4:
> - fix checkpatch CHECK
> - defer probe ddc i2c adapter
>
> Changes in v3:
> - split multi-register access to one indepent patch
>
> Changes in v2:
> - use git format -M to generate these patch
>
> Andy Yan (11):
>staging: imx-drm: imx-hdmi: make checkpatch happy
>staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter
>staging: imx-drm: imx-hdmi: convert imx-hdmi to drm_bridge mode
>staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
>dt-bindings: add document for dw_hdmi
>drm: bridge/dw_hdmi: add support for multi-byte register width access
>drm: bridge/dw_hdmi: add mode_valid support
>drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
>drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
>dt-bindings: Add documentation for rockchip dw hdmi
>drm: bridge/dw_hdmi: add rockchip rk3288 support
>
> .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 40 ++
> .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++
> drivers/gpu/drm/bridge/Kconfig | 5 +
> drivers/gpu/drm/bridge/Makefile| 1 +
> .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 767
> +
> .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}| 7 +-
> drivers/gpu/drm/rockchip/Kconfig | 10 +
> drivers/gpu/drm/rockchip/Makefile | 2 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 355 ++
> drivers/staging/imx-drm/Kconfig| 1 +
> drivers/staging/imx-drm/Makefile | 2 +-
> drivers/staging/imx-drm/dw_hdmi-imx.c | 274
> include/drm/bridge/dw_hdmi.h | 60 ++
> 13 files changed, 1139 insertions(+), 428 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> create mode 100644
> Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
> rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}
> (70%)
> rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}
> (99%)
> create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
> create mode 100644 include/drm/bridge/dw_hdmi.h
>
[PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.
Meanwhile do what pretty much all the drivers have done for the plane
update functions: Simply skip the vblank wait for the buffer cleanup
if the buffer is the same. Since the universal cursor plane code will
not recreate framebuffers needlessly this allows us to not slow down
legacy pageflip events while someone moves the cursor around.
v2: Drop the async plane update hunk from a previous attempt at this
issue.
v3: Fix up kerneldoc.
v4: Don't oops so badly. Reported by Jasper.
Cc: Rob Clark
Cc: "Jasper St. Pierre"
Reviewed-by: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index af37f1edd3ed..0d32039d072f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -748,6 +748,33 @@ static void wait_for_fences(struct drm_device *dev,
}
}
+static bool framebuffer_changed(struct drm_device *dev,
+ struct drm_atomic_state *old_state,
+ struct drm_crtc *crtc)
+{
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state;
+ int nplanes = old_state->dev->mode_config.num_total_plane;
+ int i;
+
+ for (i = 0; i < nplanes; i++) {
+ plane = old_state->planes[i];
+ old_plane_state = old_state->plane_states[i];
+
+ if (!plane)
+ continue;
+
+ if (plane->state->crtc != crtc &&
+ old_plane_state->crtc != crtc)
+ continue;
+
+ if (plane->state->fb != old_plane_state->fb)
+ return true;
+ }
+
+ return false;
+}
+
/**
* drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
* @dev: DRM device
@@ -755,7 +782,9 @@ static void wait_for_fences(struct drm_device *dev,
*
* Helper to, after atomic commit, wait for vblanks on all effected
* crtcs (ie. before cleaning up old framebuffers using
- * drm_atomic_helper_cleanup_planes())
+ * drm_atomic_helper_cleanup_planes()). It will only wait on crtcs where the
+ * framebuffers have actually changed to optimize for the legacy cursor and
+ * plane update use-case.
*/
void
drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
@@ -781,6 +810,9 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
if (!crtc->state->enable)
continue;
+ if (!framebuffer_changed(dev, old_state, crtc))
+ continue;
+
ret = drm_crtc_vblank_get(crtc);
if (ret != 0)
continue;
--
2.1.1
[GIT PULL FOR v3.19] R-Car DU changes
On 11/24/2014 09:01 PM, Dave Airlie wrote: > On 25 November 2014 at 00:18, Lars-Peter Clausen wrote: >> On 11/24/2014 03:00 PM, Laurent Pinchart wrote: >>> >>> Hi Daniel, >>> >>> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: >>> Decouple EDID parsing from I2C adapter" patch available at >>> git://linuxtv.org/pinchartl/fbdev.git drm/next/du) >>> >>> On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: >> >> - the interface looks rather backwards: Either this still does i2c >> reads, and then you'd just need a i2c-over-whatever adapter to make >> it >> work. Or you have other magic means to optain an edid block, in >> which >> case just do that and then feed the edid drm_add_edid_modes. > > > I have a magic way to get EDID over I2C :-) Basically the ADV7511 > controls > the DDC bus, and exposes EDID data over I2C using vendor commands. To > read an EDID block I have to write an ADV7511 register over I2C with the > block number, wait for an interrupt, read a status register to check > whether EDID data is available or whether an error occurred, and then > read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs > to be repeated for every block. I thus can't use drm_get_edid() > directly. Sounds familiar. See the special ddc-over-sdvo i2c bus we register in intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit of boilerplate, but in the end just amounts to 3 small functions and one tiny vtable to wire it all up cleanly. >>> >>> >>> That's what I would have done as well if I had a device-specific I2C >>> adapter >>> connected to the DDC bus, but in this case the interface exposed by the >>> ADV7511 to the SoC over I2C consists of higher level device-specific I2C >>> commands to read EDID data. There is no low-level I2C read/write >>> primitives >>> available. I would thus need to expose a fake adapter that would receive >>> I2C >>> commands, parse them to detect an EDID block read, retrieve the EDID data >>> and >>> return them from the fake read. That doesn't make much sense to me. >> >> >> The intel sdvo looks just like a simple I2C mux which will just pass-through >> messages from the master to the EDID EEPROM. The ADV7511 is unfortunately a >> bit different. You tell it to fetch the EDID information, then it will do >> some magic and then you can read the EDID back. Abstracting this as a this >> as a I2C controller will, while possible, result in a fair amount of boiler >> plate code that will not look particularly pretty. > > It sounds also a bit like DP auxch also, or even how on UDL we get the edid > over USB. > > I'd rather see not pretty code that only one person had to look at though :-) > with lots of comments on the hw design that demands ugly. I'd rather not see that if I'm the person who has to look at it ;) But looking around it appears as if this is a more common thing among external HDMI encoders though. E.g. the tda998x has the exact same issue and the current driver just copy&pastes drm_do_get_edid() and plugs in its own EDID block retrieval method. On the other hand the patch that makes it possible to use a different backend then a raw I2C adapter to fetch the EDID is extremely trivial and doesn't make the existing code more complex in any way.
[PATCH] drm/atomic: Drop per-plane locking TODO
I've forgotten to remove that in my per-plane locking patch. Reported-by: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d3b46746b611..ba49b5ca822f 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -243,12 +243,6 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state, if (state->plane_states[index]) return state->plane_states[index]; - /* -* TODO: We currently don't have per-plane mutexes. So instead of trying -* crazy tricks with deferring plane->crtc and hoping for the best just -* grab all crtc locks. Once we have per-plane locks we must update this -* to only take the plane mutex. -*/ ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx); if (ret) return ERR_PTR(ret); -- 2.1.1
[PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.
Meanwhile do what pretty much all the drivers have done for the plane
update functions: Simply skip the vblank wait for the buffer cleanup
if the buffer is the same. Since the universal cursor plane code will
not recreate framebuffers needlessly this allows us to not slow down
legacy pageflip events while someone moves the cursor around.
v2: Drop the async plane update hunk from a previous attempt at this
issue.
v3: Fix up kerneldoc.
Cc: Rob Clark
Cc: "Jasper St. Pierre"
Reviewed-by: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fad2b932cf72..ac4795f720cb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -754,6 +754,30 @@ static void wait_for_fences(struct drm_device *dev,
}
}
+static bool framebuffer_changed(struct drm_device *dev,
+ struct drm_atomic_state *old_state,
+ struct drm_crtc *crtc)
+{
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state;
+ int nplanes = old_state->dev->mode_config.num_total_plane;
+ int i;
+
+ for (i = 0; i < nplanes; i++) {
+ plane = old_state->planes[i];
+ old_plane_state = old_state->plane_states[i];
+
+ if (plane->state->crtc != crtc &&
+ old_plane_state->crtc != crtc)
+ continue;
+
+ if (plane->state->fb != old_plane_state->fb)
+ return true;
+ }
+
+ return false;
+}
+
/**
* drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
* @dev: DRM device
@@ -761,7 +785,9 @@ static void wait_for_fences(struct drm_device *dev,
*
* Helper to, after atomic commit, wait for vblanks on all effected
* crtcs (ie. before cleaning up old framebuffers using
- * drm_atomic_helper_cleanup_planes())
+ * drm_atomic_helper_cleanup_planes()). It will only wait on crtcs where the
+ * framebuffers have actually changed to optimize for the legacy cursor and
+ * plane update use-case.
*/
void
drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
@@ -787,6 +813,9 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
if (!crtc->state->enable)
continue;
+ if (!framebuffer_changed(dev, old_state, crtc))
+ continue;
+
ret = drm_crtc_vblank_get(crtc);
if (ret != 0)
continue;
--
2.1.1
[PATCH] drm: Document that drm_dev_alloc doesn't need a parent
Possible for purely virtual debug devices. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 2e5c7d941313..4f41377b0b80 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -535,6 +535,8 @@ static void drm_fs_inode_free(struct inode *inode) * The initial ref-count of the object is 1. Use drm_dev_ref() and * drm_dev_unref() to take and drop further ref-counts. * + * Note that for purely virtual devices @parent can be NULL. + * * RETURNS: * Pointer to new DRM device, or NULL if out of memory. */ -- 2.1.1
[Bug 86669] SSH Account request
https://bugs.freedesktop.org/show_bug.cgi?id=86669 Bug ID: 86669 Summary: SSH Account request Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel at lists.freedesktop.org Reporter: seanpaul at chromium.org realname: Sean Paul email: seanpaul at chromium.org acctname: seanpaul rsa: ssh-rsa B3NzaC1yc2EDAQABAAABAQDPkbopYTyjCHuBOjkjec0ERFcIAH7KjVbOUFdB4+6bXvpWnUR9FxupvL36XWI2jF9T9suBZipoD22cvpsXK2PGPmzNGeICgRnyzGrnq5ZlV3mYq8WyapAXypohbIVfnP8Dz43Qtjf6y1v5xsd4K0fIjoRdjQ+vCAO0ZFYpo1xMI14nrUQtx4WIPXd12p95Rv8cML7vGqA+E31M6ZSguTvvjR6On/2O0ynrSkELofLhgj9ZnSKfjaBz2pbC2GzED/V82+Rjsr/k1ox1ZtzFAeIDBSt3ZwRu32gwelFVftxw0botiAzv+od4/Jq/9SKMzraSt+Fm/eWRFjkWjaAHE4DB seanpaul at chromium.org gpg: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFRzXGYBCADnkUuZDKswJpSznqtB+CM3N6G3j0937g4kNAfWzfVHWjliQH9D muIVUBsiCc/gd1RRZbu8ohidBa4qbcPBPBgqc5Lv4Lqw1lbu+Dfu2g7IlcQB7s+S kWepSWnL7rLS2aRzRbJQyXGViA5Gavnp35Amirb8VuI/EChArODO2jWijQUHeWYJ 3fRnMyJKm5NkPmOZnirclLib3shpgUxJUS5u97D7AH9Wt9KK7+9GqA/c7tY5+KGm vZEWM9T75AmwRuaEU1cBiWmDAyGLZ7Cg2RjeGHkyt1E/RLutRq18PEFmVaLCfeOG 4I71j7M9XZW7qIaPOI0XB/U5EmdLCGTWnNjHABEBAAG0IVNlYW4gUGF1bCA8c2Vh bnBhdWxAY2hyb21pdW0ub3JnPokBOAQTAQIAIgUCVHNcZgIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQGcCPkB86pMdeugf/R+Hh9UJNp4TKYi0DePLDwedC vk/FBY8AjAWBuiV0Rhaumr5DwEW4Zgv4qjrIqub4dlI0Ty4+g8Y2Cox6Kzgpz2vg 6KwVkgGg2nO3cnw2AtS9rYq/Dd72kfT41Wq7MA0GqA6CnrXKZKz3t+bhKHwCQTRJ 2SIfMPysFsfDHVC4oxoKcM5g0D5+ktqGpzxHa5SHsDkmccNlHJ4lTrfd7qXq9X9A aBgvpMMkqIm2hkAqeAhPliyU/cmYCGLEgFRq5MnXrDryEwRmFt1YO1AGOx4XO5wr nQz5YxKgxCLM8irn9HwYRArFs4gZyHExPbJTdYD8aH3erFSvWlnVL1TCVQS3oLkB DQRUc1xmAQgAsQYCU6QBuUJLZK1MSinxT4wg4Ye1DHAal5P3tDqqUc6R7spKghsN /HIbM5jiyr+Y4CE2xp2nZOt7W8L1dKbYVCtd3ywD/S+9iY7Rz3aN/S0UC5x3oK26 F8rpexI7cY0Zuqt0v8fmCSTK3gCMEU5L1CB+guwmV0scb3VIso/i2ik99e2IDR8+ ibUyo8fGGuHrQiuAu5wzsbzceSoXDdlNECKHD6I47cKgv/+/TOt7m41w3Lx3cE5k +YKlJ+me80L96v3kW3zUAAf1xepcUODlDoMkMv3gaUs33WLYf6ky5qmJvOgAvoVK uBpnALQpjW/QQaUHk9lNsvgv6hRNoTewiwARAQABiQEfBBgBAgAJBQJUc1xmAhsM AAoJEBnAj5AfOqTHTmcH+gPLQosqYw55ViV/KaUtgHKrlOyE+KpV6FcBqCBzrWZY 4cyg66pPbR0HcV8CmzqCpi+hC0tGIT2/JO0YN8bbIbRre8PNvkXxHFs3KIyr5ihh 43mzuMSRKEsEKZIt0/nAMI19ljqNArBWKpXlMwU6s5+C2b2c+fYMM5d3TxjgtPdt YkWA9BTnrGWcLNw4fPnXFGRWQz0fKjR7Wq3HZpny8pe2eX/jDBIAyn5lFmRr61dD NCyW4DIV5gfvkiZ7l1sRuqKcOCWs0Lj/VWyyzm24pn9zjavKCxBrC1O+mpknziBc Yd6azQezzPw/45syfBD4Iy2KDtfRB/YOyESrBQFjGIY= =mKjp -END PGP PUBLIC KEY BLOCK- -- 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/20141124/fac0f267/attachment.html>
[Bug 72785] bfgminer --scrypt on 7xxx+
https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #38 from Linux User --- > Do you have an X server running? I am (on one of GPUs). And I can understand X could be slow, etc and adjusting intensity on GPU sharing X server is well known thing to me. But I'm talking about GPU lockups. When GPU crashes due to ring stall and driver have to restart it, its likely something else failing? Somehow, attempts to run bfgminer --scrypt with high intensity often can provoke ring stalls. > drm.rnodes=1 to your kernel command line. Cool, but... 1) It could be nice to view output on separate monitor and graphic terminal looks better than just framebuffer console. At least in trial runs I would prefer to deal with my favorite terminal, adjusting intensity of 1st GPU a bit. 2) I do not think apps should be cause fatal GPU deadlocks, effectively screwing all graphics, system-wide. Though thanks for render nodes hint - sounds like it can be really valuable thing to try on some headless machines, etc. P.S. also there is another silly issue. If I just install Ubuntu and run bfgminer on multi-GPU setup within X session, it would only see 1st GPU (where X server running). Remaining GPUs are not detected. Fix is to either run bfgminer as root (extremely unsafe!!!) or create new user and make "video" it's primary group. The user who installs Ubuntu is a member of "video" group, but "video" is his secondary group, which is very common. Somehow, kernel seems to disregard permissions in such case and would issue -EPERM on certain syscall, making bfgminer unable to find GPUs except one used by X. Generally it means that user can't use more than 1 GPU unless he is either root (very dangerous!) or video is his primary group (inconvenient and uncommon). I believe it is a bug and I should file it? Since I fail to understand how average Joe would be able to use some OpenCL program in multi-GPU setup and get it working "by default" on all available GPUs. I guess I should file it as new bug? Is it kernel issue or MESA, etc? -- 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/20141124/b8565e41/attachment-0001.html>
[Bug 72785] bfgminer --scrypt on 7xxx+
https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #37 from Tom Stellard --- (In reply to Linux User from comment #36) > Got similar issues when trying scrypt. I have relatively recent bfgminer (~1 > month old git build) and more or less recent graphics stack: 3.17 kernel, > mesa 10.4 pre-release from Oibaf PPA and LLVM 3.5.1 > > I have bunch of HD5000 based cards, mostly HD5750/5770 and somesuch and R9 > 270. Tests have shown bfgminer performs correctly when computing SHA256 and > goes about 80% of catalyst at 57xx and even better than that on R9 270. > > However things are much worse when it comes to scrypt. I got impression open > driver can get issues if something aggressively using GPU VRAM. > > Some observations about open drivers stack so far: > - If you set scrypt intensity too high, there is high risk GPU would lock up > in fatal way and crash (can happen on both 57xx and R9). > Do you have an X server running? One cause of lockups is bfgminer hogging the GPU, and X not being able to do anything. I recommend trying without an X server. For best results when not using an X server, enable render nodes in the kernel by adding drm.rnodes=1 to your kernel command line. -- 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/20141124/d43d4331/attachment.html>
[PATCH] drm/exynos: vidi: add component support
This patch adds component support for vidi driver.
vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.
This patch fixes below error also,
# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[ 55.618529] [ cut here ]
[ 55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203
exynos_drm_crtc_dpms+0x88/0x17c()
[ 55.631268] Modules linked in:
[ 55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7
#1154
[ 55.641885] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 55.649597] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[ 55.656802] [] (dump_stack) from []
(warn_slowpath_common+0x6c/0x88)
[ 55.664866] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 55.673632] [] (warn_slowpath_null) from []
(exynos_drm_crtc_dpms+0x88/0x17c)
[ 55.682482] [] (exynos_drm_crtc_dpms) from []
(exynos_drm_crtc_commit+0x14/0x44)
[ 55.691622] [] (exynos_drm_crtc_commit) from []
(drm_crtc_helper_set_mode+0x3d0/0x51c)
[ 55.701233] [] (drm_crtc_helper_set_mode) from []
(drm_crtc_helper_set_config+0x87c/0x9dc)
[ 55.711230] [] (drm_crtc_helper_set_config) from []
(drm_mode_set_config_internal+0x58/0xd4)
[ 55.721380] [] (drm_mode_set_config_internal) from []
(restore_fbdev_mode+0xcc/0xec)
[ 55.730834] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[ 55.741424] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[] (drm_fb_helper_set_par+0x1c/0x60)
[ 55.752271] [] (drm_fb_helper_set_par) from []
(drm_fb_helper_hotplug_event+0x88/0xc4)
[ 55.761906] [] (drm_fb_helper_hotplug_event) from []
(drm_helper_hpd_irq_event+0xc8/0x134)
[ 55.771898] [] (drm_helper_hpd_irq_event) from []
(vidi_store_connection+0x90/0xc8)
[ 55.781268] [] (vidi_store_connection) from []
(kernfs_fop_write+0xc0/0x180)
[ 55.790045] [] (kernfs_fop_write) from []
(vfs_write+0xa0/0x1ac)
[ 55.797757] [] (vfs_write) from [] (SyS_write+0x44/0x9c)
[ 55.804790] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x30)
[ 55.812328] ---[ end trace 3c0fe4386702d4dd ]---
This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 ++
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3b6fdd6..45899fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
@@ -48,11 +49,11 @@ struct vidi_win_data {
struct vidi_context {
struct exynos_drm_manager manager;
struct exynos_drm_display display;
+ struct platform_device *pdev;
struct drm_device *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connectorconnector;
- struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -560,9 +561,10 @@ static struct exynos_drm_display_ops vidi_display_ops = {
.create_connector = vidi_create_connector,
};
-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
{
struct vidi_context *ctx = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
struct drm_crtc *crtc = ctx->crtc;
int ret;
@@ -584,9 +586,18 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
+
+static void vidi_unbind(struct device *dev, struct device *master, void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+ .bind = vidi_bind,
+ .unbind = vidi_unbind,
+};
+
static int vidi_probe(struct platform_device *pdev)
{
- struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;
@@ -599,6 +610,17 @@ static int vidi_probe(struct platform_device *pdev)
ctx->display.type = EXYNOS_DISPLAY_TYPE_VIDI;
ctx->display.ops = &vidi_display_ops;
ctx->default_win = 0;
+ ctx->pdev = pdev;
+
+ ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
+ ctx->manager.type);
+ if (ret)
+ return ret;
+
+ ret
drm/exynos: vidi: add component support
This patch adds component support for vidi driver.
vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.
This patch fixes below error also,
# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[ 55.618529] [ cut here ]
[ 55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203
exynos_drm_crtc_dpms+0x88/0x17c()
[ 55.631268] Modules linked in:
[ 55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7
#1154
[ 55.641885] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 55.649597] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[ 55.656802] [] (dump_stack) from []
(warn_slowpath_common+0x6c/0x88)
[ 55.664866] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 55.673632] [] (warn_slowpath_null) from []
(exynos_drm_crtc_dpms+0x88/0x17c)
[ 55.682482] [] (exynos_drm_crtc_dpms) from []
(exynos_drm_crtc_commit+0x14/0x44)
[ 55.691622] [] (exynos_drm_crtc_commit) from []
(drm_crtc_helper_set_mode+0x3d0/0x51c)
[ 55.701233] [] (drm_crtc_helper_set_mode) from []
(drm_crtc_helper_set_config+0x87c/0x9dc)
[ 55.711230] [] (drm_crtc_helper_set_config) from []
(drm_mode_set_config_internal+0x58/0xd4)
[ 55.721380] [] (drm_mode_set_config_internal) from []
(restore_fbdev_mode+0xcc/0xec)
[ 55.730834] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[ 55.741424] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[] (drm_fb_helper_set_par+0x1c/0x60)
[ 55.752271] [] (drm_fb_helper_set_par) from []
(drm_fb_helper_hotplug_event+0x88/0xc4)
[ 55.761906] [] (drm_fb_helper_hotplug_event) from []
(drm_helper_hpd_irq_event+0xc8/0x134)
[ 55.771898] [] (drm_helper_hpd_irq_event) from []
(vidi_store_connection+0x90/0xc8)
[ 55.781268] [] (vidi_store_connection) from []
(kernfs_fop_write+0xc0/0x180)
[ 55.790045] [] (kernfs_fop_write) from []
(vfs_write+0xa0/0x1ac)
[ 55.797757] [] (vfs_write) from [] (SyS_write+0x44/0x9c)
[ 55.804790] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x30)
[ 55.812328] ---[ end trace 3c0fe4386702d4dd ]---
This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 ++
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3b6fdd6..45899fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
@@ -48,11 +49,11 @@ struct vidi_win_data {
struct vidi_context {
struct exynos_drm_manager manager;
struct exynos_drm_display display;
+ struct platform_device *pdev;
struct drm_device *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connectorconnector;
- struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -560,9 +561,10 @@ static struct exynos_drm_display_ops vidi_display_ops = {
.create_connector = vidi_create_connector,
};
-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
{
struct vidi_context *ctx = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
struct drm_crtc *crtc = ctx->crtc;
int ret;
@@ -584,9 +586,18 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
+
+static void vidi_unbind(struct device *dev, struct device *master, void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+ .bind = vidi_bind,
+ .unbind = vidi_unbind,
+};
+
static int vidi_probe(struct platform_device *pdev)
{
- struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;
@@ -599,6 +610,17 @@ static int vidi_probe(struct platform_device *pdev)
ctx->display.type = EXYNOS_DISPLAY_TYPE_VIDI;
ctx->display.ops = &vidi_display_ops;
ctx->default_win = 0;
+ ctx->pdev = pdev;
+
+ ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
+ ctx->manager.type);
+ if (ret)
+ return ret;
+
+ ret
[Bug 72785] bfgminer --scrypt on 7xxx+
https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #36 from Linux User --- Got similar issues when trying scrypt. I have relatively recent bfgminer (~1 month old git build) and more or less recent graphics stack: 3.17 kernel, mesa 10.4 pre-release from Oibaf PPA and LLVM 3.5.1 I have bunch of HD5000 based cards, mostly HD5750/5770 and somesuch and R9 270. Tests have shown bfgminer performs correctly when computing SHA256 and goes about 80% of catalyst at 57xx and even better than that on R9 270. However things are much worse when it comes to scrypt. I got impression open driver can get issues if something aggressively using GPU VRAM. Some observations about open drivers stack so far: - If you set scrypt intensity too high, there is high risk GPU would lock up in fatal way and crash (can happen on both 57xx and R9). - It is also exceptionally unsafe to try sha256 with vectors=4 on HD 57xx. It would be much slower than other vector settings anyway, but still indication of some techmical problem lurking around. - If I'm setting up intensity at reasonable levels, it does builds kernels and computes BUT --benchmark ***NEVER*** accepts computed blocks, 100% reject rate. If I reduce intensity - error rate goes down. But still no accepted blocks. If I try CPU at same time, it computes several blocks at time frame where GPU gives no results at all. This indicates computations are just going wrong. p.s. IMO bfgminer is a really worthy program to add it into automated tests/regression checks, etc. P.P.S. and what about better fan/intensity control? Problem is that if ambient is warm, about 25-26C, 57xx cards can make really annoying noise. Heat can be reduced via intensity a bit but it works poorly and not really fine grained. There is also overheat + hysteresis setting which can be (ab)used to cool down GPU a bit but it makes fan to speed up and down in oscillating manner which is also really annoying to hear. Any proper tooling to hint DPM about max acceptable cooler rate or max allowed GPU freq comparable to what Catalyst haves to offer in ADL? Preferred attitude would be to reduce GPU core clocks if ambient is high and increase it if ambient temp is low and TDP/fan setup permits. Its possible to achieve with Catalyst, but Catalyst really stinks and really I want to get rid of it. -- 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/20141124/173c6ede/attachment.html>
[PATCH] drm/exynos: fix exynos_drm_component_del
This patch resolves the issue that component object isn't removed correctly. A given component object couldn't be placed to head of drm_component_list so all component objects added to the drm_component_list should be checked to remove the given component object. Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index c5cb8b6..0e4813b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -473,8 +473,6 @@ void exynos_drm_component_del(struct device *dev, list_del(&cdev->list); kfree(cdev); } - - break; } mutex_unlock(&drm_component_lock); -- 1.7.9.5
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 4:26 PM, Thierry Reding
wrote:
> On Mon, Nov 24, 2014 at 04:17:18PM +0530, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
>> wrote:
>> > On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
>> >> DP PHY now require pmu-system-controller to handle PMU register
>> >> to control PHY's power isolation. Adding the same to dp-phy
>> >> node.
>> >>
>> >> Signed-off-by: Vivek Gautam
>> >> Reviewed-by: Jingoo Han
>> >> Tested-by: Javier Martinez Canillas
>> >> Cc: Kukjin Kim
>> >> ---
>> >> arch/arm/boot/dts/exynos5250.dtsi |2 +-
>> >> arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>> >> 2 files changed, 3 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> >> b/arch/arm/boot/dts/exynos5250.dtsi
>> >> index 0a588b4..bebd099 100644
>> >> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> >> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> >> @@ -732,7 +732,7 @@
>> >>
>> >> dp_phy: video-phy at 10040720 {
>> >> compatible = "samsung,exynos5250-dp-video-phy";
>> >> - reg = <0x10040720 4>;
>> >> + samsung,pmu-syscon = <&pmu_system_controller>;
>> >> #phy-cells = <0>;
>> >> };
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>> >> b/arch/arm/boot/dts/exynos5420.dtsi
>> >> index 8617a03..1353a09 100644
>> >> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> >> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> >> @@ -503,8 +503,8 @@
>> >> };
>> >>
>> >> dp_phy: video-phy at 10040728 {
>> >> - compatible = "samsung,exynos5250-dp-video-phy";
>> >> - reg = <0x10040728 4>;
>> >> + compatible = "samsung,exynos5420-dp-video-phy";
>> >> + samsung,pmu-syscon = <&pmu_system_controller>;
>> >> #phy-cells = <0>;
>> >> };
>> >>
>> >
>> > It seems like these nodes have been in the Linux tree since 3.12 and
>> > 3.17, respectively and these changes break backwards-compatibility. Has
>> > anyone thought about the possible consequences?
>>
>> Sorry for my ignorance, but i have a doubt.
>> If the bindings and device node both are being changed in the same kernel
>> version (as fixes),
>> so that the stable will have both; then the only scenerio of backward
>> compatibility comes when kernel is upgraded but not dtbs.
>
> Correct.
>
>> Does such upgradation makes sense for distros ?
>
> Yes. Back at the time a decision was made that device trees need to be
> stable ABI because eventually they'd be shipped with the device rather
> than the distribution. As such it may not at all be possible to update
> them (they could be in some sort of ROM).
>
> For that reason new kernels need to keep working with old DTBs unless an
> argument can be made that would justify breaking things. I don't think I
> have ever seen anyone win such an argument.
> One of the rare exceptions
> that I know of is if you can prove that a given hardware block has never
> been used in an upstream kernel, then changing the DTB in backwards-
> incompatible ways would be okay because you wouldn't be breaking things
> for existing users.
I am pretty sure about the Chrome devices (which have not been
upgraded to any kernel after
3.8).
Probably Javier may have better knowledge.
Javier, is there any other device using upstream kernel post 3.12 (any
arndale octa based) ?
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
[PATCH 3/3] drm/exynos: move Exynos platform drivers registration to init
On 2014ë
11ì 21ì¼ 08:42, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Registering the Exynos DRM subdevices platform drivers in the probe
> function is causing an infinite loop. Fix this by moving it to the
> exynos_drm_init() function to register the drivers on module init.
>
> Registering drivers in the probe functions causes a deadlock in the parent
> device lock. See Grant Likely explanation on the topic:
>
> "I think the problem is that exynos_drm_init() is registering a normal
> (non-OF) platform device, so the parent will be /sys/devices/platform.
> It immediately gets bound against exynos_drm_platform_driver which
> calls the exynos drm_platform_probe() hook. The driver core obtains
> device_lock() on the device *and on the device parent*.
>
> Inside the probe hook, additional platform_drivers get registered.
> Each time one does, it tries to bind against every platform device in
> the system, which includes the ones created by OF. When it attempts to
> bind, it obtains device_lock() on the device *and on the device
> parent*.
>
> Before the change to move of-generated platform devices into
> /sys/devices/platform, the devices had different parents. Now both
> devices have /sys/devices/platform as the parent, so yes they are
> going to deadlock.
>
> The real problem is registering drivers from within a probe hook. That
> is completely wrong for the above deadlock reason. __driver_attach()
> will deadlock. Those registrations must be pulled out of .probe().
>
> Registering devices in .probe() is okay because __device_attach()
> doesn't try to obtain device_lock() on the parent."
>
> INFO: task swapper/0:1 blocked for more than 120 seconds.
>Not tainted 3.18.0-rc3-next-20141105 #794
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> swapper/0 D c052534c 0 1 0 0x
> [] (__schedule) from []
> (schedule_preempt_disabled+0x14/0x20)
> [] (schedule_preempt_disabled) from []
> (mutex_lock_nested+0x1c4/0x464
>
> [] (mutex_lock_nested) from []
> (__driver_attach+0x48/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
> [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
> [] (driver_register) from []
> (exynos_drm_platform_probe+0x34/0x234)
> [] (exynos_drm_platform_probe) from []
> (platform_drv_probe+0x48/0xa4)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x13c/0x37c)
> [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
> [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
> [] (driver_register) from [] (exynos_drm_init+0x70/0xa0)
> [] (exynos_drm_init) from [] (do_one_initcall+0xac/0x1f0)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x10c/0x1d8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
> 3 locks held by swapper/0/1:
> #0: (&dev->mutex){..}, at: [] __driver_attach+0x48/0x98
> #1: (&dev->mutex){..}, at: [] __driver_attach+0x58/0x98
> #2: (&dev->mutex){..}, at: [] __driver_attach+0x48/0x98
>
> Signed-off-by: Javier Martinez Canillas
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 124
> +++-
> 1 file changed, 59 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 91891cf..cb3ed9b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -548,6 +548,38 @@ static const struct component_master_ops exynos_drm_ops
> = {
> .unbind = exynos_drm_unbind,
> };
>
> +static int exynos_drm_platform_probe(struct platform_device *pdev)
> +{
> + struct component_match *match;
> +
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
> +
> + match = exynos_drm_match_add(&pdev->dev);
> + if (IS_ERR(match)) {
> + return PTR_ERR(match);
> + }
> +
> + return component_master_add_with_match(&pdev->dev, &exynos_drm_ops,
> +match);
> +}
> +
> +static int exynos_drm_platform_remove(struct platform_device *pdev)
> +{
> + component_master_del(&pdev->dev, &exynos_drm_ops);
> + return 0;
> +}
> +
> +static struct platform_driver exynos_drm_platform_driver = {
> + .probe = exynos_drm_platform_probe,
> + .remove = exynos_drm_platform_remove,
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "exynos-drm",
> + .pm = &exynos_drm_pm_ops,
> + },
> +};
> +
> static struct platform_driver *const exynos_drm_kms_drivers[] = {
> #ifdef CONFIG_DRM_EXYNOS_FIMD
> &fimd_driver,
>
[GIT PULL FOR v3.19] R-Car DU changes
On Mon, Nov 24, 2014 at 3:29 PM, Lars-Peter Clausen wrote: > On 11/24/2014 09:01 PM, Dave Airlie wrote: >> >> On 25 November 2014 at 00:18, Lars-Peter Clausen wrote: >>> >>> On 11/24/2014 03:00 PM, Laurent Pinchart wrote: Hi Daniel, (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: Decouple EDID parsing from I2C adapter" patch available at git://linuxtv.org/pinchartl/fbdev.git drm/next/du) On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: > > > On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: >>> >>> >>> - the interface looks rather backwards: Either this still does i2c >>> reads, and then you'd just need a i2c-over-whatever adapter to >>> make >>> it >>> work. Or you have other magic means to optain an edid block, in >>> which >>> case just do that and then feed the edid drm_add_edid_modes. >> >> >> >> I have a magic way to get EDID over I2C :-) Basically the ADV7511 >> controls >> the DDC bus, and exposes EDID data over I2C using vendor commands. To >> read an EDID block I have to write an ADV7511 register over I2C with >> the >> block number, wait for an interrupt, read a status register to check >> whether EDID data is available or whether an error occurred, and then >> read EDID data from the ADV7511 over I2C in 64-bytes chunks. This >> needs >> to be repeated for every block. I thus can't use drm_get_edid() >> directly. > > > > Sounds familiar. See the special ddc-over-sdvo i2c bus we register in > intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a > bit > of boilerplate, but in the end just amounts to 3 small functions and > one > tiny vtable to wire it all up cleanly. That's what I would have done as well if I had a device-specific I2C adapter connected to the DDC bus, but in this case the interface exposed by the ADV7511 to the SoC over I2C consists of higher level device-specific I2C commands to read EDID data. There is no low-level I2C read/write primitives available. I would thus need to expose a fake adapter that would receive I2C commands, parse them to detect an EDID block read, retrieve the EDID data and return them from the fake read. That doesn't make much sense to me. >>> >>> >>> >>> The intel sdvo looks just like a simple I2C mux which will just >>> pass-through >>> messages from the master to the EDID EEPROM. The ADV7511 is unfortunately >>> a >>> bit different. You tell it to fetch the EDID information, then it will do >>> some magic and then you can read the EDID back. Abstracting this as a >>> this >>> as a I2C controller will, while possible, result in a fair amount of >>> boiler >>> plate code that will not look particularly pretty. >> >> >> It sounds also a bit like DP auxch also, or even how on UDL we get the >> edid >> over USB. >> >> I'd rather see not pretty code that only one person had to look at though >> :-) >> with lots of comments on the hw design that demands ugly. > > > I'd rather not see that if I'm the person who has to look at it ;) > > But looking around it appears as if this is a more common thing among > external HDMI encoders though. E.g. the tda998x has the exact same issue and > the current driver just copy&pastes drm_do_get_edid() and plugs in its own > EDID block retrieval method. > > On the other hand the patch that makes it possible to use a different > backend then a raw I2C adapter to fetch the EDID is extremely trivial and > doesn't make the existing code more complex in any way. > I suppose the only real disadvantage of the patch is it gives driver writers a bad alternative in cases where they really should expose their ddc as an i2c_adapter.. but perhaps we should just handle that via sufficient review ;-) (I have seen enough downstream drivers that could use i2c_adapter but do not..) BR, -R > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] MAINTAINERS: add maintainer for i.MX DRM driver
Add myself as the maintainer of the i.MX DRM driver. Signed-off-by: Philipp Zabel Acked-by: Shawn Guo --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3c69a3c7..b29325d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3202,6 +3202,13 @@ F: drivers/gpu/drm/exynos/ F: include/drm/exynos* F: include/uapi/drm/exynos* +DRM DRIVERS FOR FREESCALE IMX +M: Philipp Zabel +L: dri-devel at lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/imx/ +F: Documentation/devicetree/bindings/drm/imx/ + DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding M: Terje Bergström -- 2.1.1
[PATCH v2 1/2] drm: imx: Move imx-drm driver out of staging
The imx-drm driver was put into staging mostly for the following reasons,
all of which have been addressed or superseded:
- convert the irq driver to use linear irq domains
- work out the device tree bindings, this lead to the common of_graph
bindings being used
- factor out common helper functions, this mostly resulted in the
component framework and drm of_graph helpers.
Before adding new fixes, and certainly before adding new features,
move it into its proper place below drivers/gpu/drm.
Signed-off-by: Philipp Zabel
---
.../{staging/imx-drm => drm/imx}/fsl-imx-drm.txt| 0
.../bindings/{staging/imx-drm => drm/imx}/hdmi.txt | 0
.../bindings/{staging/imx-drm => drm/imx}/ldb.txt | 0
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile| 1 +
drivers/{staging/imx-drm => gpu/drm/imx}/Kconfig| 0
drivers/{staging/imx-drm => gpu/drm/imx}/Makefile | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-drm-core.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-drm.h | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-hdmi.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-hdmi.h | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-ldb.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/imx-tve.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-crtc.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-plane.c | 0
drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-plane.h | 0
.../{staging/imx-drm => gpu/drm/imx}/parallel-display.c | 0
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile| 1 -
drivers/staging/imx-drm/TODO| 17 -
20 files changed, 3 insertions(+), 20 deletions(-)
rename Documentation/devicetree/bindings/{staging/imx-drm =>
drm/imx}/fsl-imx-drm.txt (100%)
rename Documentation/devicetree/bindings/{staging/imx-drm => drm/imx}/hdmi.txt
(100%)
rename Documentation/devicetree/bindings/{staging/imx-drm => drm/imx}/ldb.txt
(100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/Kconfig (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/Makefile (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-drm-core.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-drm.h (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-hdmi.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-hdmi.h (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-ldb.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/imx-tve.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-crtc.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-plane.c (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/ipuv3-plane.h (100%)
rename drivers/{staging/imx-drm => gpu/drm/imx}/parallel-display.c (100%)
delete mode 100644 drivers/staging/imx-drm/TODO
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
similarity index 100%
rename from Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
rename to Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
b/Documentation/devicetree/bindings/drm/imx/hdmi.txt
similarity index 100%
rename from Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
rename to Documentation/devicetree/bindings/drm/imx/hdmi.txt
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
b/Documentation/devicetree/bindings/drm/imx/ldb.txt
similarity index 100%
rename from Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
rename to Documentation/devicetree/bindings/drm/imx/ldb.txt
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 37c5a6e..24c2d7c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -202,3 +202,5 @@ source "drivers/gpu/drm/panel/Kconfig"
source "drivers/gpu/drm/sti/Kconfig"
source "drivers/gpu/drm/amd/amdkfd/Kconfig"
+
+source "drivers/gpu/drm/imx/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd9d35b..47d8986 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_DRM_BOCHS) += bochs/
obj-$(CONFIG_DRM_MSM) += msm/
obj-$(CONFIG_DRM_TEGRA) += tegra/
obj-$(CONFIG_DRM_STI) += sti/
+obj-$(CONFIG_DRM_IMX) += imx/
obj-y += i2c/
obj-y += panel/
obj-y += bridge/
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/gpu/drm/imx/Kconfig
similarity index 100%
rename from drivers/staging/imx-drm/Kconfig
rename to drivers/gpu/drm/imx/Kconfig
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/gpu/drm/imx/Makefile
similarity index 100%
rename from drivers/staging/imx-drm/Makefile
rename to drivers/gpu/drm/imx/Makefile
dif
[PATCH] drm/exynos: avoid leak if exynos_dpi_probe() fails
From: Gustavo Padovan
The component must be deleted if the probe fails.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1bf52ab..abd2ca9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1215,8 +1215,10 @@ static int fimd_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ctx->display = exynos_dpi_probe(dev);
- if (IS_ERR(ctx->display))
- return PTR_ERR(ctx->display);
+ if (IS_ERR(ctx->display)) {
+ ret = PTR_ERR(ctx->display);
+ goto err_del_component;
+ }
pm_runtime_enable(dev);
--
1.9.3
[PATCH 4/4] drm/exynos: remove struct exynos_drm_overlay
From: Gustavo Padovan
struct exynos_drm_overlay has no practical advantage nor serves as
important piece of the exynos API design. The only place it was used
was inside the struct exynos_plane which was just causing a extra
access overhead. Users had to access the overlay first and just then
get the plane information it contains.
This patch merges struct exynos_drm_overlay into struct exynos_plane.
It also renames struct exynos_plane to struct exynos_drm_plane.
The rational is to cut one step to access plane information.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 +++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 44
drivers/gpu/drm/exynos/exynos_drm_plane.c | 85 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 38 +++---
drivers/gpu/drm/exynos/exynos_mixer.c | 50 +-
6 files changed, 112 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index e353d35..dbd4227 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -24,7 +24,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device *dev,
int pipe);
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);
void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
- struct exynos_drm_overlay *overlay);
+ struct exynos_drm_plane *plane);
void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index ffef077..ae0dce7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -25,6 +25,7 @@
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
drm_crtc)
+#define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
/* This enumerates device type. */
enum exynos_drm_device_type {
@@ -47,6 +48,7 @@ enum exynos_drm_output_type {
/*
* Exynos drm common overlay structure.
*
+ * @base: plane object
* @fb_x: offset x on a framebuffer to be displayed.
* - the unit is screen coordinates.
* @fb_y: offset y on a framebuffer to be displayed.
@@ -76,11 +78,14 @@ enum exynos_drm_output_type {
* @local_path: in case of lcd type, local path mode on or off.
* @transparency: transparency on or off.
* @activated: activated or not.
+ * @enabled: enabled or not.
*
* this structure is common to exynos SoC and its contents would be copied
* to hardware specific overlay info.
*/
-struct exynos_drm_overlay {
+
+struct exynos_drm_plane {
+ struct drm_plane base;
unsigned int fb_x;
unsigned int fb_y;
unsigned int fb_width;
@@ -107,6 +112,7 @@ struct exynos_drm_overlay {
bool local_path:1;
bool transparency:1;
bool activated:1;
+ bool enabled:1;
};
/*
@@ -188,7 +194,7 @@ struct exynos_drm_manager_ops {
void (*disable_vblank)(struct exynos_drm_manager *mgr);
void (*wait_for_vblank)(struct exynos_drm_manager *mgr);
void (*win_mode_set)(struct exynos_drm_manager *mgr,
- struct exynos_drm_overlay *overlay);
+ struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..abd2ca9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -518,44 +518,44 @@ static void fimd_disable_vblank(struct exynos_drm_manager
*mgr)
}
static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
- struct exynos_drm_overlay *overlay)
+ struct exynos_drm_plane *plane)
{
struct fimd_context *ctx = mgr_to_fimd(mgr);
struct fimd_win_data *win_data;
int win;
unsigned long offset;
- if (!overlay) {
- DRM_ERROR("overlay is NULL\n");
+ if (!plane) {
+ DRM_ERROR("plane is NULL\n");
return;
}
- win = overlay->zpos;
+ win = plane->zpos;
if (win == DEFAULT_ZPOS)
win = ctx->default_win;
if (win < 0 || win >= WINDOWS_NR)
return;
- offset = overlay->fb_x * (overlay->bpp >> 3);
- offset += overlay->fb_y * overlay->pitch;
+ offset = plane->fb_x * (plane->bpp >> 3);
+ offset += plane->fb
[PATCH 3/4] drm/exynos: remove exynos_drm_crtc_plane_* wrappers
From: Gustavo Padovan
This functions were doing nothing but calling a manager op function,
so remove them and call the manager directly.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 33 ---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 ++
2 files changed, 15 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e74b6fe..13c7ba5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -410,39 +410,6 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
*dev, int pipe)
spin_unlock_irqrestore(&dev->event_lock, flags);
}
-void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
- struct exynos_drm_overlay *overlay)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
-
- if (manager->ops->win_mode_set)
- manager->ops->win_mode_set(manager, overlay);
-}
-
-void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
-
- if (manager->ops->win_commit)
- manager->ops->win_commit(manager, zpos);
-}
-
-void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
-
- if (manager->ops->win_enable)
- manager->ops->win_enable(manager, zpos);
-}
-
-void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
-
- if (manager->ops->win_disable)
- manager->ops->win_disable(manager, zpos);
-}
-
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
{
struct exynos_drm_manager *manager;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c7045a66..7d76861 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -76,6 +76,7 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct
drm_crtc *crtc,
uint32_t src_w, uint32_t src_h)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
+ struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
unsigned int actual_w;
unsigned int actual_h;
@@ -141,7 +142,8 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct
drm_crtc *crtc,
plane->crtc = crtc;
- exynos_drm_crtc_plane_mode_set(crtc, overlay);
+ if (manager->ops->win_mode_set)
+ manager->ops->win_mode_set(manager, overlay);
return 0;
}
@@ -150,26 +152,35 @@ void exynos_plane_commit(struct drm_plane *plane)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
+ struct exynos_drm_manager *manager =
to_exynos_crtc(plane->crtc)->manager;
- exynos_drm_crtc_plane_commit(plane->crtc, overlay->zpos);
+ if (manager->ops->win_commit)
+ manager->ops->win_commit(manager, overlay->zpos);
}
void exynos_plane_dpms(struct drm_plane *plane, int mode)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
+ struct exynos_drm_manager *manager;
if (mode == DRM_MODE_DPMS_ON) {
if (exynos_plane->enabled)
return;
- exynos_drm_crtc_plane_enable(plane->crtc, overlay->zpos);
+ manager = to_exynos_crtc(plane->crtc)->manager;
+ if (manager->ops->win_enable)
+ manager->ops->win_enable(manager, overlay->zpos);
+
exynos_plane->enabled = true;
} else {
if (!exynos_plane->enabled)
return;
- exynos_drm_crtc_plane_disable(plane->crtc, overlay->zpos);
+ manager = to_exynos_crtc(plane->crtc)->manager;
+ if (manager->ops->win_disable)
+ manager->ops->win_disable(manager, overlay->zpos);
+
exynos_plane->enabled = false;
}
}
--
1.9.3
[PATCH 2/4] drm/exynos: expose struct exynos_drm_crtc
From: Gustavo Padovan
Let other pieces of the driver access struct exynos_drm_crtc as well.
struct exynos_drm_manager will be merged into struct exynos_drm_crtc, in
the sense we will move all its members to exynos_drm_crtc, so to start
this conversion exynos_drm_crtc need to be exposed as well.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 30 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 30 ++
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c8a3169..e74b6fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -20,36 +20,6 @@
#include "exynos_drm_encoder.h"
#include "exynos_drm_plane.h"
-enum exynos_crtc_mode {
- CRTC_MODE_NORMAL, /* normal mode */
- CRTC_MODE_BLANK,/* The private plane of crtc is blank */
-};
-
-/*
- * Exynos specific crtc structure.
- *
- * @drm_crtc: crtc object.
- * @manager: the manager associated with this crtc
- * @pipe: a crtc index created at load() with a new crtc object creation
- * and the crtc object would be set to private->crtc array
- * to get a crtc object corresponding to this pipe from private->crtc
- * array when irq interrupt occurred. the reason of using this pipe is that
- * drm framework doesn't support multiple irq yet.
- * we can refer to the crtc to current hardware interrupt occurred through
- * this pipe value.
- * @dpms: store the crtc dpms value
- * @mode: store the crtc mode value
- */
-struct exynos_drm_crtc {
- struct drm_crtc drm_crtc;
- struct exynos_drm_manager *manager;
- unsigned intpipe;
- unsigned intdpms;
- enum exynos_crtc_mode mode;
- wait_queue_head_t pending_flip_queue;
- atomic_tpending_flip;
-};
-
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9e14ae6f..ffef077 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -215,6 +215,36 @@ struct exynos_drm_manager {
struct exynos_drm_manager_ops *ops;
};
+enum exynos_crtc_mode {
+ CRTC_MODE_NORMAL, /* normal mode */
+ CRTC_MODE_BLANK,/* The private plane of crtc is blank */
+};
+
+/*
+ * Exynos specific crtc structure.
+ *
+ * @drm_crtc: crtc object.
+ * @manager: the manager associated with this crtc
+ * @pipe: a crtc index created at load() with a new crtc object creation
+ * and the crtc object would be set to private->crtc array
+ * to get a crtc object corresponding to this pipe from private->crtc
+ * array when irq interrupt occurred. the reason of using this pipe is that
+ * drm framework doesn't support multiple irq yet.
+ * we can refer to the crtc to current hardware interrupt occurred through
+ * this pipe value.
+ * @dpms: store the crtc dpms value
+ * @mode: store the crtc mode value
+ */
+struct exynos_drm_crtc {
+ struct drm_crtc drm_crtc;
+ struct exynos_drm_manager *manager;
+ unsigned intpipe;
+ unsigned intdpms;
+ enum exynos_crtc_mode mode;
+ wait_queue_head_t pending_flip_queue;
+ atomic_tpending_flip;
+};
+
struct exynos_drm_g2d_private {
struct device *dev;
struct list_headinuse_cmdlist;
--
1.9.3
[PATCH 1/4] drm/exynos: move to_exynos_crtc() macro to main header
From: Gustavo Padovan
With this change we allow other pieces of the code to use this macro.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 45026e6..c8a3169 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -20,9 +20,6 @@
#include "exynos_drm_encoder.h"
#include "exynos_drm_plane.h"
-#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
- drm_crtc)
-
enum exynos_crtc_mode {
CRTC_MODE_NORMAL, /* normal mode */
CRTC_MODE_BLANK,/* The private plane of crtc is blank */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2e4e91b..9e14ae6f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -23,6 +23,9 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
+ drm_crtc)
+
/* This enumerates device type. */
enum exynos_drm_device_type {
EXYNOS_DEVICE_TYPE_NONE,
--
1.9.3
[PATCH 0/4] removal of extra abstraction layers
From: Gustavo Padovan Hi Inki, In this series I've removed some level of indirection from the exynos_drm_code. There two moves in these patches, first we remove all exynos_drm_crtc_plane_*() wrappers and call the manager specific functions directly. The other change is the removal of struct exynos_drm_overlay(). In my understanding the overlay struct was just storing plane data in a 1:1 relationship so it made sense to merge its fields in struct exynos_drm_plane and remove another abstraction from the driver. Next steps: During our initial investigation on the Exynos DRM driver we've spoted a few abstractions that could be removed to get a more clean and less abstract code. - struct exynos_drm_manager: this is just a helper of struct exynos_drm_crtc, I suggest we could merge them both. - struct *_win_data: Most of the share common fields and could be merged int struct exynos_drm_plane. - some more function wrapper can be removed as well. After these changes intead of looking to manager and win_data we will look into crtc and planes. The new names give us more clue about what a piece of code is doing since they are already defined and used by the whole DRM ecossytem. What your thoughts on this? I've seen that you pushed some patches to remove static usage of managers so I would like to check with you which direction are you planning to go with this. I've done some code[0] around this but now it needs a rebase against you exynos-drm-next. [0] https://git.kernel.org/cgit/linux/kernel/git/padovan/drm-exynos.git/log/?h=cleanup Gustavo Padovan (4): drm/exynos: move to_exynos_crtc() macro to main header drm/exynos: expose struct exynos_drm_crtc drm/exynos: remove exynos_drm_crtc_plane_* wrappers drm/exynos: remove struct exynos_drm_overlay drivers/gpu/drm/exynos/exynos_drm_crtc.c | 66 - drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 43 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 44 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.c | 96 +++ drivers/gpu/drm/exynos/exynos_drm_vidi.c | 38 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 50 7 files changed, 156 insertions(+), 183 deletions(-) -- 1.9.3
[GIT PULL FOR v3.19] R-Car DU changes
On Mon, Nov 24, 2014 at 04:00:53PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: > Decouple EDID parsing from I2C adapter" patch available at > git://linuxtv.org/pinchartl/fbdev.git drm/next/du) > > On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: > > On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: > > > > - the interface looks rather backwards: Either this still does i2c > > > > reads, and then you'd just need a i2c-over-whatever adapter to make it > > > > work. Or you have other magic means to optain an edid block, in which > > > > case just do that and then feed the edid drm_add_edid_modes. > > > > > > I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls > > > the DDC bus, and exposes EDID data over I2C using vendor commands. To > > > read an EDID block I have to write an ADV7511 register over I2C with the > > > block number, wait for an interrupt, read a status register to check > > > whether EDID data is available or whether an error occurred, and then > > > read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs > > > to be repeated for every block. I thus can't use drm_get_edid() directly. > > > > Sounds familiar. See the special ddc-over-sdvo i2c bus we register in > > intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit > > of boilerplate, but in the end just amounts to 3 small functions and one > > tiny vtable to wire it all up cleanly. > > That's what I would have done as well if I had a device-specific I2C adapter > connected to the DDC bus, but in this case the interface exposed by the > ADV7511 to the SoC over I2C consists of higher level device-specific I2C > commands to read EDID data. There is no low-level I2C read/write primitives > available. I would thus need to expose a fake adapter that would receive I2C > commands, parse them to detect an EDID block read, retrieve the EDID data and > return them from the fake read. That doesn't make much sense to me. Yeah that's a bit annoying indeed. So if you capture that in the commit message + kerneldoc (stating clearly what the other options are and when to use this) the I'm ok with this patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
Hi,
On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
wrote:
> On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
>> DP PHY now require pmu-system-controller to handle PMU register
>> to control PHY's power isolation. Adding the same to dp-phy
>> node.
>>
>> Signed-off-by: Vivek Gautam
>> Reviewed-by: Jingoo Han
>> Tested-by: Javier Martinez Canillas
>> Cc: Kukjin Kim
>> ---
>> arch/arm/boot/dts/exynos5250.dtsi |2 +-
>> arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 0a588b4..bebd099 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -732,7 +732,7 @@
>>
>> dp_phy: video-phy at 10040720 {
>> compatible = "samsung,exynos5250-dp-video-phy";
>> - reg = <0x10040720 4>;
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>> #phy-cells = <0>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 8617a03..1353a09 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -503,8 +503,8 @@
>> };
>>
>> dp_phy: video-phy at 10040728 {
>> - compatible = "samsung,exynos5250-dp-video-phy";
>> - reg = <0x10040728 4>;
>> + compatible = "samsung,exynos5420-dp-video-phy";
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>> #phy-cells = <0>;
>> };
>>
>
> It seems like these nodes have been in the Linux tree since 3.12 and
> 3.17, respectively and these changes break backwards-compatibility. Has
> anyone thought about the possible consequences?
Sorry for my ignorance, but i have a doubt.
If the bindings and device node both are being changed in the same kernel
version (as fixes),
so that the stable will have both; then the only scenerio of backward
compatibility comes when kernel is upgraded but not dtbs.
Does such upgradation makes sense for distros ?
>
> Although, looking more closely it seems like this isn't the first time
> that backwards-compatibility was broken in these files, so perhaps
> nobody cares...
>
> Thierry
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
ro console=ttySAC3,115200 debug earlyprintk init=/linuxrc Also attached the complete log: kernel-log_next20141124. I am still not sure how SND_SOC creates a problem for you. I did not revert any patch (apart from the display config revert) as seen in my git hash. So with this setup, my peach-pi boots up fine, display comes up; CONFIG_SND_SOC is still enabled. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- next part -- A non-text attachment was scrubbed... Name: config_next20141124 Type: application/octet-stream Size: 81025 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/6c761fa1/attachment-0002.obj> -- next part -- A non-text attachment was scrubbed... Name: kernel-log_next20141124 Type: application/octet-stream Size: 35935 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/6c761fa1/attachment-0003.obj>
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi,
Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas:
> On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote:
>> On 11/21/2014 06:32 PM, Ajay kumar wrote:
>>> I have rebased my bridge series on top of linux-next.
>>>
>>> This is my git log:
>>> 4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for
>>> display panel support""
>>> 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge
>>> and panel using videoport and endpoints
>>> aee649c ARM: dts: snow: represent the connection between bridge and
>>> panel using videoport and endpoints
>>> 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
>>> 581257f Documentation: bridge: Add documentation for ps8622 DT properties
>>> 178e8b9 Documentation: devicetree: Add vendor prefix for parade
>>> 0ceea75 Documentation: drm: bridge: move to video/bridge
>>> f143e2e drm/bridge: ptn3460: use gpiod interface
>>> 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach
>>> 32ac563 drm/bridge: ptn3460: support drm_panel
>>> 91c6c30 drm/exynos: dp: support drm_bridge
>>> 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model
>>> 602f343 drm/bridge: make bridge registration independent of drm flow
>>> 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
>>> 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
>>> 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>> 28655d1 drm/exynos: Move platform drivers registration to module init
>>> ed6778a Add linux-next specific files for 20141121
>>>
>>> I have attached the rebased patches as well.
>>> I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
>>> Display is totally fine with exynos_defconfig (booting is fine even
>>> with CONFIG_SND_SOC_SNOW=y)
>>
>> Thanks for forward porting your patches to linux-next. Unfortunately I
>> won't have time to test them until Monday but I wonder why you didn't
>> have the boot issues that we have with next-20141121.
>
> I tested your ToT patches on top of next-20141121, this is my git log:
>
> 93fe3d7 Revert "Revert "ARM: exynos_defconfig: Enable options for display
> panel support""
> 552f74e ARM: dts: peach-pit: represent the connection between bridge and
> panel using videoport and endpoints
> dbbc293 ARM: dts: snow: represent the connection between bridge and panel
> using videoport and endpoints
> d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
> f29a649 Documentation: bridge: Add documentation for ps8622 DT properties
> 6ade887 Documentation: devicetree: Add vendor prefix for parade
> d81c42d Documentation: drm: bridge: move to video/bridge
> 50b9828 drm/bridge: ptn3460: use gpiod interface
> 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach
> f3cf063 drm/bridge: ptn3460: support drm_panel
> cab682b drm/exynos: dp: support drm_bridge
> 6e78916 drm/bridge: ptn3460: Convert to i2c driver model
> 93f4b5f drm/bridge: make bridge registration independent of drm flow
> 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
> eb6996e drm/bridge: ptn3460: Few trivial cleanups
> c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> 51b2c75 drm/exynos: Move platform drivers registration to module init
> ed6778a Add linux-next specific files for 20141121
>
>> I found that the commit ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add
>> runtime Power Management support v12") had to be reverted in order to
>> boot linux-next.
>>
>
> Display works but I needed to revert the mentioned commit, otherwise
> the boot hangs as reported before. I'm using exynos_defconfig and this
> kernel command line:
>
> console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
I tested Spring with next-20141124, and finally got it to work! :)
Thanks a lot, Ajay and Javier!
To be on the safe side, I reverted the patch pointed out by Javier and
was still using clk_ignore_unused.
Ajay, note that your rebased Snow patch has the last hunk indented one
level too deep.
I'll post a cleaned-up bridge patch for Spring later.
Cheers,
Andreas
--
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
[GIT PULL FOR v3.19] R-Car DU changes
Hi Daniel, (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: Decouple EDID parsing from I2C adapter" patch available at git://linuxtv.org/pinchartl/fbdev.git drm/next/du) On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: > On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: > > > - the interface looks rather backwards: Either this still does i2c > > > reads, and then you'd just need a i2c-over-whatever adapter to make it > > > work. Or you have other magic means to optain an edid block, in which > > > case just do that and then feed the edid drm_add_edid_modes. > > > > I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls > > the DDC bus, and exposes EDID data over I2C using vendor commands. To > > read an EDID block I have to write an ADV7511 register over I2C with the > > block number, wait for an interrupt, read a status register to check > > whether EDID data is available or whether an error occurred, and then > > read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs > > to be repeated for every block. I thus can't use drm_get_edid() directly. > > Sounds familiar. See the special ddc-over-sdvo i2c bus we register in > intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit > of boilerplate, but in the end just amounts to 3 small functions and one > tiny vtable to wire it all up cleanly. That's what I would have done as well if I had a device-specific I2C adapter connected to the DDC bus, but in this case the interface exposed by the ADV7511 to the SoC over I2C consists of higher level device-specific I2C commands to read EDID data. There is no low-level I2C read/write primitives available. I would thus need to expose a fake adapter that would receive I2C commands, parse them to detect an EDID block read, retrieve the EDID data and return them from the fake read. That doesn't make much sense to me. -- Regards, Laurent Pinchart
[PATCH] drm/exynos: Fix exynos_dpi_remove() parameter
From: Gustavo Padovan
exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2e4e91b..2e50634 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -307,7 +307,10 @@ int exynos_dpi_remove(struct exynos_drm_display *display);
#else
static inline struct exynos_drm_display *
exynos_dpi_probe(struct device *dev) { return NULL; }
-static inline int exynos_dpi_remove(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct exynos_drm_display *display)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
--
1.9.3
[GIT PULL FOR v3.19] R-Car DU changes
On 11/24/2014 03:00 PM, Laurent Pinchart wrote: > Hi Daniel, > > (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: > Decouple EDID parsing from I2C adapter" patch available at > git://linuxtv.org/pinchartl/fbdev.git drm/next/du) > > On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: >> On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: - the interface looks rather backwards: Either this still does i2c reads, and then you'd just need a i2c-over-whatever adapter to make it work. Or you have other magic means to optain an edid block, in which case just do that and then feed the edid drm_add_edid_modes. >>> >>> I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls >>> the DDC bus, and exposes EDID data over I2C using vendor commands. To >>> read an EDID block I have to write an ADV7511 register over I2C with the >>> block number, wait for an interrupt, read a status register to check >>> whether EDID data is available or whether an error occurred, and then >>> read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs >>> to be repeated for every block. I thus can't use drm_get_edid() directly. >> >> Sounds familiar. See the special ddc-over-sdvo i2c bus we register in >> intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit >> of boilerplate, but in the end just amounts to 3 small functions and one >> tiny vtable to wire it all up cleanly. > > That's what I would have done as well if I had a device-specific I2C adapter > connected to the DDC bus, but in this case the interface exposed by the > ADV7511 to the SoC over I2C consists of higher level device-specific I2C > commands to read EDID data. There is no low-level I2C read/write primitives > available. I would thus need to expose a fake adapter that would receive I2C > commands, parse them to detect an EDID block read, retrieve the EDID data and > return them from the fake read. That doesn't make much sense to me. The intel sdvo looks just like a simple I2C mux which will just pass-through messages from the master to the EDID EEPROM. The ADV7511 is unfortunately a bit different. You tell it to fetch the EDID information, then it will do some magic and then you can read the EDID back. Abstracting this as a this as a I2C controller will, while possible, result in a fair amount of boiler plate code that will not look particularly pretty. - Lars
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 --- Comment #5 from Daniel Scharrer --- GPU is a Radeon HD 7950 -- 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/20141124/ba377632/attachment.html>
[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Sun, Nov 23, 2014 at 12:26 AM, Javier Martinez Canillas wrote: > Hello Vivek > > On Wed, Nov 19, 2014 at 1:03 PM, Vivek Gautam > wrote: >>> >>> Tested-by: Javier Martinez Canillas >> >> Thanks for testing. >> > > You are welcome > >>> >>> Kukjin, >> >> Sorry for not adding Kukjin to the list and thereby for the delay >> about this patch. >> > > No worries but I'm not sure if Kukjin is aware of this patch. I see he > has been applying other patches but didn't pick $subject. Right, > > Maybe you can resend it to Kukjin just to be sure he will have it in > his mailbox? Posted a RESEND version of this patch. Thanks again for noticing. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 --- Comment #4 from Daniel Scharrer --- Created attachment 109946 --> https://bugs.freedesktop.org/attachment.cgi?id=109946&action=edit Deadfall Adventures menu screen I have also noticed similar black squares in the menu screen of Deadfall Adventures. In that case, changing the texture quality to the lowest setting gets rid of them. Changing all other video settings from highest to lowest reduces the size of the squares from ~104² pixels to 50² pixels. I guess the root cause might just be single NaN/negative fragments that then get propagated by a subsequent screen-space filter into a whole square? Neither game has any VGPR register spilling warnings in their console output so it's not that. Oh, and this is all with Mesa 10.5.0-devel (git-fecae46), but I remember also seeing this with older versions. -- 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/20141124/f0ae4688/attachment.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 --- Comment #3 from Daniel Scharrer --- Created attachment 109945 --> https://bugs.freedesktop.org/attachment.cgi?id=109945&action=edit Sanctum 2 (map Trainstation) with lowest texture quality setting -- 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/20141124/1d98c2a8/attachment-0001.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 --- Comment #2 from Daniel Scharrer --- Created attachment 109944 --> https://bugs.freedesktop.org/attachment.cgi?id=109944&action=edit Sanctum 2 (map Trainstation) with highest texture quality setting -- 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/20141124/968aa831/attachment.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 Daniel Scharrer changed: What|Removed |Added Attachment #109943|0 |1 is obsolete|| -- 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/20141124/f3d70e44/attachment.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 --- Comment #1 from Daniel Scharrer --- (I fail at bugzilla today :/) On some maps in Sanctum 2 I'm getting black squares in some spots. The squares always seem to be the same screen-space size (120Ã120 pixels, some are wider/taller but that could just be overlapping squares), but are centered around fixed positions in the game world and not aligned to a screen-space grid. Moving the camera or character can cause some of them to disappear/reappear. The squares don't just cover the world geometry, but also the user interface including the hud and menu, and even loading screens. This happens with and without R600_DEBUG=nohyperz. It does not happen with fglrx 14.9. It doesn't happen on all maps, but for those affected (e.g. Trainstation) it is 100% reproducible. Lowering texture quality in the game's options reduces the number of black squares. For the screenshots I had all other settings at their lowest value (except bloom turned on as that is required for the game to render correctly, even on other drivers). I have tried to create an apitrace showing the problem but glretrace crashes inside glDrawRangeElements() shortly before getting to the buggy part when replaying with either radeonsi or fglrx. I can still provide it if anyone is interested, but it's probably not appropriate to link here. -- 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/20141124/ea39ef49/attachment.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 Bug ID: 86663 Summary: [radeonsi] Black squares in Sanctum 2 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: daniel at constexpr.org Created attachment 109943 --> https://bugs.freedesktop.org/attachment.cgi?id=109943&action=edit Sanctum 2 (map Trainstation) with highest texture quality setting -- 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/20141124/1b7e6751/attachment.html>
[PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
Hi Andy, On 24/11/14 14:17, Andy Yan wrote: > Hi ZubairLK, Russel King, Greg Kroah-Hartman , Philipp Zabel and Daniel: >Do you have any further opinions or suggestions about the > the current patch set? I have reviewed the patches as much as I could. They look good to me. But I don't know the inner details of DRM to be able to comment further. Please do cc me in further patches. Also, my mail client makes these patches look like the new series gets cascaded in the older patch 8 series. It could be just my thunderbird. But please start a new thread when you send a new series. Thank-you ZubairLK > On 2014å¹´11æ17æ¥ 18:53, Andy Yan wrote: >> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) >> use the interface compatible Designware HDMI IP, but they also have some >> lightly differences, such as phy pll configuration, register width(imx hdmi >> register is one byte, but rk3288 is 4 bytes width and can only be accessed >> by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0 >> support.
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote: > On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote: > > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > > > on vlv, if ipvr is installed, it need be manually unloaded before > > > > i915, otherwise user might run into use-after-free issue. > > > > > > Huh? That doesn't sound right. What exactly is it that's going wrong? > > > You should never have to do this. If you do you're almost certainly > > > doing something wrong in the kernel module. > > > > It's the hilarity called platform devices. Removing them is somewhat racy, > > so doing that upfront makes the entire thing a bit safer. The use after > > free is on the text, since grabbing a module refcount for the platform > > device doesn't work (it would pin the module forever). > > I don't understand what the issue is here. I've used platform devices > quite extensively on ARM and I've never encountered a situation where > they were insufficient (or racy for that matter). > > If I understand correctly what this commit tries to achieve, then it > unloads one module before another module that it depends on so that the > dependency can be removed subsequently without causing a crash. That > sounds really brittle to me. How are you going to document this for > users so that they don't accidentally go and unload the i915 module and > crash their system? Module unloading taints your kernel and isn't an end-user supported feature. That simple ;-) Also afaik the problem is that you actually can't unload i915 until you've unloaded the subordinate driver, since i915 registering the platform driver prevents unload. Or at least that was my understanding, I didn't test this myself. I just asked whether the unload script still works and apparently it breaks. I guess what's different with ARM is that DT creates all the platform devices, and not modules themselves? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL FOR v3.19] R-Car DU changes
On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: > > - the interface looks rather backwards: Either this still does i2c reads, > > and then you'd just need a i2c-over-whatever adapter to make it work. Or > > you have other magic means to optain an edid block, in which case just > > do that and then feed the edid drm_add_edid_modes. > > I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls > the > DDC bus, and exposes EDID data over I2C using vendor commands. To read an > EDID > block I have to write an ADV7511 register over I2C with the block number, > wait > for an interrupt, read a status register to check whether EDID data is > available or whether an error occurred, and then read EDID data from the > ADV7511 over I2C in 64-bytes chunks. This needs to be repeated for every > block. I thus can't use drm_get_edid() directly. Sounds familiar. See the special ddc-over-sdvo i2c bus we register in intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit of boilerplate, but in the end just amounts to 3 small functions and one tiny vtable to wire it all up cleanly. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
Hello Vivek, Thierry,
On 11/24/2014 12:29 PM, Vivek Gautam wrote:
>> Yes. Back at the time a decision was made that device trees need to be
>> stable ABI because eventually they'd be shipped with the device rather
>> than the distribution. As such it may not at all be possible to update
>> them (they could be in some sort of ROM).
>>
>> For that reason new kernels need to keep working with old DTBs unless an
>> argument can be made that would justify breaking things. I don't think I
>> have ever seen anyone win such an argument.
Although uncommon, there are cases when breaking a DT backward compatibility
could make sense IMHO. For example the DT binding for the SPI controller
found on Samsung SoCs (s3c64xx) used a custom binding to specify the chip
select (CS) line. Later the binding was changed in mainline breaking backward
compatibility and the breakage was not noticed in a year even when the change
not only broke backward compatibility but also was wrong.
So the options were to a) keep the buggy DT which also broke backward compact,
b) revert to the old binding breaking any DTS that were added the last year,
c) break backward compatibility again but take the opportunity to fix the
binding for good by dropping device specific bindings and use standard ones.
At the end it was decided that c) was the least bad option and was made in
commit 306972c ("spi: s3c64xx: use the generic SPI "cs-gpios" property").
>> One of the rare exceptions
>> that I know of is if you can prove that a given hardware block has never
>> been used in an upstream kernel, then changing the DTB in backwards-
>> incompatible ways would be okay because you wouldn't be breaking things
>> for existing users.
>
> I am pretty sure about the Chrome devices (which have not been
> upgraded to any kernel after
> 3.8).
> Probably Javier may have better knowledge.
>
Correct. The Exynos based Chromebooks are using a 3.8 kernel and the FDT
shipped can't be used with a mainline kernel since it used out-of-tree
drivers whose DT bindings were changed during review to upstream inclusion.
Also, the stock boot-loader loads a FIT image which has a kernel and FDT
bundled in the same image so in that case the FDT has to be shipped with
the Linux kernel anyways.
> Javier, is there any other device using upstream kernel post 3.12 (any
> arndale octa based) ?
>
Sorry, I don't know if there are other Exynos devices using a more recent
kernel but AFAICT the DT binding for the Exynos Display Port was changed
recently (v3.17) in a non-backward compatible way with commit 5f1dcd8
("drm/exynos: dp: Modify driver to support drm_panel"). So anyone using a
more recent kernel will have to update the FDT to have display working.
Also display does not work for many Exynos5 devices that have an eDP to LVDS
bridge chip for example so I think is safe to assume that anything related
to the Exynos DP (like the DP PHY) would still not have a stable DT binding.
Best regards,
Javier
[PATCH] drm/locking: Allow NULL crtc in drm_modeset_legacy_acquire_ctx
OL(drm_modeset_lock_crtc);
> /**
> * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
> * @crtc: drm crtc
> + * @dev: device
> *
> * Legacy ioctl operations like cursor updates or page flips only have
> per-crtc
> * locking, and store the acquire ctx in the corresponding crtc. All other
> * legacy operations take all locks and use a global acquire context. This
> * function grabs the right one.
> + *
> + * Note that either @crtc or @dev can be NULL, but not both.
> */
> struct drm_modeset_acquire_ctx *
> -drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
> +drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc,
> + struct drm_device *dev)
> {
> - if (crtc->acquire_ctx)
> + if (crtc && crtc->acquire_ctx)
> return crtc->acquire_ctx;
>
> - WARN_ON(!crtc->dev->mode_config.acquire_ctx);
> + WARN_ON(!dev->mode_config.acquire_ctx);
>
> - return crtc->dev->mode_config.acquire_ctx;
> + return dev->mode_config.acquire_ctx;
> }
> EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
>
> diff --git a/include/drm/drm_modeset_lock.h
> b/include/drm/drm_modeset_lock.h
> index 28931a23d96c..cdbfd822e52f 100644
> --- a/include/drm/drm_modeset_lock.h
> +++ b/include/drm/drm_modeset_lock.h
> @@ -135,7 +135,8 @@ void drm_modeset_lock_crtc(struct drm_crtc *crtc);
> void drm_modeset_unlock_crtc(struct drm_crtc *crtc);
> void drm_warn_on_modeset_not_all_locked(struct drm_device *dev);
> struct drm_modeset_acquire_ctx *
> -drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc);
> +drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc,
> + struct drm_device *dev);
>
> int drm_modeset_lock_all_crtcs(struct drm_device *dev,
> struct drm_modeset_acquire_ctx *ctx);
> --
> 2.1.1
>
>
--
Jasper
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/f29d00b9/attachment.html>
[PATCH] drm/atomic-helper: Skip vblank waits for unchanged fbs
With the oops fix:
Reviewed-by: Jasper St. Pierre
Tested-by: Jasper St. Pierre
On Mon, Nov 24, 2014 at 12:42 PM, Daniel Vetter
wrote:
> Especially with legacy cursor ioctls existing userspace assumes that
> you can pile up lots of updates in one go. The super-proper way to
> support this would be a special commit mode which overwrites the last
> update. But getting there will be quite a bit of work.
>
> Meanwhile do what pretty much all the drivers have done for the plane
> update functions: Simply skip the vblank wait for the buffer cleanup
> if the buffer is the same. Since the universal cursor plane code will
> not recreate framebuffers needlessly this allows us to not slow down
> legacy pageflip events while someone moves the cursor around.
>
> v2: Drop the async plane update hunk from a previous attempt at this
> issue.
>
> v3: Fix up kerneldoc.
>
> v4: Don't oops so badly. Reported by Jasper.
>
> Cc: Rob Clark
> Cc: "Jasper St. Pierre"
> Reviewed-by: Rob Clark
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 34
> +-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index af37f1edd3ed..0d32039d072f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -748,6 +748,33 @@ static void wait_for_fences(struct drm_device *dev,
> }
> }
>
> +static bool framebuffer_changed(struct drm_device *dev,
> + struct drm_atomic_state *old_state,
> + struct drm_crtc *crtc)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *old_plane_state;
> + int nplanes = old_state->dev->mode_config.num_total_plane;
> + int i;
> +
> + for (i = 0; i < nplanes; i++) {
> + plane = old_state->planes[i];
> + old_plane_state = old_state->plane_states[i];
> +
> + if (!plane)
> + continue;
> +
> + if (plane->state->crtc != crtc &&
> + old_plane_state->crtc != crtc)
> + continue;
> +
> + if (plane->state->fb != old_plane_state->fb)
> + return true;
> + }
> +
> + return false;
> +}
> +
> /**
> * drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
> * @dev: DRM device
> @@ -755,7 +782,9 @@ static void wait_for_fences(struct drm_device *dev,
> *
> * Helper to, after atomic commit, wait for vblanks on all effected
> * crtcs (ie. before cleaning up old framebuffers using
> - * drm_atomic_helper_cleanup_planes())
> + * drm_atomic_helper_cleanup_planes()). It will only wait on crtcs where
> the
> + * framebuffers have actually changed to optimize for the legacy cursor
> and
> + * plane update use-case.
> */
> void
> drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
> @@ -781,6 +810,9 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> if (!crtc->state->enable)
> continue;
>
> + if (!framebuffer_changed(dev, old_state, crtc))
> + continue;
> +
> ret = drm_crtc_vblank_get(crtc);
> if (ret != 0)
> continue;
> --
> 2.1.1
>
>
--
Jasper
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/a87f5551/attachment.html>
[PATCH] gpu/drm/drm_sysfs.c: Export drm_sysfs_connector_add and drm_sysfs_connector_remove
Building the adi_axi_hdmi driver as a module failed: ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/adi_axi_hdmi/adi_axi_hdmi.ko] undefined! Mark drm_sysfs_connector_remove for export to fix this. Also mark drm_sysfs_connector_add for export, for symetry and because at least one other module uses it (xylon_connector.c). Signed-off-by: Mike Looijmans --- drivers/gpu/drm/drm_sysfs.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index ab1a5f6..d0296cc 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -438,6 +438,7 @@ err_out_files: out: return ret; } +EXPORT_SYMBOL(drm_sysfs_connector_add); /** * drm_sysfs_connector_remove - remove an connector device from sysfs @@ -467,6 +468,7 @@ void drm_sysfs_connector_remove(struct drm_connector *connector) device_unregister(connector->kdev); connector->kdev = NULL; } +EXPORT_SYMBOL(drm_sysfs_connector_remove); /** * drm_sysfs_hotplug_event - generate a DRM uevent -- 1.7.9.5
[Bug 85320] [RV630] and RS880 GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #25 from Daniele --- Update: there are still some videos (taken with my smartphone) causing the GPU to hang as it did before, both with VLC and mpv, but I confirm that I can now play youtube with hw acceleration. -- 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/20141124/8e782f92/attachment.html>
[Bug 85320] [RV630] and RS880 GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #24 from Daniele --- Ok I've just learnt something interesting: suspending kwin desktop effects make everything work flawlessy here. I tried mpv, vlc and even the flash plugin and hw accel works well; I tried also seeking in the video without any problem. Now we should find out if the problems is only there with kwin or even with other desktop environments. -- 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/20141124/ec94e126/attachment.html>
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 04:17:18PM +0530, Vivek Gautam wrote:
> Hi,
>
>
> On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
> wrote:
> > On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
> >> DP PHY now require pmu-system-controller to handle PMU register
> >> to control PHY's power isolation. Adding the same to dp-phy
> >> node.
> >>
> >> Signed-off-by: Vivek Gautam
> >> Reviewed-by: Jingoo Han
> >> Tested-by: Javier Martinez Canillas
> >> Cc: Kukjin Kim
> >> ---
> >> arch/arm/boot/dts/exynos5250.dtsi |2 +-
> >> arch/arm/boot/dts/exynos5420.dtsi |4 ++--
> >> 2 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> >> b/arch/arm/boot/dts/exynos5250.dtsi
> >> index 0a588b4..bebd099 100644
> >> --- a/arch/arm/boot/dts/exynos5250.dtsi
> >> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> >> @@ -732,7 +732,7 @@
> >>
> >> dp_phy: video-phy at 10040720 {
> >> compatible = "samsung,exynos5250-dp-video-phy";
> >> - reg = <0x10040720 4>;
> >> + samsung,pmu-syscon = <&pmu_system_controller>;
> >> #phy-cells = <0>;
> >> };
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> >> b/arch/arm/boot/dts/exynos5420.dtsi
> >> index 8617a03..1353a09 100644
> >> --- a/arch/arm/boot/dts/exynos5420.dtsi
> >> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> >> @@ -503,8 +503,8 @@
> >> };
> >>
> >> dp_phy: video-phy at 10040728 {
> >> - compatible = "samsung,exynos5250-dp-video-phy";
> >> - reg = <0x10040728 4>;
> >> + compatible = "samsung,exynos5420-dp-video-phy";
> >> + samsung,pmu-syscon = <&pmu_system_controller>;
> >> #phy-cells = <0>;
> >> };
> >>
> >
> > It seems like these nodes have been in the Linux tree since 3.12 and
> > 3.17, respectively and these changes break backwards-compatibility. Has
> > anyone thought about the possible consequences?
>
> Sorry for my ignorance, but i have a doubt.
> If the bindings and device node both are being changed in the same kernel
> version (as fixes),
> so that the stable will have both; then the only scenerio of backward
> compatibility comes when kernel is upgraded but not dtbs.
Correct.
> Does such upgradation makes sense for distros ?
Yes. Back at the time a decision was made that device trees need to be
stable ABI because eventually they'd be shipped with the device rather
than the distribution. As such it may not at all be possible to update
them (they could be in some sort of ROM).
For that reason new kernels need to keep working with old DTBs unless an
argument can be made that would justify breaking things. I don't think I
have ever seen anyone win such an argument. One of the rare exceptions
that I know of is if you can prove that a given hardware block has never
been used in an upstream kernel, then changing the DTB in backwards-
incompatible ways would be okay because you wouldn't be breaking things
for existing users.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/2b867f5a/attachment.sig>
[PATCH 1/9] drm: add helper to get crtc timings (v4)
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
v4 (by Matt):
- Drop stereo doubling function again; add 'stereo only' flag
to drm_mode_set_crtcinfo() instead (Ville)
Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
drivers/gpu/drm/drm_modes.c | 24 ++--
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
include/drm/drm_modes.h | 3 +++
5 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 589a921..f06f1b4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2499,6 +2499,27 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
EXPORT_SYMBOL(drm_mode_set_config_internal);
/**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted;
+
+ drm_mode_copy(&adjusted, mode);
+ drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE_ONLY);
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
* @crtc: CRTC that framebuffer will be displayed on
@@ -2515,16 +2536,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
{
int hdisplay, vdisplay;
- hdisplay = mode->hdisplay;
- vdisplay = mode->vdisplay;
-
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ drm_crtc_get_hv_timing(mode, &hdisplay, &vdisplay);
if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..fd5479b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -765,18 +765,22 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p,
int adjust_flags)
}
}
- if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
- p->crtc_vdisplay *= 2;
- p->crtc_vsync_start *= 2;
- p->crtc_vsync_end *= 2;
- p->crtc_vtotal *= 2;
+ if (!(adjust_flags & CRTC_NO_DBLSCAN)) {
+ if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
+ p->crtc_vdisplay *= 2;
+ p->crtc_vsync_start *= 2;
+ p->crtc_vsync_end *= 2;
+ p->crtc_vtotal *= 2;
+ }
}
- if (p->vscan > 1) {
- p->crtc_vdisplay *= p->vscan;
- p->crtc_vsync_start *= p->vscan;
- p->crtc_vsync_end *= p->vscan;
- p->crtc_vtotal *= p->vscan;
+ if (!(adjust_flags & CRTC_NO_VSCAN)) {
+ if (p->vscan > 1) {
+ p->crtc_vdisplay *= p->vscan;
+ p->crtc_vsync_start *= p->vscan;
+ p->crtc_vsync_end *= p->vscan;
+ p->crtc_vtotal *= p->vscan;
+ }
}
if (adjust_flags & CRTC_STEREO_DOUBLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a3d2a44..b87aeab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10205,9 +10205,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(&pipe_config->requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
- pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(&pipe_config->requested_mode,
+ &pipe_config->pipe_src_w,
+ &pipe_config->pipe_src_h);
encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff
[GIT PULL FOR v3.19] R-Car DU changes
Hi Daniel, Thank you for the review. On Friday 07 November 2014 10:19:14 Daniel Vetter wrote: > On Fri, Nov 07, 2014 at 08:25:32AM +0200, Laurent Pinchart wrote: > > Hi Dave, > > > > Here's a pull request that adds HDMI support to the R-Car DU driver, > > including a new slave encoder driver for the adv7511. > > > > The branch is based on a merge of drm-next and Simon's > > tags/renesas-dt-du-for- v3.19 available at > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git, for which > > a pull request has been submitted for v3.19 to the ARM SoC maintainers. > > > > I'm leaving now for two weeks of holidays and would like to avoid missing > > the merge window. Simon, could you please confirm that > > tags/renesas-dt-du-for- v3.19 is stable and ack this pull request (and > > possibly ping Dave on my behalf ;-)) ? > > > > The following changes since commit 19de43d4dea8712b3574d72d3d8aa16cd17e7fed: > > Merge tag 'tags/renesas-dt-du-for-v3.19' into drm/next/adv7511-base > > > > (2014-11-07 08:06:16 +0200) > > > > are available in the git repository at: > > git://linuxtv.org/pinchartl/fbdev.git > > > > for you to fetch changes up to cc47927ca851110d2c387a7d9fd7086112abb92e: > > drm: Add adv7511 encoder driver (2014-11-07 08:19:06 +0200) > > > > > > > > Lars-Peter Clausen (2): > > drm: Decouple EDID parsing from I2C adapter > > So somehow the pull request seems to lack the branch so I can't actually > take a lookc. git request-pull is playing trick with me :-/ I'll try to fix that. The branch is available at git://linuxtv.org/pinchartl/fbdev.git drm/next/du (http://git.linuxtv.org/cgit.cgi/pinchartl/fbdev.git/commit/?h=drm/next/du) > But this patch here seems to lack review: > - kerneldoc for the newly exported function is missing I'll fix that. > - the interface looks rather backwards: Either this still does i2c reads, > and then you'd just need a i2c-over-whatever adapter to make it work. Or > you have other magic means to optain an edid block, in which case just > do that and then feed the edid drm_add_edid_modes. I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls the DDC bus, and exposes EDID data over I2C using vendor commands. To read an EDID block I have to write an ADV7511 register over I2C with the block number, wait for an interrupt, read a status register to check whether EDID data is available or whether an error occurred, and then read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs to be repeated for every block. I thus can't use drm_get_edid() directly. > Nack from me in this form. And can we try not to be quite this sneaky with > drm core patches going in through driver trees, please? > > Thanks, Daniel > > > drm: Add adv7511 encoder driver > > > > Laurent Pinchart (6): > > drm: rcar-du: Remove platform data support > > drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init() > > drm: rcar-du: Replace direct DRM encoder access with cast macro > > drm: rcar-du: Replace drm_encoder with drm_slave_encoder > > drm: rcar-du: Add HDMI encoder and connector support > > video: Add ADV751[13] DT bindings documentation > > > > Documentation/devicetree/bindings/video/adi,adv7511.txt | 88 ++ > > drivers/gpu/drm/drm_edid.c | 27 +- > > drivers/gpu/drm/i2c/Kconfig |6 + > > drivers/gpu/drm/i2c/Makefile|2 + > > drivers/gpu/drm/i2c/adv7511.c | 1010 ++ > > drivers/gpu/drm/i2c/adv7511.h | 289 +++ > > drivers/gpu/drm/rcar-du/Kconfig | 11 +- > > drivers/gpu/drm/rcar-du/Makefile|2 + > > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.h |2 - > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 45 +- > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 23 +- > > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++ > > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 + > > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 > > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35 + > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 53 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 31 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |2 - > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |1 - > > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c|5 +- > > include/drm/drm_edid.h |5 + > > include/linux/platform_data/rcar-du.h
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
>
> Signed-off-by: Vivek Gautam
> Reviewed-by: Jingoo Han
> Tested-by: Javier Martinez Canillas
> Cc: Kukjin Kim
> ---
> arch/arm/boot/dts/exynos5250.dtsi |2 +-
> arch/arm/boot/dts/exynos5420.dtsi |4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 0a588b4..bebd099 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
>
> dp_phy: video-phy at 10040720 {
> compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040720 4>;
> + samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8617a03..1353a09 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
> };
>
> dp_phy: video-phy at 10040728 {
> - compatible = "samsung,exynos5250-dp-video-phy";
> - reg = <0x10040728 4>;
> + compatible = "samsung,exynos5420-dp-video-phy";
> + samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
It seems like these nodes have been in the Linux tree since 3.12 and
3.17, respectively and these changes break backwards-compatibility. Has
anyone thought about the possible consequences?
Although, looking more closely it seems like this isn't the first time
that backwards-compatibility was broken in these files, so perhaps
nobody cares...
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/979d6675/attachment-0001.sig>
[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam
Reviewed-by: Jingoo Han
Tested-by: Javier Martinez Canillas
Cc: Kukjin Kim
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
dp_phy: video-phy at 10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
- reg = <0x10040720 4>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
dp_phy: video-phy at 10040728 {
- compatible = "samsung,exynos5250-dp-video-phy";
- reg = <0x10040728 4>;
+ compatible = "samsung,exynos5420-dp-video-phy";
+ samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
--
1.7.10.4
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Ajay,
On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote:
> On 11/21/2014 06:32 PM, Ajay kumar wrote:
>> Hi,
>>
>> I have rebased my bridge series on top of linux-next.
>>
>> This is my git log:
>> 4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for
>> display panel support""
>> 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge
>> and panel using videoport and endpoints
>> aee649c ARM: dts: snow: represent the connection between bridge and
>> panel using videoport and endpoints
>> 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
>> 581257f Documentation: bridge: Add documentation for ps8622 DT properties
>> 178e8b9 Documentation: devicetree: Add vendor prefix for parade
>> 0ceea75 Documentation: drm: bridge: move to video/bridge
>> f143e2e drm/bridge: ptn3460: use gpiod interface
>> 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach
>> 32ac563 drm/bridge: ptn3460: support drm_panel
>> 91c6c30 drm/exynos: dp: support drm_bridge
>> 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model
>> 602f343 drm/bridge: make bridge registration independent of drm flow
>> 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
>> 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
>> 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> 28655d1 drm/exynos: Move platform drivers registration to module init
>> ed6778a Add linux-next specific files for 20141121
>>
>> I have attached the rebased patches as well.
>> I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
>> Display is totally fine with exynos_defconfig (booting is fine even
>> with CONFIG_SND_SOC_SNOW=y)
>>
>
> Thanks for forward porting your patches to linux-next. Unfortunately I
> won't have time to test them until Monday but I wonder why you didn't
> have the boot issues that we have with next-20141121.
>
I tested your ToT patches on top of next-20141121, this is my git log:
93fe3d7 Revert "Revert "ARM: exynos_defconfig: Enable options for display panel
support""
552f74e ARM: dts: peach-pit: represent the connection between bridge and panel
using videoport and endpoints
dbbc293 ARM: dts: snow: represent the connection between bridge and panel using
videoport and endpoints
d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
f29a649 Documentation: bridge: Add documentation for ps8622 DT properties
6ade887 Documentation: devicetree: Add vendor prefix for parade
d81c42d Documentation: drm: bridge: move to video/bridge
50b9828 drm/bridge: ptn3460: use gpiod interface
1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach
f3cf063 drm/bridge: ptn3460: support drm_panel
cab682b drm/exynos: dp: support drm_bridge
6e78916 drm/bridge: ptn3460: Convert to i2c driver model
93f4b5f drm/bridge: make bridge registration independent of drm flow
81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
eb6996e drm/bridge: ptn3460: Few trivial cleanups
c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
51b2c75 drm/exynos: Move platform drivers registration to module init
ed6778a Add linux-next specific files for 20141121
> I found that the commit ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add
> runtime Power Management support v12") had to be reverted in order to
> boot linux-next.
>
Display works but I needed to revert the mentioned commit, otherwise
the boot hangs as reported before. I'm using exynos_defconfig and this
kernel command line:
console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
Best regards,
Javier
[PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge
2014-11-22 Inki Dae :
> 2014-11-21 8:54 GMT+09:00 Gustavo Padovan :
> > From: Gustavo Padovan
> >
> > DP was leaked everytime function returns EPROBE_DEFER, free it before
> > returning.
>
> It seems that you misunderstood devm_* api.
Yeah, I though it would only free memory at unload of the module but it also
free it when the probe fails.
>
> Thanks,
> Inki Dae
>
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > b/drivers/gpu/drm/exynos/exynos_dp_core.c
> > index 85762cf..6fd4a46 100644
> > --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> > @@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device
> > *pdev)
> > if (panel_node) {
> > dp->panel = of_drm_find_panel(panel_node);
> > of_node_put(panel_node);
> > - if (!dp->panel)
> > - return -EPROBE_DEFER;
> > + if (!dp->panel) {
> > + ret = -EPROBE_DEFER;
> > + goto free_dp;
> > + }
> > }
> >
> > endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> > @@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device
> > *pdev)
> > if (bridge_node) {
> > dp->bridge = of_drm_find_bridge(bridge_node);
> > of_node_put(bridge_node);
> > - if (!dp->bridge)
> > - return -EPROBE_DEFER;
> > - } else
> > - return -EPROBE_DEFER;
> > + if (!dp->bridge) {
> > + ret = -EPROBE_DEFER;
> > + goto free_dp;
> > + }
> > + } else {
> > + ret = -EPROBE_DEFER;
> > + goto free_dp;
> > + }
> > }
> >
> > exynos_dp_display.ctx = dp;
> > @@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device
> > *pdev)
> > exynos_drm_component_del(&pdev->dev,
> >
> > EXYNOS_DEVICE_TYPE_CONNECTOR);
> >
> > +free_dp:
> > + devm_kfree(dev, dp);
> > +
> > return ret;
> > }
> >
> > --
> > 1.9.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Gustavo
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote: > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > > on vlv, if ipvr is installed, it need be manually unloaded before > > > i915, otherwise user might run into use-after-free issue. > > > > Huh? That doesn't sound right. What exactly is it that's going wrong? > > You should never have to do this. If you do you're almost certainly > > doing something wrong in the kernel module. > > It's the hilarity called platform devices. Removing them is somewhat racy, > so doing that upfront makes the entire thing a bit safer. The use after > free is on the text, since grabbing a module refcount for the platform > device doesn't work (it would pin the module forever). I don't understand what the issue is here. I've used platform devices quite extensively on ARM and I've never encountered a situation where they were insufficient (or racy for that matter). If I understand correctly what this commit tries to achieve, then it unloads one module before another module that it depends on so that the dependency can be removed subsequently without causing a crash. That sounds really brittle to me. How are you going to document this for users so that they don't accidentally go and unload the i915 module and crash their system? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141124/f993c9fc/attachment.sig>
[PATCH 1/3] drm/edid: new drm_edid_block_checksum helper function V2
On Sun, 23 Nov 2014, Stefan Brüns wrote:
> The function will also be used by a later patch, so factor it out.
>
> V2: make raw_edid const, define/declare before first use
>
> Signed-off-by: Stefan Brüns
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a71ed93..f6c4a1d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1022,6 +1022,16 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
> length)
> return true;
> }
>
> +static u8 drm_edid_block_checksum(const u8 *raw_edid)
> +{
> + int i;
> + u8 csum = 0;
> + for (i = 0; i < EDID_LENGTH; i++)
> + csum += raw_edid[i];
> +
> + return csum;
> +}
> +
> /**
> * drm_edid_block_valid - Sanity check the EDID block (base or extension)
> * @raw_edid: pointer to raw EDID block
> @@ -1036,7 +1046,6 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
> length)
> bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
> {
> int i;
> - u8 csum = 0;
I meant it's no longer necessary to initialize this to 0. You still need
the variable. Please try compiling the code you send and you'll see
why. ;)
BR,
Jani.
> struct edid *edid = (struct edid *)raw_edid;
>
> if (WARN_ON(!raw_edid))
> @@ -1056,9 +1065,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid)
> }
> }
>
> - for (i = 0; i < EDID_LENGTH; i++)
> - csum += raw_edid[i];
> - if (csum) {
> + if (drm_edid_block_checksum(raw_edid)) {
> if (print_bad_edid) {
> DRM_ERROR("EDID checksum is invalid, remainder is
> %d\n", csum);
> }
> --
> 2.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] gpu/drm/drm_sysfs.c: Export drm_sysfs_connector_add and drm_sysfs_connector_remove
On Mon, Nov 24, 2014 at 7:25 AM, Mike Looijmans
wrote:
> Building the adi_axi_hdmi driver as a module failed:
> ERROR: "drm_sysfs_connector_remove"
> [drivers/gpu/drm/adi_axi_hdmi/adi_axi_hdmi.ko] undefined!
>
> Mark drm_sysfs_connector_remove for export to fix this. Also mark
> drm_sysfs_connector_add for export, for symetry and because at least
> one other module uses it (xylon_connector.c).
no.. you should be using drm_connector_{register,unregister}() now,
and not calling the drm_sysfs_connector_{add,remove}() fxns directly..
BR,
-R
> Signed-off-by: Mike Looijmans
> ---
> drivers/gpu/drm/drm_sysfs.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ab1a5f6..d0296cc 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -438,6 +438,7 @@ err_out_files:
> out:
> return ret;
> }
> +EXPORT_SYMBOL(drm_sysfs_connector_add);
>
> /**
> * drm_sysfs_connector_remove - remove an connector device from sysfs
> @@ -467,6 +468,7 @@ void drm_sysfs_connector_remove(struct drm_connector
> *connector)
> device_unregister(connector->kdev);
> connector->kdev = NULL;
> }
> +EXPORT_SYMBOL(drm_sysfs_connector_remove);
>
> /**
> * drm_sysfs_hotplug_event - generate a DRM uevent
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
