[PATCH] drm/gm204/i2c: fix semicolon.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/i2c/padgm204.c:74:26-27: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu --- padgm204.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/padgm204.c +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/padgm204.c @@ -71,7 +71,7 @@ gm204_i2c_pad_ctor(struct nouveau_object if (ret) return ret; - pad->addr = index * 0x50;; + pad->addr = index * 0x50; return 0; }
[PATCH] drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86
On 1 December 2014 at 14:02, Alex Deucher wrote: > On Thu, Nov 27, 2014 at 4:00 AM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627 >> Signed-off-by: Michel Dänzer > > Applied to my -fixes tree. Btw while I'm okay to merge this as a workaround, I'd really like to know if someone cares enough to fix it. Because there is no reason WC mappings should be broken on 32-bit, and its quite likely they are broken on 64-bit too just more subtly. Dave.
[jbarnes:upstream-sync-points 2/2] drivers/gpu/drm/i915/i915_sync.c:43:12: sparse: symbol 'fence_lock' was not declared. Should it be static?
tree: git://people.freedesktop.org/~jbarnes/linux upstream-sync-points head: 97b242f63adaf11c3edf16b0282243cc4274eac8 commit: 97b242f63adaf11c3edf16b0282243cc4274eac8 [2/2] drm/i915: Android sync points for i915 v3 reproduce: # apt-get install sparse git checkout 97b242f63adaf11c3edf16b0282243cc4274eac8 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/i915_sync.c:43:12: sparse: symbol 'fence_lock' was not >> declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
[PATCH jbarnes] drm/i915: fence_lock can be static
drivers/gpu/drm/i915/i915_sync.c:43:12: sparse: symbol 'fence_lock' was not declared. Should it be static? Signed-off-by: Fengguang Wu --- i915_sync.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_sync.c b/drivers/gpu/drm/i915/i915_sync.c index 069c069..b614eea 100644 --- a/drivers/gpu/drm/i915/i915_sync.c +++ b/drivers/gpu/drm/i915/i915_sync.c @@ -40,7 +40,7 @@ #include "../../../staging/android/sync.h" /* Nothing really to protect here... */ -spinlock_t fence_lock; +static spinlock_t fence_lock; /* * i915 fences on sync timelines
[PATCH 1/3] drm/vmwgfx: Don't use memory accounting for kernel-side fence objects
On 2 December 2014 at 21:59, Thomas Hellstrom wrote: > Kernel side fence objects are used when unbinding resources and may thus be > created as part of a memory reclaim operation. This might trigger recursive > memory reclaims and result in the kernel running out of stack space. > > So a simple way out is to avoid accounting of these fence objects. > In principle this is OK since while user-space can trigger the creation of > such objects, it can't really hold on to them. However, their lifetime is > quite long, so some form of accounting should perhaps be implemented in the > future. > > Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 > with low system memory settings. are these 3 intended for fixes? can you send me a git pull for them soon, so they don't miss Linus release. Dave.
[git pull] drm radeon + nouveau fixes
Hi, so nouveau had a few regression introduced, Ben and Maarten finally tracked down the one that was causing problems on my MacBookPro, also nvidia gave some info on the an engine we were using incorrectly, so disable our use of it, and one regresion with pci hotplug affecting optimus users. radeon has an oops fixs, sync fix, and one workaround to avoid broken functionality on 32-bit x86, this needs better root causing and a better fix, but the bandaid is a lot safer at this point. Dave. The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a: Linux 3.18-rc7 (2014-11-30 16:42:27 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 00d6a9b6be5885ad38234cd171f6fb18a87faa7c: Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-12-03 11:03:24 +1000) Ben Skeggs (1): drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it Christian König (1): drm/radeon: sync all BOs involved in a CS v2 Dave Airlie (3): Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes nouveau: move the hotplug ignore to correct place. Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Ilia Mirkin (1): drm/nouveau/gf116: remove copy1 engine Maarten Lankhorst (1): drm/nouveau: prevent stale fence->channel pointers, and protect with rcu Michel Dänzer (1): drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86 Petr Mladek (1): drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 drivers/gpu/drm/nouveau/core/engine/device/nvc0.c | 1 - drivers/gpu/drm/nouveau/core/engine/fifo/nv04.c | 2 +- drivers/gpu/drm/nouveau/core/engine/fifo/nvc0.c | 4 +- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 92 --- drivers/gpu/drm/nouveau/nouveau_fence.h | 4 +- drivers/gpu/drm/radeon/radeon_cs.c| 17 ++--- drivers/gpu/drm/radeon/radeon_kms.c | 2 + drivers/gpu/drm/radeon/radeon_object.c| 7 ++ 10 files changed, 88 insertions(+), 45 deletions(-)
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit b68362278af9
("drm/i915: More cautious with pch fifo underruns") from the
drm-intel-fixes tree and commit a72e4c9f9a11 ("drm/i915: Use dev_priv
in public intel_fifo_underrun.c functions") from the drm tree.
I fixed it up (I used the drm tree version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141203/74994fc4/attachment.sig>
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in
drivers/gpu/drm/drm_edid.c between commit 18df89fef2d5 ("drm: Decouple
EDID parsing from I2C adapter") from the drm tree and commit
d6885d659037 ("drm/edid: move drm_edid_is_zero to top, make edid
argument const") from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/drm_edid.c
index a7b5a71856a7,2c1d2e49fb6f..
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -1176,34 -1196,8 +1196,26 @@@ drm_do_probe_ddc_edid(void *data, u8 *b
return ret == xfers ? 0 : -1;
}
- static bool drm_edid_is_zero(u8 *in_edid, int length)
- {
- if (memchr_inv(in_edid, 0, length))
- return false;
-
- return true;
- }
-
-static u8 *
-drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
+/**
+ * drm_do_get_edid - get EDID data using a custom EDID block read function
+ * @connector: connector we're probing
+ * @get_edid_block: EDID block read function
+ * @data: private data passed to the block read function
+ *
+ * When the I2C adapter connected to the DDC bus is hidden behind a device
that
+ * exposes a different interface to read EDID blocks this function can be used
+ * to get EDID data using a custom block read function.
+ *
+ * As in the general case the DDC bus is accessible by the kernel at the I2C
+ * level, drivers must make all reasonable efforts to expose it as an I2C
+ * adapter and use drm_get_edid() instead of abusing this function.
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+struct edid *drm_do_get_edid(struct drm_connector *connector,
+ int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
+size_t len),
+ void *data)
{
int i, j = 0, valid_extensions = 0;
u8 *block, *new;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141203/220f5c6b/attachment.sig>
tile property contents
On 3 December 2014 at 10:01, Aaron Plattner wrote: > On 10/13/2014 08:23 PM, Dave Airlie wrote: >> >> Hi, >> >> So I've been hacking on mutter and the gnome pieces for tiling, and >> I've at least fixed mutter locally so maximise windows works and the >> heads are in the right order. >> >> Now I've strung all the pieces together using a single KMS property >> that X.org propogates, and mutter picks up and propagates over dbus as >> well, >> >> Currently I've ascii encoded the property into a blob, >> >> >> >> >> I'm thinking of dropping the version field and just exposing TILE2 >> property if we need it later to add more values, > > > Nifty. Is there a randrproto.txt spec for this planned? > Well for KMS its a kernel property and is documented there, I suppose randrproto should also contain the info. > > What format does this ID need to be in? It looks like monitors are > identified by (vendor id, product id, serial number) tuples in the DisplayID > extension block so it would make sense to just concatenate that into one > giant number as the tileid. Having to centrally manage these (in the > kernel??) seems like overkill. I don't mind, but central management is what we've done, it wasn't a lot of work, you could munge the vendor/product/serial, but maybe DisplayId won't be the only game in town in the future and I'd hate to tie things to it. >> group - unique per group >> flags: bit 0 : single monitor enclosure >> maxhtiles: total number of horiz tiles >> maxvtiles: total number of vert tiles >> h_tile_loc: horiz location of this output in tile group >> v_tile_loc: vert location of this output in tile group >> tile_w: width of this tile >> tile_h: height of this tile. >> >> Now we extract all of these from the DisplayID v1.3 block, and I'm >> wondering if maybe I shouldn't just export the whole DisplayID tiling >> info block instead, it however encodes a few other pieces of >> information, including bezel info, and some flags specifying behaviour >> in some cases. > > > I don't know whether the other flags would be useful, but one important one > is the "native resolution" field. At least one monitor I've seen fails to > work if you drive the normal EDID "preferred" timings on both tiles. I think the last two fields are copied from that, the tile w/h, I can't see any mention of a specific native res flag. Dave.
[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen
https://bugs.freedesktop.org/show_bug.cgi?id=86832 --- Comment #7 from Sylvain BERTRAND --- Got my hands on Alex D. drm-next-3.19, I'm going to try... -- 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/20141203/3e7bf6d6/attachment.html>
[PATCH 1/3] drm/vmwgfx: Don't use memory accounting for kernel-side fence objects
On 12/03/2014 02:06 AM, Dave Airlie wrote: > On 2 December 2014 at 21:59, Thomas Hellstrom > wrote: >> Kernel side fence objects are used when unbinding resources and may thus be >> created as part of a memory reclaim operation. This might trigger recursive >> memory reclaims and result in the kernel running out of stack space. >> >> So a simple way out is to avoid accounting of these fence objects. >> In principle this is OK since while user-space can trigger the creation of >> such objects, it can't really hold on to them. However, their lifetime is >> quite long, so some form of accounting should perhaps be implemented in the >> future. >> >> Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 >> with low system memory settings. > are these 3 intended for fixes? can you send me a git pull for them > soon, so they don't miss Linus release. > > Dave. Hi. Actually, these bugs have been quite long-standing and I feel a bit uncomfortable including the fixes this late in the release cycle. I'd rather wait to 3.19 unless you think otherwise. Thanks, Thomas
[PATCH] drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86
On 03.12.2014 08:28, Dave Airlie wrote: > On 1 December 2014 at 14:02, Alex Deucher wrote: >> On Thu, Nov 27, 2014 at 4:00 AM, Michel Dänzer >> wrote: >>> From: Michel Dänzer >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627 >>> Signed-off-by: Michel Dänzer >> >> Applied to my -fixes tree. > > Btw while I'm okay to merge this as a workaround, I'd really like to know > if someone cares enough to fix it. > > Because there is no reason WC mappings should be broken on 32-bit, > and its quite likely they are broken on 64-bit too just more subtly. It would definitely be nice to get to the bottom of this, but I'm not sure where to dig next. Given that basically the same 64-bit kernel seems to fail when built on a 32-bit host but works fine when built on a 64-bit host, I suspect it might be something from the host toolchain / build environment leaking into the resulting binaries somehow. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
On Wed, 03 Dec 2014, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/intel_display.c between commit b68362278af9
> ("drm/i915: More cautious with pch fifo underruns") from the
> drm-intel-fixes tree and commit a72e4c9f9a11 ("drm/i915: Use dev_priv
> in public intel_fifo_underrun.c functions") from the drm tree.
>
> I fixed it up (I used the drm tree version) and can carry the fix as
> necessary (no action is required).
b68362278af9 removes two lines of code; these should be removed in the
resolved version too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Jani,
On Wed, 03 Dec 2014 10:24:12 +0200 Jani Nikula wrote:
>
> On Wed, 03 Dec 2014, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm tree got a conflict in
> > drivers/gpu/drm/i915/intel_display.c between commit b68362278af9
> > ("drm/i915: More cautious with pch fifo underruns") from the
> > drm-intel-fixes tree and commit a72e4c9f9a11 ("drm/i915: Use dev_priv
> > in public intel_fifo_underrun.c functions") from the drm tree.
> >
> > I fixed it up (I used the drm tree version) and can carry the fix as
> > necessary (no action is required).
>
> b68362278af9 removes two lines of code; these should be removed in the
> resolved version too.
Thanks for the correction. I will do that tomorrow.
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141203/e56a4691/attachment.sig>
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
Hi Philipp:
On 2014å¹´12æ03æ¥ 02:23, Philipp Zabel wrote:
> Hi Andy,
>
> Am Dienstag, den 02.12.2014, 15:42 +0800 schrieb Andy Yan:
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> new file mode 100644
>> index 000..107c1ca
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> @@ -0,0 +1,40 @@
>> +DesignWare HDMI bridge bindings
>> +
>> +Required properities:
>> +- compatible: platform specific such as:
>> + * "fsl,imx6q-hdmi"
>> + * "fsl,imx6dl-hdmi"
>> + * "rockchip,rk3288-dw-hdmi"
> I think we should add a common compatible value "snps,dw-hdmi-tx" here:
>
> compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx";
>
How about "snps,dw-hdmi", because the driver is not only about
hdmi tx, but also include hdmi phy.
If we add such compatible value, do we have to implement another
platform driver like dw_hdmi-pltfm.c with the
compatible="snps,dw-hdmi" ,
or just include the compatible value in dw_hdmi-imx.c and
dw_hdmi-rockchip.c?
>> +- reg: Physical base address and length of the controller's registers.
>> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> Better make ddc-i2c-bus optional, see the other thread about the ddc i2c
> master.
>
>> +- interrupts: The HDMI interrupt number
>> +
>> +Optional properties
>> +- reg-io-width: the width of the reg:1,4, default set to 1 if not present
>> +
>> +Example:
>> +hdmi: hdmi at 012 {
>> +compatible = "fsl,imx6q-hdmi";
>> +reg = <0x0012 0x9000>;
>> +interrupts = <0 115 0x04>;
>> +gpr = <&gpr>;
>> +clocks = <&clks 123>, <&clks 124>;
>> +clock-names = "iahb", "isfr";
>> +ddc-i2c-bus = <&i2c2>;
>> +
>> +port at 0 {
>> +reg = <0>;
>> +
>> +hdmi_mux_0: endpoint {
>> +remote-endpoint = <&ipu1_di0_hdmi>;
>> +};
>> +};
>> +
>> +port at 1 {
>> +reg = <1>;
>> +
>> +hdmi_mux_1: endpoint {
>> +remote-endpoint = <&ipu1_di1_hdmi>;
>> +};
>> +};
>> +};
> regards
> Philipp
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
[PATCH] drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
From: Rafael J. Wysocki
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM in 4 files under
gpu/drm/exynos/.
Signed-off-by: Rafael J. Wysocki
---
Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).
Please let me know if it is OK to take this one into linux-pm.
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|2 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
===
--- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1817,7 +1817,7 @@ static int fimc_resume(struct device *de
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int fimc_runtime_suspend(struct device *dev)
{
struct fimc_context *ctx = get_fimc_context(dev);
Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
===
--- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1764,7 +1764,7 @@ static int gsc_resume(struct device *dev
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int gsc_runtime_suspend(struct device *dev)
{
struct gsc_context *ctx = get_gsc_context(dev);
Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
===
--- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -822,7 +822,7 @@ static int rotator_resume(struct device
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int rotator_runtime_suspend(struct device *dev)
{
struct rot_context *rot = dev_get_drvdata(dev);
Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
===
--- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1540,7 +1540,7 @@ static int g2d_resume(struct device *dev
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int g2d_runtime_suspend(struct device *dev)
{
struct g2d_data *g2d = dev_get_drvdata(dev);
[PATCH] drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On Wednesday, December 03, 2014 10:54 AM, Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
> depending on CONFIG_PM_RUNTIME may now be changed to depend on
> CONFIG_PM.
>
> Replace CONFIG_PM_RUNTIME with CONFIG_PM in 4 files under
> gpu/drm/exynos/.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> PM_SLEEP is selected) which is only in linux-next at the moment (via the
> linux-pm tree).
>
> Please let me know if it is OK to take this one into linux-pm.
>
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c|2 +-
> drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
> drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
> drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> ===
> --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1817,7 +1817,7 @@ static int fimc_resume(struct device *de
> }
> #endif
>
> -#ifdef CONFIG_PM_RUNTIME
> +#ifdef CONFIG_PM
> static int fimc_runtime_suspend(struct device *dev)
> {
> struct fimc_context *ctx = get_fimc_context(dev);
> Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> ===
> --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1764,7 +1764,7 @@ static int gsc_resume(struct device *dev
> }
> #endif
>
> -#ifdef CONFIG_PM_RUNTIME
> +#ifdef CONFIG_PM
> static int gsc_runtime_suspend(struct device *dev)
> {
> struct gsc_context *ctx = get_gsc_context(dev);
> Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> ===
> --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -822,7 +822,7 @@ static int rotator_resume(struct device
> }
> #endif
>
> -#ifdef CONFIG_PM_RUNTIME
> +#ifdef CONFIG_PM
> static int rotator_runtime_suspend(struct device *dev)
> {
> struct rot_context *rot = dev_get_drvdata(dev);
> Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> ===
> --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1540,7 +1540,7 @@ static int g2d_resume(struct device *dev
> }
> #endif
>
> -#ifdef CONFIG_PM_RUNTIME
> +#ifdef CONFIG_PM
> static int g2d_runtime_suspend(struct device *dev)
> {
> struct g2d_data *g2d = dev_get_drvdata(dev);
[PULL] vmwgfx-next
Dave, A number of bug fixes. The following changes since commit 4fcd01d0f34645710ac92d5523e26019428b0806: drm: rcar-du: Fix NULL encoder pointer dereference (2014-12-03 08:28:48 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux for you to fetch changes up to b8ccd1e490de8d9b9a968f859c003a10882ad8c8: drm/vmwgfx: (Re)bind shaders to MOBs with the correct offset (2014-12-03 00:48:14 -0800) Thomas Hellstrom (4): drm/vmwgfx: Fix error printout on signals pending drm/vmwgfx: Don't use memory accounting for kernel-side fence objects drm/vmwgfx: Fix fence event code drm/vmwgfx: (Re)bind shaders to MOBs with the correct offset drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 8 +-- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 39 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 2 +- 3 files changed, 15 insertions(+), 34 deletions(-)
[PATCH] drm/dp: add drm_dp_link_power_down() helper
On Tue, 02 Dec 2014, Rob Clark wrote:
> We had _power_up(), but drivers also need to be able to power down.
Patch looks good, I'm just hijacking the thread to talk about the
_power_up() counterpart. Sorry. ;)
First, I'm not sure it's all right or sensible to read DP_SET_POWER
first when the sink is sleeping. Shouldn't it just write DP_SET_POWER_D0
to DP_SET_POWER?
Second, I think _power_up() should retry the wake up to ensure an AUX
reply. (If we decide it's all right to read DP_SET_POWER first, I think
it should have a retry too.)
DP v1.2 section 5.1.5 (section 5.2.5 is also relevant):
"""
The Source device must write the value of 1h to DPCD Address 600h of the
downstream device via AUX CH to switch the uPacket RX of the downstream
device out of power-save mode. A uPacket RX of a downstream device in a
power-save mode may not reply to this AUX request transaction. The
uPacket RX of a downstream device in a power-save mode for an open,
box-to-box connection is allowed to take up to 1ms till it is ready to
reply to the AUX request transaction. Therefore, the Source device must
retry until the 1ms wake-up timeout period of the Sink device expires.
"""
This also means that _probe() probably should not be used on sinks that
are in sleep. Therefore _power_up() after _probe() seems redundant too
(one example in tegra_output_sor_enable).
I seem to have reviewed the _power_up() and _probe() patch, so you can
blame me just as well...
BR,
Jani.
>
> Signed-off-by: Rob Clark
> ---
> This lets me drop edp_sink_power_state() from msm eDP code, and use
> the helpers instead.
>
> drivers/gpu/drm/drm_dp_helper.c | 31 +++
> include/drm/drm_dp_helper.h | 1 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 959e207..82122ec 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -353,6 +353,37 @@ int drm_dp_link_power_up(struct drm_dp_aux *aux, struct
> drm_dp_link *link)
> EXPORT_SYMBOL(drm_dp_link_power_up);
>
> /**
> + * drm_dp_link_power_down() - power down a DisplayPort link
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 value;
> + int err;
> +
> + /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> + if (link->revision < 0x11)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
> + if (err < 0)
> + return err;
> +
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D3;
> +
> + err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_link_power_down);
> +
> +/**
> * drm_dp_link_configure() - configure a DisplayPort link
> * @aux: DisplayPort AUX channel
> * @link: pointer to a structure containing the link configuration
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 11f8c84..7e25030 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -586,6 +586,7 @@ struct drm_dp_link {
>
> int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> --
> 1.9.3
>
> ___
> 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
[Bug 86969] _drm_intel_gem_bo_references() function takes half the CPU with Witcher2 game
https://bugs.freedesktop.org/show_bug.cgi?id=86969 Bug ID: 86969 Summary: _drm_intel_gem_bo_references() function takes half the CPU with Witcher2 game Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Keywords: have-backtrace Severity: normal Priority: medium Component: libdrm Assignee: dri-devel at lists.freedesktop.org Reporter: eero.t.tamminen at intel.com CC: currojerez at riseup.net Created attachment 110404 --> https://bugs.freedesktop.org/attachment.cgi?id=110404&action=edit hack/test for alternate drm_intel_gem_bo_references() semantics Setup: - HSW GT3e in desktop case - Ubuntu 14.10 64-bit (kernel 3.16, Xorg 1.16) - Latest libdrm & Mesa 32-bit builds (2014-11-07) - Witcher2 game from Steam (32-bit) Steps: - Start Witcher2 with latest Mesa - Select FullHD resolution and highest generic gfx option, then disable anti-aliasing & ubersampling from the advanced options - Select "Arena" option from the main menu - After animation stops, click through "discussion" and pan around with mouse Results: - When panning around, some orientations show 100% (single) CPU utilization. - "perf" reports (nearly) *half* of the CPU consumption to happen in (very small & recursive) libdrm "_drm_intel_gem_bo_references" function. Analysis: Only caller of "_drm_intel_gem_bo_references" is the exported "drm_intel_gem_bo_references" function. Tracing the calls to that, reveals it to be called from Mesa gen6_check_query() function. [1] Removing libdrm _drm_intel_gem_bo_references() CPU bottleneck by doing flushes unconditionally in gen6_check_query() removed most of the CPU consumption and verifies the "perf" finding. However, those extra flushes made performance marginally worse. Printing statistics from resolving counts showed that for Witcher2, largest relocation count in _drm_intel_gem_bo_references() was 590, but ~97% of the calls had zero relocation counts. Another test was changing the semantics of "drm_intel_gem_bo_references". This also removed most of the Witcher2 CPU consumption, potentially with speed improvement. *On the test machine*, Witcher2 isn't CPU bound despite ~100% CPU load, so CPU usage doesn't directly affect that. *However*, on a temperature limited machine (e.g. laptop with GT3), this could have clear performance impact as the lowered CPU consumption may allow GPU to run at higher clock speed. Power usage should at least be effected. Attached is patch/hack (by Fransisco Jerez) for testing this. Conclusion: There could be two separate functions, with slightly different semantics. One that is fast and does something similar to what Fransisco proposed and which can be used by (Mesa) functions that don't need more accurate information, and the current "libdrm _drm_intel_gem_bo_references" function for those that do need it. --- [1] In addition to resource usage tracing, functracer can attach to a running process and track calls to specified (exported) function: https://maemo.gitorious.org/maemo-tools/functracer According to it, the callers were: 194154 calls (for the trace period): 0xf601e722 drm_intel_bo_references() at intel_bufmgr.c:298 0xf63ca55c gen6_check_query() at gen6_queryobj.c:329 0xf6144e8d _mesa_GetQueryObjectiv() at queryobj.c:620 1133 calls: 0xf601e722 drm_intel_bo_references() at intel_bufmgr.c:298 0xf63ca34c gen6_queryobj_get_results() at gen6_queryobj.c:128 0xf63ca583 gen6_check_query() at gen6_queryobj.c:333 0xf6144e8d _mesa_GetQueryObjectiv() at queryobj.c:620 mp.h:17626 62 calls: 0xf601e722 drm_intel_bo_references() at intel_bufmgr.c:298 0xf62fe973 brw_map_buffer_range() at intel_buffer_objects.c:390 0xf60754b6 _mesa_MapBufferRange() at bufferobj.c:2178 -- 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/20141203/4fcfc22d/attachment-0001.html>
[Bug 86969] _drm_intel_gem_bo_references() function takes half the CPU with Witcher2 game
https://bugs.freedesktop.org/show_bug.cgi?id=86969 --- Comment #1 from Chris Wilson --- Created attachment 110405 --> https://bugs.freedesktop.org/attachment.cgi?id=110405&action=edit Only emit flush the batch once after a pending query -- 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/20141203/6e06e737/attachment.html>
[Bug 86969] _drm_intel_gem_bo_references() function takes half the CPU with Witcher2 game
https://bugs.freedesktop.org/show_bug.cgi?id=86969 Chris Wilson changed: What|Removed |Added Component|libdrm |Drivers/DRI/i965 Version|unspecified |git Assignee|dri-devel at lists.freedesktop |idr at freedesktop.org |.org| Product|DRI |Mesa QA Contact||intel-3d-bugs at lists.freedes ||ktop.org --- Comment #2 from Chris Wilson --- Changing product to one that we have visibility over. -- 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/20141203/fda35866/attachment.html>
[RFC] drm: store property instead of id in obj attachment
On Tue, Dec 02, 2014 at 02:09:41PM -0500, Rob Clark wrote: > On Tue, Dec 2, 2014 at 1:47 PM, Sean Paul wrote: > > On Wed, Nov 26, 2014 at 4:19 PM, Rob Clark wrote: > >> Keep property pointer, instead of id, in per mode-object attachments. > >> This will simplify things in later patches. > >> > >> --- > >> Does anyone care about the lifetime issue and dangling property ptrs? > > > > Judging by the lack of response, it seems like the answer is probably no. > > > > That said, it doesn't seem like a whole lot of work to add refcounting > > to drm_property so we don't have to worry about it. Maybe I'm missing > > something. > > true.. but then the property would not actually go away then, it would > be kept alive by the extra ref. That said, I can't think of a valid > reason for dynamically creating/destroying properties, so I'm tempted > to just add a comment somewhere to explain that detaching from mode > objects would be required if someone did want to dynamically destroy a > property and leave it at that.. I've thought we'd implement blob properties by allowing userspace to allocate a blob prop and then pass around it's id. Similar for framebuffers those would need to be refcounted and also cleaned up (the public side at least) when their owning file_priv is closed. But in general I agree with Rob, there's not really a use case for refcounted driver-side props that I could think of. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/2] drm/ttm: optionally move duplicates to a separate list
From: Christian König
This patch adds an optional list_head parameter to ttm_eu_reserve_buffers.
If specified duplicates in the execbuf list are no longer reported as errors,
but moved to this list instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_release.c| 3 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
include/drm/ttm/ttm_execbuf_util.h | 9 -
7 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 446e71c..d9b2568 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -264,7 +264,8 @@ int qxl_release_reserve_list(struct qxl_release *release,
bool no_intr)
if (list_is_singular(&release->bos))
return 0;
- ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos, !no_intr);
+ ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos,
+!no_intr, NULL);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 6162bd2..fe48f22 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -564,7 +564,7 @@ static void radeon_gem_va_update_vm(struct radeon_device
*rdev,
if (!vm_bos)
return;
- r = ttm_eu_reserve_buffers(&ticket, &list, true);
+ r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL);
if (r)
goto error_free;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 4ab0747..a4a3ac8 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -508,7 +508,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
u64 bytes_moved = 0, initial_bytes_moved;
u64 bytes_moved_threshold = radeon_bo_get_threshold_for_moves(rdev);
- r = ttm_eu_reserve_buffers(ticket, head, true);
+ r = ttm_eu_reserve_buffers(ticket, head, true, NULL);
if (unlikely(r != 0)) {
return r;
}
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 8ce508e..3820ae9 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -93,7 +93,8 @@ EXPORT_SYMBOL(ttm_eu_backoff_reservation);
*/
int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
- struct list_head *list, bool intr)
+ struct list_head *list, bool intr,
+ struct list_head *dups)
{
struct ttm_bo_global *glob;
struct ttm_validate_buffer *entry;
@@ -117,6 +118,13 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
__ttm_bo_unreserve(bo);
ret = -EBUSY;
+
+ } else if (ret == -EALREADY && dups) {
+ struct ttm_validate_buffer *safe = entry;
+ entry = list_prev_entry(entry, head);
+ list_del(&safe->head);
+ list_add(&safe->head, dups);
+ continue;
}
if (!ret) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 596cd6d..33176d0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2487,7 +2487,8 @@ int vmw_execbuf_process(struct drm_file *file_priv,
if (unlikely(ret != 0))
goto out_err_nores;
- ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
true);
+ ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
+true, NULL);
if (unlikely(ret != 0))
goto out_err;
@@ -2677,7 +2678,8 @@ void __vmw_execbuf_release_pinned_bo(struct vmw_private
*dev_priv,
query_val.shared = false;
list_add_tail(&query_val.head, &validate_list);
- ret = ttm_eu_reserve_buffers(&ticket, &validate_list, false);
+ ret = ttm_eu_reserve_buffers(&ticket, &validate_list,
+false, NULL);
if (unlikely(ret != 0)) {
vmw_execbuf_unpin_panic(dev_priv);
goto out_no_reserve;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 026de7c..210ef15 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -1222,7 +1222,7 @@ vmw_resource_check_buffer(struct vmw_resource *res,
val_buf->bo = ttm_bo_reference(&res->backup->base);
[PATCH 2/2] drm/radeon: remove duplicates check
From: Christian König
Completely unnecessary since the ww_mutex used to reserve a buffer
can detect double reservations from the same thread anyway.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon.h| 1 -
drivers/gpu/drm/radeon/radeon_cs.c | 30 +++---
drivers/gpu/drm/radeon/radeon_object.c | 13 ++---
drivers/gpu/drm/radeon/radeon_uvd.c| 2 +-
drivers/gpu/drm/radeon/radeon_vce.c| 2 +-
6 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index b81ba19..e5521946 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2452,7 +2452,7 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
idx, p->nrelocs);
return -EINVAL;
}
- *cs_reloc = p->relocs_ptr[idx];
+ *cs_reloc = &p->relocs[idx];
p->dma_reloc_idx++;
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b59a4de..1319c9c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1076,7 +1076,6 @@ struct radeon_cs_parser {
/* relocations */
unsignednrelocs;
struct radeon_bo_list *relocs;
- struct radeon_bo_list **relocs_ptr;
struct radeon_bo_list *vm_bos;
struct list_headvalidated;
unsigneddma_reloc_idx;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index fb776cb..26f7855 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -77,8 +77,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
struct drm_device *ddev = p->rdev->ddev;
struct radeon_cs_chunk *chunk;
struct radeon_cs_buckets buckets;
- unsigned i, j;
- bool duplicate, need_mmap_lock = false;
+ unsigned i;
+ bool need_mmap_lock = false;
int r;
if (p->chunk_relocs_idx == -1) {
@@ -88,10 +88,6 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->dma_reloc_idx = 0;
/* FIXME: we assume that each relocs use 4 dwords */
p->nrelocs = chunk->length_dw / 4;
- p->relocs_ptr = kcalloc(p->nrelocs, sizeof(void *), GFP_KERNEL);
- if (p->relocs_ptr == NULL) {
- return -ENOMEM;
- }
p->relocs = kcalloc(p->nrelocs, sizeof(struct radeon_bo_list),
GFP_KERNEL);
if (p->relocs == NULL) {
return -ENOMEM;
@@ -104,28 +100,13 @@ static int radeon_cs_parser_relocs(struct
radeon_cs_parser *p)
struct drm_gem_object *gobj;
unsigned priority;
- duplicate = false;
r = (struct drm_radeon_cs_reloc *)&chunk->kdata[i*4];
- for (j = 0; j < i; j++) {
- struct drm_radeon_cs_reloc *other;
- other = (void *)&chunk->kdata[j*4];
- if (r->handle == other->handle) {
- p->relocs_ptr[i] = &p->relocs[j];
- duplicate = true;
- break;
- }
- }
- if (duplicate) {
- continue;
- }
-
gobj = drm_gem_object_lookup(ddev, p->filp, r->handle);
if (gobj == NULL) {
DRM_ERROR("gem object lookup failed 0x%x\n",
r->handle);
return -ENOENT;
}
- p->relocs_ptr[i] = &p->relocs[i];
p->relocs[i].robj = gem_to_radeon_bo(gobj);
/* The userspace buffer priorities are from 0 to 15. A higher
@@ -448,7 +429,6 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
}
kfree(parser->track);
kfree(parser->relocs);
- kfree(parser->relocs_ptr);
drm_free_large(parser->vm_bos);
for (i = 0; i < parser->nchunks; i++)
drm_free_large(parser->chunks[i].kdata);
@@ -523,10 +503,6 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser
*p,
for (i = 0; i < p->nrelocs; i++) {
struct radeon_bo *bo;
- /* ignore duplicates */
- if (p->relocs_ptr[i] != &p->relocs[i])
- continue;
-
bo = p->relocs[i].robj;
bo_va = radeon_vm_bo_find(vm, bo);
if (bo_va == NULL) {
@@ -871,6 +847,6 @@ int radeon_cs_packet_next_reloc(struct radeon_cs_parser *p,
(u64)relocs_chunk->kdata[idx + 3] << 32;
(*cs_reloc)->gpu_offset |= relocs_chunk->kdata[idx + 0];
} else
- *cs_reloc = p->relocs_ptr[(idx / 4)];
+
[PATCH] drm/radeon: use pointers instead of indexes for CS chunks
From: Christian König
Nobody is interested at which index the chunk is. What's needed is
a pointer to the chunk. Remove unused chunk_id field as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen_cs.c | 6 ++--
drivers/gpu/drm/radeon/r100.c | 2 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 14 -
drivers/gpu/drm/radeon/radeon.h | 11 +++
drivers/gpu/drm/radeon/radeon_cs.c| 57 +--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 10 +++---
drivers/gpu/drm/radeon/radeon_vce.c | 4 +--
9 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index a1dece6..924b1b7 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2661,7 +2661,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
p->track = NULL;
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib.length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
@@ -2684,7 +2684,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
**/
int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
{
- struct radeon_cs_chunk *ib_chunk = &p->chunks[p->chunk_ib_idx];
+ struct radeon_cs_chunk *ib_chunk = p->chunk_ib;
struct radeon_bo_list *src_reloc, *dst_reloc, *dst2_reloc;
u32 header, cmd, count, sub_cmd;
volatile u32 *ib = p->ib.ptr;
@@ -3100,7 +3100,7 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
DRM_ERROR("Unknown packet type %d at %d !\n", cmd, idx);
return -EINVAL;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib->length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8174731..d65d1d0 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2061,7 +2061,7 @@ int r100_cs_parse(struct radeon_cs_parser *p)
}
if (r)
return r;
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 91d2442..064ad55 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1283,7 +1283,7 @@ int r300_cs_parse(struct radeon_cs_parser *p)
if (r) {
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index e5521946..acc1f99 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2316,7 +2316,7 @@ int r600_cs_parse(struct radeon_cs_parser *p)
p->track = NULL;
return r;
}
- } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+ } while (p->idx < p->chunk_ib->length_dw);
#if 0
for (r = 0; r < p->ib.length_dw; r++) {
printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
@@ -2351,7 +2351,7 @@ static void r600_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
static int r600_cs_parser_relocs_legacy(struct radeon_cs_parser *p)
{
- if (p->chunk_relocs_idx == -1) {
+ if (p->chunk_relocs == NULL) {
return 0;
}
p->relocs = kzalloc(sizeof(struct radeon_bo_list), GFP_KERNEL);
@@ -2398,7 +2398,7 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
/* Copy the packet into the IB, the parser will read from the
* input memory (cached) and write to the IB (which can be
* uncached). */
- ib_chunk = &parser.chunks[parser.chunk_ib_idx];
+ ib_chunk = parser.chunk_ib;
parser.ib.length_dw = ib_chunk->length_dw;
*l = parser.ib.length_dw;
if (copy_from_user(ib, ib_chunk->user_ptr, ib_chunk->length_dw * 4)) {
@@ -2441,11 +2441,11 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
unsigned idx;
*cs_reloc = NULL;
- if (p->chunk_relocs_idx == -1) {
+ if (p->chunk_relocs == NULL) {
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- relocs_chunk = &p->chunks[p->chunk_relocs_idx];
+ relocs_chunk = p->chunk_relocs;
tile property contents
On 12/02/2014 07:04 PM, Dave Airlie wrote: > On 3 December 2014 at 10:01, Aaron Plattner wrote: >> On 10/13/2014 08:23 PM, Dave Airlie wrote: >>> >>> Hi, >>> >>> So I've been hacking on mutter and the gnome pieces for tiling, and >>> I've at least fixed mutter locally so maximise windows works and the >>> heads are in the right order. >>> >>> Now I've strung all the pieces together using a single KMS property >>> that X.org propogates, and mutter picks up and propagates over dbus as >>> well, >>> >>> Currently I've ascii encoded the property into a blob, >>> >>> >>> >>> >>> I'm thinking of dropping the version field and just exposing TILE2 >>> property if we need it later to add more values, >> >> >> Nifty. Is there a randrproto.txt spec for this planned? >> > > Well for KMS its a kernel property and is documented there, > I suppose randrproto should also contain the info. >> >> What format does this ID need to be in? It looks like monitors are >> identified by (vendor id, product id, serial number) tuples in the DisplayID >> extension block so it would make sense to just concatenate that into one >> giant number as the tileid. Having to centrally manage these (in the >> kernel??) seems like overkill. > > I don't mind, but central management is what we've done, it wasn't a lot > of work, you could munge the vendor/product/serial, but maybe > DisplayId won't be the only game in town in the future and I'd hate > to tie things to it. Alright. At least for now, we can just centrally manage group IDs in our X driver until we move that stuff to the kernel. >>> group - unique per group >>> flags: bit 0 : single monitor enclosure >>> maxhtiles: total number of horiz tiles >>> maxvtiles: total number of vert tiles >>> h_tile_loc: horiz location of this output in tile group >>> v_tile_loc: vert location of this output in tile group >>> tile_w: width of this tile >>> tile_h: height of this tile. >>> >>> Now we extract all of these from the DisplayID v1.3 block, and I'm >>> wondering if maybe I shouldn't just export the whole DisplayID tiling >>> info block instead, it however encodes a few other pieces of >>> information, including bezel info, and some flags specifying behaviour >>> in some cases. >> >> >> I don't know whether the other flags would be useful, but one important one >> is the "native resolution" field. At least one monitor I've seen fails to >> work if you drive the normal EDID "preferred" timings on both tiles. > > I think the last two fields are copied from that, the tile w/h, I can't see > any mention of a specific native res flag. Oh, got it. I was confused by this because our DisplayID parsing library calls this field 'native_resolution'. -- Aaron
[PATCH] drm/edid: Restore kerneldoc consistency
From: Thierry Reding
Commit 18df89fef2d5 ("drm: Decouple EDID parsing from I2C adapter")
renamed the adapter parameter of the drm_do_probe_ddc_edid function
to data but didn't update the kerneldoc accordingly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a7b5a71856a7..3788b969aea4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1115,7 +1115,7 @@ EXPORT_SYMBOL(drm_edid_is_valid);
#define DDC_SEGMENT_ADDR 0x30
/**
* drm_do_probe_ddc_edid() - get EDID information via I2C
- * @adapter: I2C device adaptor
+ * @data: I2C device adapter
* @buf: EDID data buffer to be filled
* @block: 128 byte EDID block to start fetching from
* @len: EDID data buffer length to fetch
--
2.1.3
[PATCH] drm/radeon: check the right ring in radeon_evict_flags()
Check the that ring we are using for copies is functional
rather than the GFX ring. On newer asics we use the DMA
ring for bo moves.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index cbe7b32..d02aa1d 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -196,7 +196,7 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,
rbo = container_of(bo, struct radeon_bo, tbo);
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- if (rbo->rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready == false)
+ if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready ==
false)
radeon_ttm_placement_from_domain(rbo,
RADEON_GEM_DOMAIN_CPU);
else if (rbo->rdev->mc.visible_vram_size <
rbo->rdev->mc.real_vram_size &&
bo->mem.start < (rbo->rdev->mc.visible_vram_size >>
PAGE_SHIFT)) {
--
1.8.3.1
[PATCH] drm/radeon: check the right ring in radeon_evict_flags()
Am 03.12.2014 um 17:09 schrieb Alex Deucher:
> Check the that ring we are using for copies is functional
> rather than the GFX ring. On newer asics we use the DMA
> ring for bo moves.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Christian König
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index cbe7b32..d02aa1d 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -196,7 +196,7 @@ static void radeon_evict_flags(struct ttm_buffer_object
> *bo,
> rbo = container_of(bo, struct radeon_bo, tbo);
> switch (bo->mem.mem_type) {
> case TTM_PL_VRAM:
> - if (rbo->rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready == false)
> + if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready ==
> false)
> radeon_ttm_placement_from_domain(rbo,
> RADEON_GEM_DOMAIN_CPU);
> else if (rbo->rdev->mc.visible_vram_size <
> rbo->rdev->mc.real_vram_size &&
>bo->mem.start < (rbo->rdev->mc.visible_vram_size >>
> PAGE_SHIFT)) {
[PATCH] drm/edid: Restore kerneldoc consistency
On Wed, Dec 03, 2014 at 04:52:18PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit 18df89fef2d5 ("drm: Decouple EDID parsing from I2C adapter")
> renamed the adapter parameter of the drm_do_probe_ddc_edid function
> to data but didn't update the kerneldoc accordingly.
>
> Signed-off-by: Thierry Reding
Merged to my drm-misc branch, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a7b5a71856a7..3788b969aea4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1115,7 +1115,7 @@ EXPORT_SYMBOL(drm_edid_is_valid);
> #define DDC_SEGMENT_ADDR 0x30
> /**
> * drm_do_probe_ddc_edid() - get EDID information via I2C
> - * @adapter: I2C device adaptor
> + * @data: I2C device adapter
> * @buf: EDID data buffer to be filled
> * @block: 128 byte EDID block to start fetching from
> * @len: EDID data buffer length to fetch
> --
> 2.1.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
On Tue, Dec 2, 2014 at 8:46 PM, Bjorn Andersson wrote:
> On Mon, Dec 1, 2014 at 1:56 PM, Jilai Wang wrote:
>> Add HDMI HDCP support including HDCP PartI/II/III authentication.
>>
>> Signed-off-by: Jilai Wang
>> ---
>
> Hi Jilai,
>
> [..]
>
>> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
>> b/drivers/gpu/drm/msm/hdmi/hdmi.c
>
> [..]
>
>>
>> @@ -119,6 +137,22 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct
>> drm_encoder *encoder)
>> goto fail;
>> }
>>
>> + /* HDCP needs physical address of hdmi register */
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> + config->mmio_name);
>
> Is this guaranteed to be available at all times? You should probably
> do some error handling here.
Hi Bjorn,
(as mentioned on irc, but just repeating here for posterity)
this is actually ok in this case, since the previous ioremap would have failed.
>> + hdmi->mmio_phy_addr = res->start;
>> +
>> + if (config->qfprom_mmio_name) {
>
> Should this check really be here? This will always be set if CONFIG_OF is set
> and never otherwise and that seems strange to me.
>
> Perhaps you should add the string to the !CONFIG_OF platforms as well or
> simply
> add #ifdef CONFIG_OF around this section if that's what you really want. (but
> seems more like you forgot the non-of case).
or just not cared enough to make HDCP (since it is optional) work on
old pre-DT vendor kernel ;-)
fwiw, eventually the !CONFIG_OF stuff will go away.. it just exists
because some devices and some use-cases still need old downstream
kernels :-(
>> + hdmi->qfprom_mmio = msm_ioremap(pdev,
>> + config->qfprom_mmio_name, "HDMI_QFPROM");
>
>
> Is this a special hdmi qfprom or are you ioremapping _the_ qfprom here?
>
> If so I did suggest that we expose it as a syscon but I think Stephen Boyd had
> some other ideas.
afaict (but Jilai can correct me), it is *the* qfprom.. that seems to
be how things worked in android kernels. Some better mechanism would
be really nice.
>> + if (IS_ERR(hdmi->qfprom_mmio)) {
>> + dev_info(&pdev->dev, "can't find qfprom resource\n");
>> + hdmi->qfprom_mmio = NULL;
>> + }
>> + } else {
>> + hdmi->qfprom_mmio = NULL;
>
> hdmi_qfprom_read() seems to be called and read from qfprom_mmio no matter how
> this ended. Are you sure this (both error paths) shouldn't be handled as a
> fatal error?
hdmi_hdcp_init() fails (and then we continue without HDCP) if
qfprom_mmio is NULL..
> 'hdmi' is kzalloc and hence already NULL.
>
> [..]
>
>> @@ -205,6 +241,13 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct
>> drm_encoder *encoder)
>> goto fail;
>> }
>>
>> + hdmi->hdcp_ctrl = hdmi_hdcp_init(hdmi);
>> + if (IS_ERR(hdmi->hdcp_ctrl)) {
>> + ret = PTR_ERR(hdmi->hdcp_ctrl);
>> + dev_warn(dev->dev, "failed to init hdcp: %d(disabled)\n",
>> ret);
>> + hdmi->hdcp_ctrl = NULL;
>
> So either you treat this as an error or you don't.
>
> If you're fine continuing execution without hdcp_ctrl then you shouldn't set
> ret. But in that case it you should probably not print a warning every time
> you
> enter hdmi_hdcp_on() and an error on hdmi_hdcp_off().
agreed, I think it would be better for hdcp_on/off() to take struct
hdmi_hdcp_ctrl as param (and just not be called if hdmi->hdcp_ctrl is
null)
[snip]
> [..]
>
>> +
>> +struct hdmi_hdcp_reg_data {
>> + uint32_t reg_id;
>
> You should use u32 instead of uint32_t in the kernel.
tbh, I'd prefer sticking to stdint types.. before stdint was a thing,
u32 made sense
>> + uint32_t off;
>> + char *name;
>> + uint32_t reg_val;
>> +};
>> +
>> +struct hdmi_hdcp_ctrl {
>> + struct hdmi *hdmi;
>> + uint32_t auth_retries;
>> + uint32_t tz_hdcp;
>
> Turn this into a bool named something like has_tz_hdcp instead, as that's what
> it really means.
>
>> + enum hdmi_hdcp_state hdcp_state;
>> + struct mutex state_mutex;
>> + struct delayed_work hdcp_reauth_work;
>> + struct delayed_work hdcp_auth_part1_1_work;
>> + struct delayed_work hdcp_auth_part1_2_work;
>> + struct work_struct hdcp_auth_part1_3_work;
>> + struct delayed_work hdcp_auth_part2_1_work;
>> + struct delayed_work hdcp_auth_part2_2_work;
>> + struct delayed_work hdcp_auth_part2_3_work;
>> + struct delayed_work hdcp_auth_part2_4_work;
>> + struct work_struct hdcp_auth_prepare_work;
>
> You shouldn't use "work" as a way to express states in your state machine.
> Better have 1 auth work function that does all these steps, probably having
> them split in functions just like you do now.
>
> That way you can have 1 function running the pass of authentication, starting
> by checking if you're reauthing or not then processing each step one by one,
> sleeping inbe
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
On Mon, Dec 1, 2014 at 4:56 PM, Jilai Wang wrote: > + /* Enable HDCP Encryption */ > + hdmi_write(hdmi, REG_HDMI_HDCP_CTRL, BIT(0) | BIT(8)); btw, as Bjron mentioned, there are a lot of these open coded BIT(n).. but from a quick check, the first two or three I looked at, we already have the appropriate defines in the rnndb generated headers, to instead do: /* Enable HDCP Encryption */ hdmi_write(hdmi, REG_HDMI_HDCP_CTRL, HDMI_HDCP_CTRL_ENABLE | HDMI_HDCP_CTRL_ENCRYPTION_ENABLE); that seems somewhat more readable to me ;-) BR, -R
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
On Wed, Dec 3, 2014 at 12:16 PM, wrote: + enum hdmi_hdcp_state hdcp_state; + struct mutex state_mutex; + struct delayed_work hdcp_reauth_work; + struct delayed_work hdcp_auth_part1_1_work; + struct delayed_work hdcp_auth_part1_2_work; + struct work_struct hdcp_auth_part1_3_work; + struct delayed_work hdcp_auth_part2_1_work; + struct delayed_work hdcp_auth_part2_2_work; + struct delayed_work hdcp_auth_part2_3_work; + struct delayed_work hdcp_auth_part2_4_work; + struct work_struct hdcp_auth_prepare_work; >>> >>> You shouldn't use "work" as a way to express states in your state >>> machine. >>> Better have 1 auth work function that does all these steps, probably >>> having >>> them split in functions just like you do now. >>> >>> That way you can have 1 function running the pass of authentication, >>> starting >>> by checking if you're reauthing or not then processing each step one by >>> one, >>> sleeping inbetween them. You can have the functions return -EAGAIN to >>> indicate >>> that you need to retry the current operation and so on. >>> >>> This would split the state machine from the state executioners and >>> simplify >>> your code. >> >> As a side note (disclaimer, I'm not an hdcp expert), but I wonder if >> eventually some of that should be extracted out into some helpers in >> drm core. I guess that is something we'll figure out when a 2nd >> driver gains upstream HDCP support. One big work w/ msleep()'s does >> sound like it would be easier to understand (and therefore easier to >> refactor out into helpers). >> >> [snip] >> > > The reason that I break the partI/PartII work into these small works > because I want to avoid to use msleep in work. > Otherwise cancel a HDCP work may cause long delay up to several seconds. hmm, yeah, several seconds is long enough for user to plug/unplug several displays ;-) But I guess a wait_event_timeout() plus a wq that is signalled on hpd (or whenever we need to cancel) instead of msleep might do the trick? BR, -R
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
On Wed, Dec 3, 2014 at 9:16 AM, wrote: [..] + enum hdmi_hdcp_state hdcp_state; + struct mutex state_mutex; + struct delayed_work hdcp_reauth_work; + struct delayed_work hdcp_auth_part1_1_work; + struct delayed_work hdcp_auth_part1_2_work; + struct work_struct hdcp_auth_part1_3_work; + struct delayed_work hdcp_auth_part2_1_work; + struct delayed_work hdcp_auth_part2_2_work; + struct delayed_work hdcp_auth_part2_3_work; + struct delayed_work hdcp_auth_part2_4_work; + struct work_struct hdcp_auth_prepare_work; >>> >>> You shouldn't use "work" as a way to express states in your state >>> machine. >>> Better have 1 auth work function that does all these steps, probably >>> having >>> them split in functions just like you do now. >>> >>> That way you can have 1 function running the pass of authentication, >>> starting >>> by checking if you're reauthing or not then processing each step one by >>> one, >>> sleeping inbetween them. You can have the functions return -EAGAIN to >>> indicate >>> that you need to retry the current operation and so on. >>> >>> This would split the state machine from the state executioners and >>> simplify >>> your code. >> >> As a side note (disclaimer, I'm not an hdcp expert), but I wonder if >> eventually some of that should be extracted out into some helpers in >> drm core. I guess that is something we'll figure out when a 2nd >> driver gains upstream HDCP support. One big work w/ msleep()'s does >> sound like it would be easier to understand (and therefore easier to >> refactor out into helpers). >> >> [snip] >> > > The reason that I break the partI/PartII work into these small works > because I want to avoid to use msleep in work. > Otherwise cancel a HDCP work may cause long delay up to several seconds. > I definitely think the steps are nice size and make things easy to understand. If you make the steps that require a retry return out to the main state handling function with a -EAGAIN, then you can have check if you should retry or abort based on cancellation. Giving you the worst case cancellation time of the longest sleep... As Rob suggest you could use wait_event_timeout() or something to improve this, but on the other hand the worst case here seems to be the HZ/2 after prepare_auth; others are HZ/8, HZ/20 and HZ/50; not "seconds". So I would start with a simple msleep() for implementation simplicity and then enhance that in a follow up commit (if needed)... Regards, Bjorn
[PATCH 1/2] drm/ttm: optionally move duplicates to a separate list
LTGM
Reviewed-by: Thomas Hellstrom
On 12/03/2014 03:46 PM, Christian König wrote:
> From: Christian König
>
> This patch adds an optional list_head parameter to ttm_eu_reserve_buffers.
> If specified duplicates in the execbuf list are no longer reported as errors,
> but moved to this list instead.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/qxl/qxl_release.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 --
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
> include/drm/ttm/ttm_execbuf_util.h | 9 -
> 7 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index 446e71c..d9b2568 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -264,7 +264,8 @@ int qxl_release_reserve_list(struct qxl_release *release,
> bool no_intr)
> if (list_is_singular(&release->bos))
> return 0;
>
> - ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos, !no_intr);
> + ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos,
> + !no_intr, NULL);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 6162bd2..fe48f22 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -564,7 +564,7 @@ static void radeon_gem_va_update_vm(struct radeon_device
> *rdev,
> if (!vm_bos)
> return;
>
> - r = ttm_eu_reserve_buffers(&ticket, &list, true);
> + r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL);
> if (r)
> goto error_free;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 4ab0747..a4a3ac8 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -508,7 +508,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
> u64 bytes_moved = 0, initial_bytes_moved;
> u64 bytes_moved_threshold = radeon_bo_get_threshold_for_moves(rdev);
>
> - r = ttm_eu_reserve_buffers(ticket, head, true);
> + r = ttm_eu_reserve_buffers(ticket, head, true, NULL);
> if (unlikely(r != 0)) {
> return r;
> }
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 8ce508e..3820ae9 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -93,7 +93,8 @@ EXPORT_SYMBOL(ttm_eu_backoff_reservation);
> */
>
> int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
> -struct list_head *list, bool intr)
> +struct list_head *list, bool intr,
> +struct list_head *dups)
> {
> struct ttm_bo_global *glob;
> struct ttm_validate_buffer *entry;
> @@ -117,6 +118,13 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
> __ttm_bo_unreserve(bo);
>
> ret = -EBUSY;
> +
> + } else if (ret == -EALREADY && dups) {
> + struct ttm_validate_buffer *safe = entry;
> + entry = list_prev_entry(entry, head);
> + list_del(&safe->head);
> + list_add(&safe->head, dups);
> + continue;
> }
>
> if (!ret) {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 596cd6d..33176d0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -2487,7 +2487,8 @@ int vmw_execbuf_process(struct drm_file *file_priv,
> if (unlikely(ret != 0))
> goto out_err_nores;
>
> - ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
> true);
> + ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
> + true, NULL);
> if (unlikely(ret != 0))
> goto out_err;
>
> @@ -2677,7 +2678,8 @@ void __vmw_execbuf_release_pinned_bo(struct vmw_private
> *dev_priv,
> query_val.shared = false;
> list_add_tail(&query_val.head, &validate_list);
>
> - ret = ttm_eu_reserve_buffers(&ticket, &validate_list, false);
> + ret = ttm_eu_reserve_buffers(&ticket, &validate_list,
> + false, NULL);
> if (unlikely(ret != 0)) {
> vmw_execbuf_unpin_panic(dev_priv);
> goto out_no_reserve;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index 026de7c..210ef15 100644
[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes
https://bugs.freedesktop.org/show_bug.cgi?id=86038 --- Comment #18 from Kai --- Since I've updated my stack and there was a new Dreamfall Chapters release (1.1.2), I had a look at the intro scene again. But it looks still like I described in comment #17. My current stack (Debian testing as a base) is: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/a2f2eebfdf libdrm: Git:master/00847fa48b LLVM: SVN:trunk/r223220 (3.6 devel) X.Org: 2:1.16.1-1 Linux: Git::drm-next-3.19-wip/f66d9660a0 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/229064524b DDX: Git:master/c9f8f642fd -- 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/20141203/5b9e7eb5/attachment.html>
[PATCH] drm/radeon: use pointers instead of indexes for CS chunks
On Wed, Dec 3, 2014 at 9:53 AM, Christian König
wrote:
> From: Christian König
>
> Nobody is interested at which index the chunk is. What's needed is
> a pointer to the chunk. Remove unused chunk_id field as well.
>
> Signed-off-by: Christian König
Applied to my -next tree.
Thanks,
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 6 ++--
> drivers/gpu/drm/radeon/r100.c | 2 +-
> drivers/gpu/drm/radeon/r300.c | 2 +-
> drivers/gpu/drm/radeon/r600_cs.c | 14 -
> drivers/gpu/drm/radeon/radeon.h | 11 +++
> drivers/gpu/drm/radeon/radeon_cs.c| 57
> +--
> drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
> drivers/gpu/drm/radeon/radeon_uvd.c | 10 +++---
> drivers/gpu/drm/radeon/radeon_vce.c | 4 +--
> 9 files changed, 53 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index a1dece6..924b1b7 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -2661,7 +2661,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
> p->track = NULL;
> return r;
> }
> - } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
> + } while (p->idx < p->chunk_ib->length_dw);
> #if 0
> for (r = 0; r < p->ib.length_dw; r++) {
> printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
> @@ -2684,7 +2684,7 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
> **/
> int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> {
> - struct radeon_cs_chunk *ib_chunk = &p->chunks[p->chunk_ib_idx];
> + struct radeon_cs_chunk *ib_chunk = p->chunk_ib;
> struct radeon_bo_list *src_reloc, *dst_reloc, *dst2_reloc;
> u32 header, cmd, count, sub_cmd;
> volatile u32 *ib = p->ib.ptr;
> @@ -3100,7 +3100,7 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> DRM_ERROR("Unknown packet type %d at %d !\n", cmd,
> idx);
> return -EINVAL;
> }
> - } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
> + } while (p->idx < p->chunk_ib->length_dw);
> #if 0
> for (r = 0; r < p->ib->length_dw; r++) {
> printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 8174731..d65d1d0 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -2061,7 +2061,7 @@ int r100_cs_parse(struct radeon_cs_parser *p)
> }
> if (r)
> return r;
> - } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
> + } while (p->idx < p->chunk_ib->length_dw);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 91d2442..064ad55 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -1283,7 +1283,7 @@ int r300_cs_parse(struct radeon_cs_parser *p)
> if (r) {
> return r;
> }
> - } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
> + } while (p->idx < p->chunk_ib->length_dw);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index e5521946..acc1f99 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -2316,7 +2316,7 @@ int r600_cs_parse(struct radeon_cs_parser *p)
> p->track = NULL;
> return r;
> }
> - } while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
> + } while (p->idx < p->chunk_ib->length_dw);
> #if 0
> for (r = 0; r < p->ib.length_dw; r++) {
> printk(KERN_INFO "%05d 0x%08X\n", r, p->ib.ptr[r]);
> @@ -2351,7 +2351,7 @@ static void r600_cs_parser_fini(struct radeon_cs_parser
> *parser, int error)
>
> static int r600_cs_parser_relocs_legacy(struct radeon_cs_parser *p)
> {
> - if (p->chunk_relocs_idx == -1) {
> + if (p->chunk_relocs == NULL) {
> return 0;
> }
> p->relocs = kzalloc(sizeof(struct radeon_bo_list), GFP_KERNEL);
> @@ -2398,7 +2398,7 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
> struct drm_file *filp,
> /* Copy the packet into the IB, the parser will read from the
> * input memory (cached) and write to the IB (which can be
> * uncached). */
> - ib_chunk = &parser.chunks[parser.chunk_ib_idx];
> + ib_chunk = parser.chunk_ib;
> parser.ib.length_dw = ib_chunk->length_dw;
> *l = parser.ib.length_dw;
> if (copy_from_user(ib, ib_chunk->user_ptr, ib_chunk->length_dw * 4)) {
> @@ -2441,11 +2441,11 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
>
[PATCH 1/2] drm/ttm: optionally move duplicates to a separate list
On Wed, Dec 3, 2014 at 9:46 AM, Christian König
wrote:
> From: Christian König
>
> This patch adds an optional list_head parameter to ttm_eu_reserve_buffers.
> If specified duplicates in the execbuf list are no longer reported as errors,
> but moved to this list instead.
>
> Signed-off-by: Christian König
Applied the series to my -next tree.
Thanks,
Alex
> ---
> drivers/gpu/drm/qxl/qxl_release.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 --
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
> include/drm/ttm/ttm_execbuf_util.h | 9 -
> 7 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index 446e71c..d9b2568 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -264,7 +264,8 @@ int qxl_release_reserve_list(struct qxl_release *release,
> bool no_intr)
> if (list_is_singular(&release->bos))
> return 0;
>
> - ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos,
> !no_intr);
> + ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos,
> +!no_intr, NULL);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 6162bd2..fe48f22 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -564,7 +564,7 @@ static void radeon_gem_va_update_vm(struct radeon_device
> *rdev,
> if (!vm_bos)
> return;
>
> - r = ttm_eu_reserve_buffers(&ticket, &list, true);
> + r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL);
> if (r)
> goto error_free;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 4ab0747..a4a3ac8 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -508,7 +508,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
> u64 bytes_moved = 0, initial_bytes_moved;
> u64 bytes_moved_threshold = radeon_bo_get_threshold_for_moves(rdev);
>
> - r = ttm_eu_reserve_buffers(ticket, head, true);
> + r = ttm_eu_reserve_buffers(ticket, head, true, NULL);
> if (unlikely(r != 0)) {
> return r;
> }
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 8ce508e..3820ae9 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -93,7 +93,8 @@ EXPORT_SYMBOL(ttm_eu_backoff_reservation);
> */
>
> int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
> - struct list_head *list, bool intr)
> + struct list_head *list, bool intr,
> + struct list_head *dups)
> {
> struct ttm_bo_global *glob;
> struct ttm_validate_buffer *entry;
> @@ -117,6 +118,13 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
> __ttm_bo_unreserve(bo);
>
> ret = -EBUSY;
> +
> + } else if (ret == -EALREADY && dups) {
> + struct ttm_validate_buffer *safe = entry;
> + entry = list_prev_entry(entry, head);
> + list_del(&safe->head);
> + list_add(&safe->head, dups);
> + continue;
> }
>
> if (!ret) {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 596cd6d..33176d0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -2487,7 +2487,8 @@ int vmw_execbuf_process(struct drm_file *file_priv,
> if (unlikely(ret != 0))
> goto out_err_nores;
>
> - ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
> true);
> + ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes,
> +true, NULL);
> if (unlikely(ret != 0))
> goto out_err;
>
> @@ -2677,7 +2678,8 @@ void __vmw_execbuf_release_pinned_bo(struct vmw_private
> *dev_priv,
> query_val.shared = false;
> list_add_tail(&query_val.head, &validate_list);
>
> - ret = ttm_eu_reserve_buffers(&ticket, &validate_list, false);
> + ret = ttm_eu_reserve_buffers(&ticket, &validate_list,
> +false, NULL);
> if (unlikely(ret != 0)) {
> vmw_execbuf_unpin_panic(dev_priv);
> goto out_no_reserve;
> diff --git a/drivers/gpu/
[PATCH 1/2] drm/Documentation: Fix rowspan value in drm-kms-properties
The "DRM" rowspan wasn't updated in commit cc7096fb6d1d (drm/mode: document path property and function to set it. (v1.1)), so increment it by one to fix the table. Cc: Dave Airlie Signed-off-by: Sean Paul --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 56e2a9b..85287cb 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2546,7 +2546,7 @@ void intel_crt_init(struct drm_device *dev) Description/Restrictions - DRM + DRM Generic âEDIDâ BLOB | IMMUTABLE -- 2.2.0.rc0.207.ga3a616c
[PATCH 2/2] drm: Add Content Protection Desired property to drm
Add a new standard connector property to track whether content protection
(ex: hdcp) is desired by userspace. While there are 3 possible states for the
property, userspace should only change the value to desired or undesired.
Upon setting the value to desired, the driver is responsible for protecting
the link and setting the value to enabled. Disabling protection should happen
immediately.
Cc: Rob Clark
Signed-off-by: Sean Paul
---
Documentation/DocBook/drm.tmpl | 19 +--
drivers/gpu/drm/drm_crtc.c | 14 ++
drivers/gpu/drm/drm_sysfs.c| 22 ++
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm_mode.h| 5 +
5 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 85287cb..86633f2 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2546,8 +2546,8 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions
- DRM
- Generic
+ DRM
+ Generic
âEDIDâ
BLOB | IMMUTABLE
0
@@ -2562,6 +2562,21 @@ void intel_crt_init(struct drm_device *dev)
Contains DPMS operation mode value.
+ âContent Protectionâ
+ ENUM
+ { âUndesiredâ, âDesiredâ, âEnabledâ }
+ Connector
+ Contains the current state of content protection on
+ the link. User space should set this property to "Desired" to
+ enable protection. Once the driver has authenticated the
+ connection, it shall set the value to "Enabled". To disable
+ protection, user space shall set the value to "Undesired", which
+ will tear down the encryption. If at any point the link becomes
+ unprotected, the driver shall transition from "Enabled" down to
+ "Desired" and may retry if appropriate.
+
+
+
âPATHâ
BLOB | IMMUTABLE
0
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index de79283..5df5b7b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -77,6 +77,14 @@ static const struct drm_prop_enum_list
drm_plane_type_enum_list[] =
{ DRM_PLANE_TYPE_CURSOR, "Cursor" },
};
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
/*
* Optional properties
*/
@@ -1319,6 +1327,7 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
struct drm_property *edid;
struct drm_property *dpms;
struct drm_property *dev_path;
+ struct drm_property *content_protection;
/*
* Standard properties (apply to all connectors)
@@ -1339,6 +1348,11 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
"PATH", 0);
dev->mode_config.path_property = dev_path;
+ content_protection = drm_property_create_enum(dev, 0,
+ "Content Protection", drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ dev->mode_config.content_protection_property = content_protection;
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index cc3d6d6..b4019b5 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -214,6 +214,27 @@ static ssize_t enabled_show(struct device *device,
"disabled");
}
+static ssize_t content_protection_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct drm_connector *connector = to_drm_connector(device);
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+ uint64_t cp;
+ int ret;
+
+ prop = dev->mode_config.content_protection_property;
+ if (!prop)
+ return 0;
+
+ ret = drm_object_property_get_value(&connector->base, prop, &cp);
+ if (ret)
+ return 0;
+
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ drm_get_content_protection_name((int)cp));
+}
+
static ssize_t edid_show(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf, loff_t off,
size_t count)
@@ -344,6 +365,7 @@ static struct device_attribute connector_attrs[] = {
__ATTR_RO(enabled),
__ATTR_RO(dpms),
__ATTR_RO(modes),
+ __ATTR_RO(content_protection),
};
/* These attributes are for both DVI-I connectors and all types of tv-out. */
diff --git a/include/drm/drm_crtc.h b/inc
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 Bjorn Helgaas changed: What|Removed |Added CC||yinghai at kernel.org Component|Video(DRI - non Intel) |PCI Assignee|drivers_video-dri at kernel-bu |drivers_pci at kernel-bugs.osd |gs.osdl.org |l.org Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm: Add Content Protection Desired property to drm
On Wed, Dec 03, 2014 at 11:57:41AM -0800, Sean Paul wrote:
> Add a new standard connector property to track whether content protection
> (ex: hdcp) is desired by userspace. While there are 3 possible states for the
> property, userspace should only change the value to desired or undesired.
> Upon setting the value to desired, the driver is responsible for protecting
> the link and setting the value to enabled. Disabling protection should happen
> immediately.
Having a magic part r/w part r/o property doesn't sound very appealing
to me. I'm thinking it would be cleaner to just have two properties for
such things.
>
> Cc: Rob Clark
> Signed-off-by: Sean Paul
> ---
> Documentation/DocBook/drm.tmpl | 19 +--
> drivers/gpu/drm/drm_crtc.c | 14 ++
> drivers/gpu/drm/drm_sysfs.c| 22 ++
> include/drm/drm_crtc.h | 2 ++
> include/uapi/drm/drm_mode.h| 5 +
> 5 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 85287cb..86633f2 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2546,8 +2546,8 @@ void intel_crt_init(struct drm_device *dev)
> Description/Restrictions
>
>
> - DRM
> - Generic
> + DRM
> + Generic
> âEDIDâ
> BLOB | IMMUTABLE
> 0
> @@ -2562,6 +2562,21 @@ void intel_crt_init(struct drm_device *dev)
> Contains DPMS operation mode value.
>
>
> + âContent Protectionâ
> + ENUM
> + { âUndesiredâ, âDesiredâ, âEnabledâ }
> + Connector
> + Contains the current state of content protection on
> + the link. User space should set this property to "Desired" to
> + enable protection. Once the driver has authenticated the
> + connection, it shall set the value to "Enabled". To disable
> + protection, user space shall set the value to "Undesired", which
> + will tear down the encryption. If at any point the link becomes
> + unprotected, the driver shall transition from "Enabled" down to
> + "Desired" and may retry if appropriate.
> +
> +
> +
> âPATHâ
> BLOB | IMMUTABLE
> 0
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index de79283..5df5b7b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -77,6 +77,14 @@ static const struct drm_prop_enum_list
> drm_plane_type_enum_list[] =
> { DRM_PLANE_TYPE_CURSOR, "Cursor" },
> };
>
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> + { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
> + { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> + { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
> /*
> * Optional properties
> */
> @@ -1319,6 +1327,7 @@ static int
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> struct drm_property *edid;
> struct drm_property *dpms;
> struct drm_property *dev_path;
> + struct drm_property *content_protection;
>
> /*
>* Standard properties (apply to all connectors)
> @@ -1339,6 +1348,11 @@ static int
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> "PATH", 0);
> dev->mode_config.path_property = dev_path;
>
> + content_protection = drm_property_create_enum(dev, 0,
> + "Content Protection", drm_cp_enum_list,
> + ARRAY_SIZE(drm_cp_enum_list));
> + dev->mode_config.content_protection_property = content_protection;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index cc3d6d6..b4019b5 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -214,6 +214,27 @@ static ssize_t enabled_show(struct device *device,
> "disabled");
> }
>
> +static ssize_t content_protection_show(struct device *device,
> + struct device_attribute *attr, char *buf)
> +{
> + struct drm_connector *connector = to_drm_connector(device);
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> + uint64_t cp;
> + int ret;
> +
> + prop = dev->mode_config.content_protection_property;
> + if (!prop)
> + return 0;
> +
> + ret = drm_object_property_get_value(&connector->base, prop, &cp);
> + if (ret)
> + return 0;
> +
> + return snprintf(buf, PAGE_SIZE, "%s\n",
> + drm_get_content_protection_name((int)cp));
> +}
> +
> static ssize_t edid_show(struct file *filp, struct kobject *kobj,
>struct bin_attribute *attr, char *buf, loff_t off,
>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #60 from Chernovsky Oleg --- (In reply to Alex Deucher from comment #59) > I also noticed a minor error in the RPM control setup, and I've pushed a > patch to my 3.19-wip branch. I (think I) found another typo, that was tricky one to notice :D > tmp = RREG32_SMC(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK; > tmp |= FDO_PWM_MODE(mode); > WREG32_SMC(CG_FDO_CTRL2, tmp); bitwise not (~) is missing from the first 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/20141203/99763114/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #61 from Alex Deucher --- Good catch. Fix pushed to my 3.19-wip branch. -- 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/20141203/bc9be115/attachment.html>
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
Hi Philipp: On 2014å¹´12æ03æ¥ 17:19, Philipp Zabel wrote: > Hi Andy, > > Am Mittwoch, den 03.12.2014, 08:54 +0800 schrieb Andy Yan: +Required properities: +- compatible: platform specific such as: + * "fsl,imx6q-hdmi" + * "fsl,imx6dl-hdmi" + * "rockchip,rk3288-dw-hdmi" >>> I think we should add a common compatible value "snps,dw-hdmi-tx" here: >>> >>> compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx"; >>> >>How about "snps,dw-hdmi", because the driver is not only about >> hdmi tx, but also include hdmi phy. > Synopsys call the whole module > "DesignWare HDMI Transmitter (TX) IP Solution": > > https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_14_csds_tx > https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_20_csds_tx > > That includes the PHY. I'd prefer keeping the -tx in there to > differentiate from a possible future "snps,dw-hdmi-rx": > > https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_14_csds_rx > https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_20_csds_rx Ok, I will add the compatible "snps, dw-hdmi-tx", So do I need to add this value to imx6dl.dtsi? >> If we add such compatible value, do we have to implement another >> platform driver like dw_hdmi-pltfm.c with the >> compatible="snps,dw-hdmi" , >> or just include the compatible value in dw_hdmi-imx.c and >> dw_hdmi-rockchip.c? > That common compatible doesn't have to be used by any driver. It's just > there to show these are the same/similar IP core. > If a common driver without any SoC specific knowledge could be written, > that one would match against the common compatible. > > regards > Philipp > > > ___ > Linux-rockchip mailing list > Linux-rockchip at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > >
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
Am Mittwoch, den 03.12.2014, 17:46 +0800 schrieb Andy Yan: > On 2014å¹´12æ03æ¥ 02:23, Philipp Zabel wrote: > > Hi Andy, > > > > Am Dienstag, den 02.12.2014, 15:42 +0800 schrieb Andy Yan: > >> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > >> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > >> new file mode 100644 > >> index 000..107c1ca > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > >> @@ -0,0 +1,40 @@ > >> +DesignWare HDMI bridge bindings > >> + > >> +Required properities: > >> +- compatible: platform specific such as: > >> + * "fsl,imx6q-hdmi" > >> + * "fsl,imx6dl-hdmi" > >> + * "rockchip,rk3288-dw-hdmi" > > I think we should add a common compatible value "snps,dw-hdmi-tx" here: > > > > compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx"; > > > >> +- reg: Physical base address and length of the controller's registers. > >> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > Better make ddc-i2c-bus optional, see the other thread about the ddc i2c > > master. > I have the same idea too, but the patch about ddc i2c master has not > landed yet, can we change the ddc-i2c-bus to optional after the ddc > i2c master > patch land? Check out Documentation/devicetree/bindings/drm/imx/hdmi.txt, it was already marked as optional. We can't make it required now. regards Philipp
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
On 2014å¹´12æ03æ¥ 19:52, Philipp Zabel wrote: > Am Mittwoch, den 03.12.2014, 17:46 +0800 schrieb Andy Yan: >> On 2014å¹´12æ03æ¥ 02:23, Philipp Zabel wrote: >>> Hi Andy, >>> >>> Am Dienstag, den 02.12.2014, 15:42 +0800 schrieb Andy Yan: diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt new file mode 100644 index 000..107c1ca --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt @@ -0,0 +1,40 @@ +DesignWare HDMI bridge bindings + +Required properities: +- compatible: platform specific such as: + * "fsl,imx6q-hdmi" + * "fsl,imx6dl-hdmi" + * "rockchip,rk3288-dw-hdmi" >>> I think we should add a common compatible value "snps,dw-hdmi-tx" here: >>> >>> compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx"; >>> +- reg: Physical base address and length of the controller's registers. +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing >>> Better make ddc-i2c-bus optional, see the other thread about the ddc i2c >>> master. >> I have the same idea too, but the patch about ddc i2c master has not >>landed yet, can we change the ddc-i2c-bus to optional after the ddc >> i2c master >>patch land? > Check out Documentation/devicetree/bindings/drm/imx/hdmi.txt, it was > already marked as optional. We can't make it required now. > > regards > Philipp > > > OK, got it, thanks
[PATCH] amdkfd: use atomic allocations within srcu callbacks
srcu callbacks are running in atomic context, we can't allocate using
__GFP_WAIT.
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index b4f49ac..b85eb0b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -196,7 +196,7 @@ static void kfd_process_destroy_delayed(struct rcu_head
*rcu)
mmdrop(p->mm);
work = (struct kfd_process_release_work *)
- kmalloc(sizeof(struct kfd_process_release_work), GFP_KERNEL);
+ kmalloc(sizeof(struct kfd_process_release_work), GFP_ATOMIC);
if (work) {
INIT_WORK((struct work_struct *) work, kfd_process_wq_release);
--
2.1.0
[PATCH v16 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
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): split platform specific code
(4): move imx-hdmi to bridge/dw_hdmi
(5): extend dw_hdmi.c to support rk3288 hdmi
(6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c
Changes in v16:
- use the common binding for the clocks
- describe ddc-i2c-bus as optional
Changes in v15:
- add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs
adviced by Philipp Zabel
- remove THIS_MODULE in platform driver
- remove unio of the multi-byte register access, adviced by Philipp Zabel
- remove THIS_MODULE in platform driver
Changes in v14:
- add defer probing, adviced by Philipp Zabel
- remove drm_connector_register, because imx-drm core has registered
connector
Changes in v13:
- patch against drm-next
- split platform specific phy configuration
- split phy configuration from patch#4
Changes in v12:
- refactor of_node_put(ddc_node)
- squash patch
- add comment for the depend on patch
Changes in v11:
- squash 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
- 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
Andy Yan (12):
drm: imx: imx-hdmi: make checkpatch happy
drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
drm: imx: imx-hdmi: split phy configuration to platform driver
drm: imx: 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 | 45 ++
.../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 ++
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile| 1 +
.../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 711 ++---
.../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 4 +-
drivers/gpu/drm/imx/Kconfig| 1 +
drivers/gpu/drm/imx/Makefile | 2 +-
drivers/gpu/drm/imx/dw_hdmi-imx.c | 247 +++
drivers/gpu/drm/rockchip/Kconfig | 10 +
drivers/gpu/drm/rockchip/Makefile | 2 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 321 ++
include/drm/bridge/dw_hdmi.h | 60 ++
13 files changed, 1074 insertions(+), 381 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/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (73%)
rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (99%)
create mode 100644 drivers/gpu/drm/imx/dw_hdmi-imx.c
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
create mode 100644 include/drm/bridge/dw_hdmi.h
--
1.9.1
[PATCH v16 01/12] drm: imx: imx-hdmi: make checkpatch happy
CHECK: Alignment should match open parenthesis
+ if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+ (hdmi->vic == 12) || (hdmi->vic == 13) ||
CHECK: braces {} should be used on all arms of this statement
+ if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+ else {
[...]
Signed-off-by: Andy Yan
Reviewed-by: Daniel Kurtz
---
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13:
- patch against drm-next
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- rearrange the patch order
Changes in v5: None
Changes in v4:
- fix checkpatch CHECK
Changes in v3: None
drivers/gpu/drm/imx/imx-hdmi.c | 109 -
1 file changed, 52 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index aaec6b2..7fd90ae 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -163,7 +163,7 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8
mask, unsigned reg)
}
static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
- u8 shift, u8 mask)
+u8 shift, u8 mask)
{
hdmi_modb(hdmi, data << shift, mask, reg);
}
@@ -327,7 +327,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq,
unsigned long pixel_clk,
}
static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,
- unsigned long pixel_clk)
+unsigned long pixel_clk)
{
unsigned int clk_n, clk_cts;
@@ -338,7 +338,7 @@ static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,
if (!clk_cts) {
dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-__func__, pixel_clk);
+ __func__, pixel_clk);
return;
}
@@ -477,13 +477,11 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi
*hdmi)
u16 coeff_b = (*csc_coeff)[1][i];
u16 coeff_c = (*csc_coeff)[2][i];
- hdmi_writeb(hdmi, coeff_a & 0xff,
- HDMI_CSC_COEF_A1_LSB + i * 2);
+ hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2);
hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2);
- hdmi_writeb(hdmi, coeff_c & 0xff,
- HDMI_CSC_COEF_C1_LSB + i * 2);
+ hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2);
}
@@ -535,21 +533,22 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data;
u8 val, vp_conf;
- if (hdmi_data->enc_out_format == RGB
- || hdmi_data->enc_out_format == YCBCR444) {
- if (!hdmi_data->enc_color_depth)
+ if (hdmi_data->enc_out_format == RGB ||
+ hdmi_data->enc_out_format == YCBCR444) {
+ if (!hdmi_data->enc_color_depth) {
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
- else if (hdmi_data->enc_color_depth == 8) {
+ } else if (hdmi_data->enc_color_depth == 8) {
color_depth = 4;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
- } else if (hdmi_data->enc_color_depth == 10)
+ } else if (hdmi_data->enc_color_depth == 10) {
color_depth = 5;
- else if (hdmi_data->enc_color_depth == 12)
+ } else if (hdmi_data->enc_color_depth == 12) {
color_depth = 6;
- else if (hdmi_data->enc_color_depth == 16)
+ } else if (hdmi_data->enc_color_depth == 16) {
color_depth = 7;
- else
+ } else {
return;
+ }
} else if (hdmi_data->enc_out_format == YCBCR422_8BITS) {
if (!hdmi_data->enc_color_depth ||
hdmi_data->enc_color_depth == 8)
@@ -561,8 +560,9 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
else
return;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422;
- } else
+ } else {
return;
+ }
/* set the packetizer registers */
val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -623,34 +623,34 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
}
static inline void hdmi_phy_test_clear(struct imx_hdmi *hdmi,
- unsigned char bit)
+
[PATCH v16 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
the original imx hdmi driver is under drm/imx/,
which depends on imx-drm, so move the imx hdmi
driver out to drm/bridge and rename it to dw_hdmi
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15:
- add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs
adviced by Philipp Zabel
- remove THIS_MODULE in platform driver
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile| 1 +
.../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 282 +++--
.../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 42 ---
drivers/gpu/drm/imx/Kconfig| 1 +
drivers/gpu/drm/imx/Makefile | 2 +-
.../drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c}| 127 +-
include/drm/bridge/dw_hdmi.h | 59 +
8 files changed, 271 insertions(+), 248 deletions(-)
rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (84%)
rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (98%)
rename drivers/gpu/drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c} (53%)
create mode 100644 include/drm/bridge/dw_hdmi.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..26162ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,8 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_DW_HDMI
+ bool "Synopsys DesignWare High-Definition Multimedia Interface"
+ depends on DRM
+ select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d8a8cfd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
similarity index 84%
rename from drivers/gpu/drm/imx/imx-hdmi.c
rename to drivers/gpu/drm/bridge/dw_hdmi.c
index 4ad6663..ac5f5e2 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -6,12 +6,11 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
- * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
- * for SLISHDMI13T and SLIPHDMIT IP cores
+ * Designware High-Definition Multimedia Interface (HDMI) driver
*
* Copyright (C) 2010, Guennadi Liakhovetski
*/
-
+#include
#include
#include
#include
@@ -24,8 +23,9 @@
#include
#include
#include
+#include
-#include "imx-hdmi.h"
+#include "dw_hdmi.h"
#define HDMI_EDID_LEN 512
@@ -101,18 +101,19 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
};
-struct imx_hdmi {
+struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
- enum imx_hdmi_devtype dev_type;
+ enum dw_hdmi_devtype dev_type;
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
struct hdmi_data_info hdmi_data;
- const struct imx_hdmi_plat_data *plat_data;
+ const struct dw_hdmi_plat_data *plat_data;
+
int vic;
u8 edid[HDMI_EDID_LEN];
@@ -129,17 +130,17 @@ struct imx_hdmi {
int ratio;
};
-static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
{
writeb(val, hdmi->regs + offset);
}
-static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset)
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
{
return readb(hdmi->regs + offset);
}
-static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
+static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
{
u8 val = hdmi_readb(hdmi, reg) & ~mask;
@@ -147,13 +148,13 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8
mask, unsigned reg)
hdmi_writeb(hdmi, val, reg);
}
-static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
+static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
u8 shift, u8 mask)
{
hdmi_modb(hdmi, data << shift, mask, reg);
}
-static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi,
+static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
unsigned int value)
{
hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
@@ -164,7 +165,7 @@ static void hdmi_set_clock_regenerator_n(struct imx_hdmi
*hdmi,
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> +int imx_hdmi_bind(struct device *dev, struct device *master,
> + void *data, struct drm_encoder *encoder,
> + const struct imx_hdmi_plat_data *plat_data)
> {
> struct platform_device *pdev = to_platform_device(dev);
> - const struct of_device_id *of_id =
> - of_match_device(imx_hdmi_dt_ids, dev);
> struct drm_device *drm = data;
> struct device_node *np = dev->of_node;
> struct device_node *ddc_node;
> @@ -1594,19 +1566,16 @@ static int imx_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> struct resource *iores;
> int ret, irq;
>
> - hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
> + hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
> if (!hdmi)
> return -ENOMEM;
>
> - hdmi->dev = dev;
> + hdmi->plat_data = plat_data;
> + hdmi->dev = &pdev->dev;
> + hdmi->dev_type = plat_data->dev_type;
> hdmi->sample_rate = 48000;
> hdmi->ratio = 100;
> -
> - if (of_id) {
> - const struct platform_device_id *device_id = of_id->data;
> -
> - hdmi->dev_type = device_id->driver_data;
> - }
> + hdmi->encoder = encoder;
I'd suggest changing imx_hdmi_bind() to take the struct resource and irq
number, and avoiding the platform device stuff altogether in here.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
Hi Bjorn,
> On Tue, Dec 2, 2014 at 8:46 PM, Bjorn Andersson wrote:
>> On Mon, Dec 1, 2014 at 1:56 PM, Jilai Wang
>> wrote:
>>> Add HDMI HDCP support including HDCP PartI/II/III authentication.
>>>
>>> Signed-off-by: Jilai Wang
>>> ---
>>
>> Hi Jilai,
>>
>> [..]
>>
>>> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
>>> b/drivers/gpu/drm/msm/hdmi/hdmi.c
>>
>> [..]
>>
>>>
>>> @@ -119,6 +137,22 @@ struct hdmi *hdmi_init(struct drm_device *dev,
>>> struct drm_encoder *encoder)
>>> goto fail;
>>> }
>>>
>>> + /* HDCP needs physical address of hdmi register */
>>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>> + config->mmio_name);
>>
>> Is this guaranteed to be available at all times? You should probably
>> do some error handling here.
>
> Hi Bjorn,
>
> (as mentioned on irc, but just repeating here for posterity)
>
> this is actually ok in this case, since the previous ioremap would have
> failed.
>
>>> + hdmi->mmio_phy_addr = res->start;
>>> +
>>> + if (config->qfprom_mmio_name) {
>>
>> Should this check really be here? This will always be set if CONFIG_OF
>> is set
>> and never otherwise and that seems strange to me.
>>
>> Perhaps you should add the string to the !CONFIG_OF platforms as well or
>> simply
>> add #ifdef CONFIG_OF around this section if that's what you really want.
>> (but
>> seems more like you forgot the non-of case).
>
> or just not cared enough to make HDCP (since it is optional) work on
> old pre-DT vendor kernel ;-)
>
> fwiw, eventually the !CONFIG_OF stuff will go away.. it just exists
> because some devices and some use-cases still need old downstream
> kernels :-(
>
>>> + hdmi->qfprom_mmio = msm_ioremap(pdev,
>>> + config->qfprom_mmio_name, "HDMI_QFPROM");
>>
>>
>> Is this a special hdmi qfprom or are you ioremapping _the_ qfprom here?
>>
>> If so I did suggest that we expose it as a syscon but I think Stephen
>> Boyd had
>> some other ideas.
>
> afaict (but Jilai can correct me), it is *the* qfprom.. that seems to
> be how things worked in android kernels. Some better mechanism would
> be really nice.
>
>>> + if (IS_ERR(hdmi->qfprom_mmio)) {
>>> + dev_info(&pdev->dev, "can't find qfprom
>>> resource\n");
>>> + hdmi->qfprom_mmio = NULL;
>>> + }
>>> + } else {
>>> + hdmi->qfprom_mmio = NULL;
>>
>> hdmi_qfprom_read() seems to be called and read from qfprom_mmio no
>> matter how
>> this ended. Are you sure this (both error paths) shouldn't be handled as
>> a
>> fatal error?
>
> hdmi_hdcp_init() fails (and then we continue without HDCP) if
> qfprom_mmio is NULL..
>
>> 'hdmi' is kzalloc and hence already NULL.
>>
>> [..]
>>
>>> @@ -205,6 +241,13 @@ struct hdmi *hdmi_init(struct drm_device *dev,
>>> struct drm_encoder *encoder)
>>> goto fail;
>>> }
>>>
>>> + hdmi->hdcp_ctrl = hdmi_hdcp_init(hdmi);
>>> + if (IS_ERR(hdmi->hdcp_ctrl)) {
>>> + ret = PTR_ERR(hdmi->hdcp_ctrl);
>>> + dev_warn(dev->dev, "failed to init hdcp:
>>> %d(disabled)\n", ret);
>>> + hdmi->hdcp_ctrl = NULL;
>>
>> So either you treat this as an error or you don't.
>>
>> If you're fine continuing execution without hdcp_ctrl then you shouldn't
>> set
>> ret. But in that case it you should probably not print a warning every
>> time you
>> enter hdmi_hdcp_on() and an error on hdmi_hdcp_off().
>
> agreed, I think it would be better for hdcp_on/off() to take struct
> hdmi_hdcp_ctrl as param (and just not be called if hdmi->hdcp_ctrl is
> null)
>
> [snip]
>
>> [..]
>>
>>> +
>>> +struct hdmi_hdcp_reg_data {
>>> + uint32_t reg_id;
>>
>> You should use u32 instead of uint32_t in the kernel.
>
> tbh, I'd prefer sticking to stdint types.. before stdint was a thing,
> u32 made sense
>
>>> + uint32_t off;
>>> + char *name;
>>> + uint32_t reg_val;
>>> +};
>>> +
>>> +struct hdmi_hdcp_ctrl {
>>> + struct hdmi *hdmi;
>>> + uint32_t auth_retries;
>>> + uint32_t tz_hdcp;
>>
>> Turn this into a bool named something like has_tz_hdcp instead, as
>> that's what
>> it really means.
>>
>>> + enum hdmi_hdcp_state hdcp_state;
>>> + struct mutex state_mutex;
>>> + struct delayed_work hdcp_reauth_work;
>>> + struct delayed_work hdcp_auth_part1_1_work;
>>> + struct delayed_work hdcp_auth_part1_2_work;
>>> + struct work_struct hdcp_auth_part1_3_work;
>>> + struct delayed_work hdcp_auth_part2_1_work;
>>> + struct delayed_work hdcp_auth_part2_2_work;
>>> + struct delayed_work hdcp_auth_part2_3_work;
>>> + struct delayed_work hdcp_auth_part2_4_work;
>>> + struct work_struct hdcp_auth_prepare_work;
>>
>> You shouldn't use "work" as a way to express states in your state
>> machine.
>> Better have 1 auth work function that does all these steps, probably
>> having
>> them split i
[PATCH v16 11/12] dt-bindings: Add documentation for rockchip dw hdmi
Signed-off-by: Andy Yan
---
Changes in v16:
- modify clocks bindings
- descrbie ddc-i2c-bus as optional
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- Add documentation for rockchip dw hdmi
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
new file mode 100644
index 000..264cb4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
@@ -0,0 +1,46 @@
+Rockchip specific extensions to the Synopsys Designware HDMI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-dw-hdmi";
+- reg: Physical base address and length of the controller's registers.
+- clocks: phandle to hdmi iahb and isrf clocks.
+- clock-names: should be "iahb" "isfr"
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- interrupts: HDMI interrupt number
+- ports: contain a port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. For
+ vopb,set the reg = <0> and set the reg = <1> for vopl.
+- reg-io-width: the width of the reg:1,4, the value should be 4 on
+ rk3288 platform
+
+Optional properties
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- clkocks, clock-names: phandle to the HDMI cec clock, name should be "cec"
+
+Example:
+hdmi: hdmi at ff98 {
+ compatible = "rockchip,rk3288-dw-hdmi";
+ reg = <0xff98 0x2>;
+ reg-io-width = <4>;
+ ddc-i2c-bus = <&i2c5>;
+ rockchip,grf = <&grf>;
+ interrupts = ;
+ clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
+ clock-names = "iahb", "isfr";
+ status = "disabled";
+ ports {
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_hdmi>;
+ };
+ hdmi_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_hdmi>;
+ };
+ };
+ };
+};
--
1.9.1
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
On 2014å¹´12æ03æ¥ 02:23, Philipp Zabel wrote:
> Hi Andy,
>
> Am Dienstag, den 02.12.2014, 15:42 +0800 schrieb Andy Yan:
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> new file mode 100644
>> index 000..107c1ca
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> @@ -0,0 +1,40 @@
>> +DesignWare HDMI bridge bindings
>> +
>> +Required properities:
>> +- compatible: platform specific such as:
>> + * "fsl,imx6q-hdmi"
>> + * "fsl,imx6dl-hdmi"
>> + * "rockchip,rk3288-dw-hdmi"
> I think we should add a common compatible value "snps,dw-hdmi-tx" here:
>
> compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx";
>
>> +- reg: Physical base address and length of the controller's registers.
>> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> Better make ddc-i2c-bus optional, see the other thread about the ddc i2c
> master.
I have the same idea too, but the patch about ddc i2c master has not
landed yet, can we change the ddc-i2c-bus to optional after the ddc
i2c master
patch land?
>> +- interrupts: The HDMI interrupt number
>> +
>> +Optional properties
>> +- reg-io-width: the width of the reg:1,4, default set to 1 if not present
>> +
>> +Example:
>> +hdmi: hdmi at 012 {
>> +compatible = "fsl,imx6q-hdmi";
>> +reg = <0x0012 0x9000>;
>> +interrupts = <0 115 0x04>;
>> +gpr = <&gpr>;
>> +clocks = <&clks 123>, <&clks 124>;
>> +clock-names = "iahb", "isfr";
>> +ddc-i2c-bus = <&i2c2>;
>> +
>> +port at 0 {
>> +reg = <0>;
>> +
>> +hdmi_mux_0: endpoint {
>> +remote-endpoint = <&ipu1_di0_hdmi>;
>> +};
>> +};
>> +
>> +port at 1 {
>> +reg = <1>;
>> +
>> +hdmi_mux_1: endpoint {
>> +remote-endpoint = <&ipu1_di1_hdmi>;
>> +};
>> +};
>> +};
> regards
> Philipp
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
[PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Hi Philipp:
On 2014å¹´12æ02æ¥ 21:00, Philipp Zabel wrote:
> Hi Andy,
>
> Am Dienstag, den 02.12.2014, 20:34 +0800 schrieb Andy Yan:
>> Hi Philipp:
>> On 2014å¹´12æ02æ¥ 18:24, Philipp Zabel wrote:
>>> Hi Andy,
>>>
>>> Am Dienstag, den 02.12.2014, 15:45 +0800 schrieb Andy Yan:
>>> [...]
+static int dw_hdmi_rockchip_bind(struct device *dev, struct device
*master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct dw_hdmi_plat_data *plat_data;
+ const struct of_device_id *match;
+ struct drm_device *drm = data;
+ struct drm_encoder *encoder;
+ struct rockchip_hdmi *hdmi;
+ int ret;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
+ if (!hdmi)
+ return -ENOMEM;
+
+ match = of_match_node(dw_hdmi_rockchip_ids, pdev->dev.of_node);
+ plat_data = match->data;
+ hdmi->dev = &pdev->dev;
+ encoder = &hdmi->encoder;
+ platform_set_drvdata(pdev, hdmi);
+
+ ret = rockchip_hdmi_parse_dt(hdmi);
+ if (ret) {
+ dev_err(hdmi->dev, "Unable to parse OF data\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(hdmi->clk);
+ if (ret) {
+ dev_err(hdmi->dev, "Cannot enable HDMI clock: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(hdmi->hdcp_clk);
+ if (ret) {
+ dev_err(hdmi->dev, "Cannot enable HDMI hdcp clock: %d\n", ret);
+ return ret;
+ }
>>> Could we have a look at the clocks again? Basically the Rockchip clock
>>> handling is exactly the same, except the clocks are called by other
>>> names.
>>>
>>> On i.MX6, according to the reference manual, the HDMI TX module has four
>>> clock inputs: "iahbclk" (bus clock), "icecclk" (32 kHz CEC clock),
>>> "ihclk" (module clock), and "isfrclk" (27 MHz internal SFR clock).
>>> The "iahbclk" and "ihclk" are both sourced from the SoC AHB root clock,
>>> the 32 kHz reference input can't be gated, and the "isfrclk" has its own
>>> gate.
>>>
>>> Does the HDMI TX implementation on Rockchip still have the separate
>>> external sfr bus and module clock inputs? I assume that your "clk" input
>>> is a single gate bit for bus and module clocks at the same time?
>>> If possible, I'd prefer to find a common binding for the clocks with
>>> some of the clocks being optional, but for that we need to know the
>>> actual clock inputs to the HDMI TX module.
>>>
>>> regards
>>> Philipp
>>>
>> There are three individual clock inputs on Rockchip RK3288 HDMI:
>> "hdmi_ctrl_clk",
>> "hdmi_cec_clk", "hdmi_hdcp_clk", the three clocks are responsible
>> for different
>>functions as their name described, and have their own private gate
>> bit. That is
>>to say, the cec_clk and hdcp_clk can all be disabled if we don't
>> need hdcp and cec
>>function.
>>So I think it's better to make the clk control platform independent.
> My question is not about the available gates at the SoC level, but about
> the actual clock inputs from point of view of the HDMI TX IP.
>
> It could be that the hdmi_ctrl_clk gates all inputs to the module and
> bus clocks together. If so, you could just reuse "isfr" and "iahb" and
> set it to the same clock. If not, we'd need to think of something else.
> Unfortunately I don't have any Synopsys documentation of the HDMI TX at
> that level.
After confirming with the IC designer, we finally make clear that
Rockchip RK3288 almost use the same clock design with imx:
clk-iahbclk, used for hdmi module and bus
hdcp_clk-isfrclk, used for hdcp and i2cm
cecclk -cecclk, but this clk can be gated on rockchip, this is
different with imx,
but we don't handle the cec stuff now. So i will try to reuse the
imx clk binds. do you
think that is ok?
> regards
> Philipp
>
>
>
>
[PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Hi Andy,
Am Mittwoch, den 03.12.2014, 20:32 +0800 schrieb Andy Yan:
> > My question is not about the available gates at the SoC level, but about
> > the actual clock inputs from point of view of the HDMI TX IP.
> >
> > It could be that the hdmi_ctrl_clk gates all inputs to the module and
> > bus clocks together. If so, you could just reuse "isfr" and "iahb" and
> > set it to the same clock. If not, we'd need to think of something else.
> > Unfortunately I don't have any Synopsys documentation of the HDMI TX at
> > that level.
>
> After confirming with the IC designer, we finally make clear that
> Rockchip RK3288 almost use the same clock design with imx:
> clk-iahbclk, used for hdmi module and bus
> hdcp_clk-isfrclk, used for hdcp and i2cm
> cecclk -cecclk, but this clk can be gated on rockchip, this is
> different with imx,
> but we don't handle the cec stuff now. So i will try to reuse the
> imx clk binds. do you
>think that is ok?
Thank you for taking the time to verify this. So we should move the
clock handling out of the soc specific parts into the common driver and
reuse the existing clock bindings ("iahb", "isfr").
I'd suggest to add the "cec" clock now to the binding document as an
optional clock, then you can already specify it in the rockchip dtsi.
regards
Philipp
[PATCH v15 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Hi Philipp:
On 2014å¹´12æ03æ¥ 21:09, Philipp Zabel wrote:
> Hi Andy,
>
> Am Mittwoch, den 03.12.2014, 20:32 +0800 schrieb Andy Yan:
>>> My question is not about the available gates at the SoC level, but about
>>> the actual clock inputs from point of view of the HDMI TX IP.
>>>
>>> It could be that the hdmi_ctrl_clk gates all inputs to the module and
>>> bus clocks together. If so, you could just reuse "isfr" and "iahb" and
>>> set it to the same clock. If not, we'd need to think of something else.
>>> Unfortunately I don't have any Synopsys documentation of the HDMI TX at
>>> that level.
>> After confirming with the IC designer, we finally make clear that
>> Rockchip RK3288 almost use the same clock design with imx:
>> clk-iahbclk, used for hdmi module and bus
>> hdcp_clk-isfrclk, used for hdcp and i2cm
>> cecclk -cecclk, but this clk can be gated on rockchip, this is
>> different with imx,
>> but we don't handle the cec stuff now. So i will try to reuse the
>> imx clk binds. do you
>> think that is ok?
> Thank you for taking the time to verify this. So we should move the
> clock handling out of the soc specific parts into the common driver and
> reuse the existing clock bindings ("iahb", "isfr").
> I'd suggest to add the "cec" clock now to the binding document as an
> optional clock, then you can already specify it in the rockchip dtsi.
ok
>
> regards
> Philipp
>
>
>
[PATCH v16 02/12] drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
drm driver may probe before the i2c bus, so the driver should
defer probing until it is available
Signed-off-by: Andy Yan
Reviewed-by: Daniel Kurtz
---
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12:
- refactor of_node_put(ddc_node)
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter
Changes in v3: None
drivers/gpu/drm/imx/imx-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index 7fd90ae..7a54d20 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -1611,10 +1611,12 @@ static int imx_hdmi_bind(struct device *dev, struct
device *master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
- if (!hdmi->ddc)
+ of_node_put(ddc_node);
+ if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
+ return -EPROBE_DEFER;
+ }
- of_node_put(ddc_node);
} else {
dev_dbg(hdmi->dev, "no ddc property found\n");
}
--
1.9.1
[PATCH v16 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver
hdmi phy configuration is platform specific, which can be adusted
according to the board to get the best SI
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13:
- split phy configuration from patch#4
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/imx/imx-hdmi.c | 85 +++-
drivers/gpu/drm/imx/imx-hdmi.h | 29
drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 57
3 files changed, 101 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index a7c1ec7..4ad6663 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -713,76 +713,14 @@ static void imx_hdmi_phy_sel_interface_control(struct
imx_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
-enum {
- RES_8,
- RES_10,
- RES_12,
- RES_MAX,
-};
-
-struct mpll_config {
- unsigned long mpixelclock;
- struct {
- u16 cpce;
- u16 gmp;
- } res[RES_MAX];
-};
-
-static const struct mpll_config mpll_config[] = {
- {
- 4525, {
- { 0x01e0, 0x },
- { 0x21e1, 0x },
- { 0x41e2, 0x }
- },
- }, {
- 9250, {
- { 0x0140, 0x0005 },
- { 0x2141, 0x0005 },
- { 0x4142, 0x0005 },
- },
- }, {
- 14850, {
- { 0x00a0, 0x000a },
- { 0x20a1, 0x000a },
- { 0x40a2, 0x000a },
- },
- }, {
- ~0UL, {
- { 0x00a0, 0x000a },
- { 0x2001, 0x000f },
- { 0x4002, 0x000f },
- },
- }
-};
-
-struct curr_ctrl {
- unsigned long mpixelclock;
- u16 curr[RES_MAX];
-};
-
-static const struct curr_ctrl curr_ctrl[] = {
- /* pixelclk bpp8bpp10 bpp12 */
- {
-5400, { 0x091c, 0x091c, 0x06dc },
- }, {
-5840, { 0x091c, 0x06dc, 0x06dc },
- }, {
-7200, { 0x06dc, 0x06dc, 0x091c },
- }, {
-7425, { 0x06dc, 0x0b5c, 0x091c },
- }, {
- 11880, { 0x091c, 0x091c, 0x06dc },
- }, {
- 21600, { 0x06dc, 0x0b5c, 0x091c },
- }
-};
-
static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep,
unsigned char res, int cscon)
{
unsigned res_idx, i;
u8 val, msec;
+ const struct mpll_config *mpll_config = hdmi->plat_data->mpll_cfg;
+ const struct curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr;
+ const struct sym_term *sym_term = hdmi->plat_data->sym_term;
if (prep)
return -EINVAL;
@@ -828,7 +766,7 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi,
unsigned char prep,
hdmi_phy_test_clear(hdmi, 0);
/* PLL/MPLL Cfg - always match on final entry */
- for (i = 0; i < ARRAY_SIZE(mpll_config) - 1; i++)
+ for (i = 0; mpll_config[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
mpll_config[i].mpixelclock)
break;
@@ -836,12 +774,12 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi,
unsigned char prep,
hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].cpce, 0x06);
hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].gmp, 0x15);
- for (i = 0; i < ARRAY_SIZE(curr_ctrl); i++)
+ for (i = 0; curr_ctrl[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
curr_ctrl[i].mpixelclock)
break;
- if (i >= ARRAY_SIZE(curr_ctrl)) {
+ if (curr_ctrl[i].mpixelclock == (~0UL)) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
hdmi->hdmi_data.video_mode.mpixelclock);
return -EINVAL;
@@ -852,10 +790,17 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi,
unsigned char prep,
hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
+
+ for (i = 0; sym_term[i].mpixelclock != (~0UL); i++)
+ if (hdmi->hdmi_data.video_mode.mpixelclock <=
+ sym_term[i].mpixelclock)
+ break;
+
/* RESISTANCE TERM 133Ohm Cfg */
- hdmi_phy_i2c_write(hdmi, 0x0005, 0x19); /* TXTERM */
+ hdmi_phy_i2c_write(hdmi, sym_term[i].term, 0x19); /* TXTERM */
[PATCH v16 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width accesses (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15:
- remove unio of the multi-byte register access, adviced by Philipp Zabel
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- refactor register access without reg_shift
Changes in v5:
- refactor reg-io-width
Changes in v4: None
Changes in v3:
- split multi-register access to one indepent patch
drivers/gpu/drm/bridge/dw_hdmi.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index ac5f5e2..d2c6ba8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -128,18 +128,41 @@ struct dw_hdmi {
unsigned int sample_rate;
int ratio;
+
+ void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+ u8 (*read)(struct dw_hdmi *hdmi, int offset);
};
-static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+ writel(val, hdmi->regs + (offset << 2));
+}
+
+static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
+{
+ return readl(hdmi->regs + (offset << 2));
+}
+
+static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
{
writeb(val, hdmi->regs + offset);
}
-static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
+static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
{
return readb(hdmi->regs + offset);
}
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+ hdmi->write(hdmi, val, offset);
+}
+
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
+{
+ return hdmi->read(hdmi, offset);
+}
+
static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
{
u8 val = hdmi_readb(hdmi, reg) & ~mask;
@@ -1512,6 +1535,7 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
struct dw_hdmi *hdmi;
struct resource *iores;
int ret, irq;
+ u32 val = 1;
hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
@@ -1524,6 +1548,22 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
hdmi->ratio = 100;
hdmi->encoder = encoder;
+ of_property_read_u32(np, "reg-io-width", &val);
+
+ switch (val) {
+ case 4:
+ hdmi->write = dw_hdmi_writel;
+ hdmi->read = dw_hdmi_readl;
+ break;
+ case 1:
+ hdmi->write = dw_hdmi_writeb;
+ hdmi->read = dw_hdmi_readb;
+ break;
+ default:
+ dev_err(dev, "reg-io-width must be 1 or 4\n");
+ return -EINVAL;
+ }
+
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
--
1.9.1
[PATCH v16 09/12] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm
operation status(i2c transfer done or error), every hdmi phy register
configuration must check this register to make sure the configuration
has complete. But the indication bit should be cleared after check, otherwise
the corresponding bit will hold on forever, this may give a wrong signal for
next check.
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/dw_hdmi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index e3999da..e53dae0 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -666,11 +666,15 @@ static inline void hdmi_phy_test_dout(struct dw_hdmi
*hdmi,
static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
{
- while ((hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
+ u32 val;
+
+ while ((val = hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
if (msec-- == 0)
return false;
udelay(1000);
}
+ hdmi_writeb(hdmi, val, HDMI_IH_I2CMPHY_STAT0);
+
return true;
}
--
1.9.1
[PATCH v16 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Rockchip RK3288 hdmi is compatible with dw_hdmi
this patch is depend on patch by Mark Yao
see https://lkml.org/lkml/2014/12/2/161
drm: rockchip: Add basic drm driver
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15:
- remove THIS_MODULE in platform driver
Changes in v14: None
Changes in v13: None
Changes in v12:
- add comment for the depend on patch
Changes in v11: None
Changes in v10:
- add more display mode support mpll configuration for rk3288
Changes in v9:
- move some phy configuration to platform driver
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/dw_hdmi.c| 3 +
drivers/gpu/drm/rockchip/Kconfig| 10 +
drivers/gpu/drm/rockchip/Makefile | 2 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 321
include/drm/bridge/dw_hdmi.h| 1 +
5 files changed, 337 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index efc3b6f..1d5a6b3 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -852,6 +852,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
+ if (hdmi->dev_type == RK3288_HDMI)
+ dw_hdmi_phy_enable_spare(hdmi, 1);
+
/*Wait for PHY PLL lock */
msec = 5;
do {
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ca9f085..6ebebe8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -15,3 +15,13 @@ config DRM_ROCKCHIP
management to userspace. This driver does not provide
2D or 3D acceleration; acceleration is performed by other
IP found on the SoC.
+
+config ROCKCHIP_DW_HDMI
+bool "Rockchip specific extensions for Synopsys DW HDMI"
+depends on DRM_ROCKCHIP
+select DRM_DW_HDMI
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Synopsys DesignWare HDMI driver. If you want to
+ enable HDMI on RK3288 based SoC, you should selet this
+ option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 2cb0672..beed7df 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -5,4 +5,6 @@
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
new file mode 100644
index 000..3369a7e
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -0,0 +1,321 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define GRF_SOC_CON60x025c
+#define HDMI_SEL_VOP_LIT(1 << 4)
+
+struct rockchip_hdmi {
+ struct device *dev;
+ struct regmap *regmap;
+ struct drm_encoder encoder;
+};
+
+#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
+
+static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
+ {
+ 2700, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 3600, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 4000, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 5400, {
+ { 0x0072, 0x0001},
+ { 0x2142, 0x0001},
+ { 0x40a2, 0x0001},
+ },
+ }, {
+ 6500, {
+ { 0x0072, 0x0001},
+ { 0x2142, 0x0001},
+ { 0x40a2, 0x0001},
+ },
+ }, {
+ 6600, {
+ { 0x013e, 0x0003},
+ { 0x217e, 0x0002},
+
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
Hi Andy,
Am Donnerstag, den 04.12.2014, 00:04 +0800 schrieb Andy Yan:
> On 2014å¹´12æ03æ¥ 23:38, Russell King - ARM Linux wrote:
> > On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> >> +int imx_hdmi_bind(struct device *dev, struct device *master,
> >> +void *data, struct drm_encoder *encoder,
> >> +const struct imx_hdmi_plat_data *plat_data)
> >> {
> >>struct platform_device *pdev = to_platform_device(dev);
> >> - const struct of_device_id *of_id =
> >> - of_match_device(imx_hdmi_dt_ids, dev);
> >>struct drm_device *drm = data;
> >>struct device_node *np = dev->of_node;
> >>struct device_node *ddc_node;
> >> @@ -1594,19 +1566,16 @@ static int imx_hdmi_bind(struct device *dev,
> >> struct device *master, void *data)
> >>struct resource *iores;
> >>int ret, irq;
> >>
> >> - hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
> >> + hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
> >>if (!hdmi)
> >>return -ENOMEM;
> >>
> >> - hdmi->dev = dev;
> >> + hdmi->plat_data = plat_data;
> >> + hdmi->dev = &pdev->dev;
> >> + hdmi->dev_type = plat_data->dev_type;
> >>hdmi->sample_rate = 48000;
> >>hdmi->ratio = 100;
> >> -
> >> - if (of_id) {
> >> - const struct platform_device_id *device_id = of_id->data;
> >> -
> >> - hdmi->dev_type = device_id->driver_data;
> >> - }
> >> + hdmi->encoder = encoder;
> > I'd suggest changing imx_hdmi_bind() to take the struct resource and irq
> > number, and avoiding the platform device stuff altogether in here.
> >
> Actually this is what the current code do: the resource and irq number
> are all handled in imx_hdmi_bind
It would be better if the bind function would not have to care about
platform resources, that should be handled in the probe function. I had
a patch to move them:
http://lists.freedesktop.org/archives/dri-devel/2014-May/059630.html
Maybe you could incorporate something like this?
regards
Philipp
[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support
> On Wed, Dec 3, 2014 at 9:16 AM, wrote: > [..] > + enum hdmi_hdcp_state hdcp_state; > + struct mutex state_mutex; > + struct delayed_work hdcp_reauth_work; > + struct delayed_work hdcp_auth_part1_1_work; > + struct delayed_work hdcp_auth_part1_2_work; > + struct work_struct hdcp_auth_part1_3_work; > + struct delayed_work hdcp_auth_part2_1_work; > + struct delayed_work hdcp_auth_part2_2_work; > + struct delayed_work hdcp_auth_part2_3_work; > + struct delayed_work hdcp_auth_part2_4_work; > + struct work_struct hdcp_auth_prepare_work; You shouldn't use "work" as a way to express states in your state machine. Better have 1 auth work function that does all these steps, probably having them split in functions just like you do now. That way you can have 1 function running the pass of authentication, starting by checking if you're reauthing or not then processing each step one by one, sleeping inbetween them. You can have the functions return -EAGAIN to indicate that you need to retry the current operation and so on. This would split the state machine from the state executioners and simplify your code. >>> >>> As a side note (disclaimer, I'm not an hdcp expert), but I wonder if >>> eventually some of that should be extracted out into some helpers in >>> drm core. I guess that is something we'll figure out when a 2nd >>> driver gains upstream HDCP support. One big work w/ msleep()'s does >>> sound like it would be easier to understand (and therefore easier to >>> refactor out into helpers). >>> >>> [snip] >>> >> >> The reason that I break the partI/PartII work into these small works >> because I want to avoid to use msleep in work. >> Otherwise cancel a HDCP work may cause long delay up to several seconds. >> > > I definitely think the steps are nice size and make things easy to > understand. > > If you make the steps that require a retry return out to the main > state handling function with a -EAGAIN, then you can have check if you > should retry or abort based on cancellation. Giving you the worst case > cancellation time of the longest sleep... > > As Rob suggest you could use wait_event_timeout() or something to > improve this, but on the other hand the worst case here seems to be > the HZ/2 after prepare_auth; others are HZ/8, HZ/20 and HZ/50; not > "seconds". > > So I would start with a simple msleep() for implementation simplicity > and then enhance that in a follow up commit (if needed)... > > Regards, > Bjorn > The worst wait time could be 5 seconds if the downstream device is a REPEATER. The maximum retry time is set to 100 and the delay for each time is HZ/20, then the maximum wait time before abort will be 5 seconds. As you suggested, I can use the flag to notify the retry process to abort earlier in case this work needs to be canceled which can reduce the delay to HZ/20 then. Or as Rob's suggestion to wait for hpd event. Thanks, Jilai
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.
To reuse the imx hdmi driver, convert it to drm_bridge
handle encoder in imx-hdmi_pltfm.c, as most of the encoder
operation are platform specific such as crtc select and
panel format set
This patch depends on Russell King's patch:
drm: imx: convert imx-drm to use the generic DRM OF helper
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-July/053484.html
Signed-off-by: Andy Yan
Signed-off-by: Yakir Yang
---
Changes in v16:
- use the common binding for the clocks
Changes in v15: None
Changes in v14:
- add defer probing, adviced by Philipp Zabel
Changes in v13:
- split platform specific phy configuration
Changes in v12:
- squash patch
Changes in v11:
- squash patch
Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)
Changes in v9: None
Changes in v8: None
Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/imx/Makefile | 2 +-
drivers/gpu/drm/imx/imx-hdmi.c | 252 +--
drivers/gpu/drm/imx/imx-hdmi.h | 14 ++
drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 193 +++
4 files changed, 304 insertions(+), 157 deletions(-)
create mode 100644 drivers/gpu/drm/imx/imx-hdmi_pltfm.c
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..63cf56a 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o
obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
-obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o imx-hdmi_pltfm.o
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index 7a54d20..a7c1ec7 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -12,25 +12,20 @@
* Copyright (C) 2010, Guennadi Liakhovetski
*/
-#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
#include
+#include
#include
#include
#include
#include
-#include
#include "imx-hdmi.h"
-#include "imx-drm.h"
#define HDMI_EDID_LEN 512
@@ -54,11 +49,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
};
-enum imx_hdmi_devtype {
- IMX6Q_HDMI,
- IMX6DL_HDMI,
-};
-
static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -113,7 +103,8 @@ struct hdmi_data_info {
struct imx_hdmi {
struct drm_connector connector;
- struct drm_encoder encoder;
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
enum imx_hdmi_devtype dev_type;
struct device *dev;
@@ -121,6 +112,7 @@ struct imx_hdmi {
struct clk *iahb_clk;
struct hdmi_data_info hdmi_data;
+ const struct imx_hdmi_plat_data *plat_data;
int vic;
u8 edid[HDMI_EDID_LEN];
@@ -137,13 +129,6 @@ struct imx_hdmi {
int ratio;
};
-static void imx_hdmi_set_ipu_di_mux(struct imx_hdmi *hdmi, int ipu_di)
-{
- regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
- IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
- ipu_di << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
-}
-
static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
{
writeb(val, hdmi->regs + offset);
@@ -1371,6 +1356,50 @@ static void imx_hdmi_poweroff(struct imx_hdmi *hdmi)
imx_hdmi_phy_disable(hdmi);
}
+static void imx_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+ struct imx_hdmi *hdmi = bridge->driver_private;
+
+ imx_hdmi_setup(hdmi, mode);
+
+ /* Store the display mode for plugin/DKMS poweron events */
+ memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
+}
+
+static bool imx_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static void imx_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+ struct imx_hdmi *hdmi = bridge->driver_private;
+
+ imx_hdmi_poweroff(hdmi);
+}
+
+static void imx_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+ struct imx_hdmi *hdmi = bridge->driver_private;
+
+ imx_hdmi_poweron(hdmi);
+
[PATCH v16 06/12] dt-bindings: add document for dw_hdmi
Signed-off-by: Andy Yan
---
Changes in v16:
- describe ddc-i2c-bus as optional
- add common clocks bindings
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/drm/bridge/dw_hdmi.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
new file mode 100644
index 000..fb14730
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -0,0 +1,45 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatible: platform specific such as:
+ * "snps,dw-hdmi-tx"
+ * "fsl,imx6q-hdmi"
+ * "fsl,imx6dl-hdmi"
+ * "rockchip,rk3288-dw-hdmi"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The HDMI interrupt number
+- clocks, clock-names : must have the phandles to the HDMI iahb and isrf
clocks,
+ as described in Documentation/devicetree/bindings/clock/clock-bindings.txt,
+ the clock-names should be "iahb", "isfr"
+
+Optional properties
+- reg-io-width: the width of the reg:1,4, default set to 1 if not present
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- clkocks, clock-names: phandle to the HDMI cec clock, name should be "cec"
+
+Example:
+ hdmi: hdmi at 012 {
+ compatible = "fsl,imx6q-hdmi";
+ reg = <0x0012 0x9000>;
+ interrupts = <0 115 0x04>;
+ gpr = <&gpr>;
+ clocks = <&clks 123>, <&clks 124>;
+ clock-names = "iahb", "isfr";
+ ddc-i2c-bus = <&i2c2>;
+
+ port at 0 {
+ reg = <0>;
+
+ hdmi_mux_0: endpoint {
+ remote-endpoint = <&ipu1_di0_hdmi>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ hdmi_mux_1: endpoint {
+ remote-endpoint = <&ipu1_di1_hdmi>;
+ };
+ };
+ };
--
1.9.1
[PATCH v16 08/12] drm: bridge/dw_hdmi: add mode_valid support
some platform may not support all the display mode,
add mode_valid interface check it
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15: None
Changes in v14:
- remove drm_connector_register, because imx-drm core has registered
connector
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/dw_hdmi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index d2c6ba8..e3999da 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1405,6 +1405,20 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
return 0;
}
+static enum drm_mode_status
+dw_hdmi_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+ struct dw_hdmi *hdmi = container_of(connector,
+ struct dw_hdmi, connector);
+ enum drm_mode_status mode_status = MODE_OK;
+
+ if (hdmi->plat_data->mode_valid)
+ mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+ return mode_status;
+}
+
static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector
*connector)
{
@@ -1429,6 +1443,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs
= {
static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
+ .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
};
--
1.9.1
[PATCH v16 10/12] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
RK3288 HDMI will not work without the spare bit of
HDMI_PHY_CONF0 enable
Signed-off-by: Andy Yan
---
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/dw_hdmi.c | 7 +++
drivers/gpu/drm/bridge/dw_hdmi.h | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index e53dae0..efc3b6f 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -713,6 +713,13 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi,
u8 enable)
HDMI_PHY_CONF0_ENTMDS_MASK);
}
+static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
+{
+ hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
+HDMI_PHY_CONF0_SPARECTRL_OFFSET,
+HDMI_PHY_CONF0_SPARECTRL_MASK);
+}
+
static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index baa7849..175dbc8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -837,7 +837,8 @@ enum {
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
- HDMI_PHY_CONF0_SPARECTRL = 0x20,
+ HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
+ HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
--
1.9.1
[PATCH v16 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
On Wed, Dec 03, 2014 at 11:32:12PM +0800, Andy Yan wrote: > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 884923f..26162ef 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -3,3 +3,8 @@ config DRM_PTN3460 > depends on DRM > select DRM_KMS_HELPER > ---help--- > + > +config DRM_DW_HDMI > + bool "Synopsys DesignWare High-Definition Multimedia Interface" > + depends on DRM > + select DRM_KMS_HELPER ... > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 82fb758..7070077 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -48,6 +48,7 @@ config DRM_IMX_IPUV3 > > config DRM_IMX_HDMI > tristate "Freescale i.MX DRM HDMI" > + select DRM_DW_HDMI > depends on DRM_IMX > help > Choose this if you want to use HDMI on i.MX6. I'd recommend that if you want to select DRM_DW_HDMI, then don't give DRM_DW_HDMI a prompt message. I assume you're going to do something similar with your Rockchip driver too - in which case DRM_DW_HDMI is really about building a library module. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
On Thu, Dec 04, 2014 at 12:04:37AM +0800, Andy Yan wrote:
> Hi Russell:
>
> On 2014å¹´12æ03æ¥ 23:38, Russell King - ARM Linux wrote:
> >On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> >>+int imx_hdmi_bind(struct device *dev, struct device *master,
> >>+ void *data, struct drm_encoder *encoder,
> >>+ const struct imx_hdmi_plat_data *plat_data)
> >> {
> >>struct platform_device *pdev = to_platform_device(dev);
> >>- const struct of_device_id *of_id =
> >>- of_match_device(imx_hdmi_dt_ids, dev);
> >>struct drm_device *drm = data;
> >>struct device_node *np = dev->of_node;
> >>struct device_node *ddc_node;
> >>@@ -1594,19 +1566,16 @@ static int imx_hdmi_bind(struct device *dev, struct
> >>device *master, void *data)
> >>struct resource *iores;
> >>int ret, irq;
> >>- hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
> >>+ hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
> >>if (!hdmi)
> >>return -ENOMEM;
> >>- hdmi->dev = dev;
> >>+ hdmi->plat_data = plat_data;
> >>+ hdmi->dev = &pdev->dev;
> >>+ hdmi->dev_type = plat_data->dev_type;
> >>hdmi->sample_rate = 48000;
> >>hdmi->ratio = 100;
> >>-
> >>- if (of_id) {
> >>- const struct platform_device_id *device_id = of_id->data;
> >>-
> >>- hdmi->dev_type = device_id->driver_data;
> >>- }
> >>+ hdmi->encoder = encoder;
> >I'd suggest changing imx_hdmi_bind() to take the struct resource and irq
> >number, and avoiding the platform device stuff altogether in here.
> >
>Actually this is what the current code do: the resource and irq number
> are all handled in imx_hdmi_bind
I meant that imx_hdmi_bind should be passed these, so that it needs to
know nothing about the struct device beyond the generic device structure.
In other words, the dw-hdmi core should not assume that the struct device
is part of a platform device.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
On Wed, Dec 03, 2014 at 05:20:15PM +0100, Philipp Zabel wrote: > Hi Andy, > > It would be better if the bind function would not have to care about > platform resources, that should be handled in the probe function. I had > a patch to move them: > > http://lists.freedesktop.org/archives/dri-devel/2014-May/059630.html > > Maybe you could incorporate something like this? Personally, I hate this idea. Having a two-layered setup means that the when the bind() method is called, the state of struct imx_hdmi is indeterminant. If it's called immediately from probe, most of the structure will be zeroed, and only those members initialised by the probe function will be set to non-zero values. However, if the HDMI interface has been previously bound, and is subsequently re-bound, then the structure will most definitely no longer be in a known state on the second bind() call. This is fragile. Now, people have tried to tell me that this isn't fragile, but, I now have proof that it is as fragile as I fear. The component helper doesn't yet have that many users, and already we have one user (okay, it's not part of the mainline kernel - it's etnaviv) which contained exactly this kind of bug: it expected its private structures to be zeroed on the bind() call. So, I /really/ hate this idea. If you really want to do this, then please ensure that the bind() call explicitly zeros the bits of the struct which aren't initialised by the probe() call, so we know that the driver will always start off with a known initial state. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
On Thu, Dec 04, 2014 at 12:30:23AM +0800, Andy Yan wrote: > > On 2014å¹´12æ04æ¥ 00:11, Russell King - ARM Linux wrote: > >I meant that imx_hdmi_bind should be passed these, so that it needs to > >know nothing about the struct device beyond the generic device structure. > >In other words, the dw-hdmi core should not assume that the struct device > >is part of a platform device. > > >if so, how about the device tree properties ddc-i2c-bus, reg-io-width, > iahb, isfr, > they are all found by device? If the device has a device tree node associated with it, it will have a non-NULL dev->of_node - which is part of the generic device structure. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[PATCH v15 06/12] dt-bindings: add document for dw_hdmi
Hi Andy, Am Mittwoch, den 03.12.2014, 08:54 +0800 schrieb Andy Yan: > >> +Required properities: > >> +- compatible: platform specific such as: > >> + * "fsl,imx6q-hdmi" > >> + * "fsl,imx6dl-hdmi" > >> + * "rockchip,rk3288-dw-hdmi" > > I think we should add a common compatible value "snps,dw-hdmi-tx" here: > > > > compatible = "fsl,imx6q-hdmi", "snps,dw-hdmi-tx"; > > > How about "snps,dw-hdmi", because the driver is not only about >hdmi tx, but also include hdmi phy. Synopsys call the whole module "DesignWare HDMI Transmitter (TX) IP Solution": https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_14_csds_tx https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_20_csds_tx That includes the PHY. I'd prefer keeping the -tx in there to differentiate from a possible future "snps,dw-hdmi-rx": https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_14_csds_rx https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_20_csds_rx >If we add such compatible value, do we have to implement another > platform driver like dw_hdmi-pltfm.c with the > compatible="snps,dw-hdmi" , > or just include the compatible value in dw_hdmi-imx.c and > dw_hdmi-rockchip.c? That common compatible doesn't have to be used by any driver. It's just there to show these are the same/similar IP core. If a common driver without any SoC specific knowledge could be written, that one would match against the common compatible. regards Philipp
[PATCH] amdkfd: use sizeof(long) granularity for the pasid bitmask
All the bit operations (such as find_first_zero_bit()) read sizeof(long) bytes
at a time. If we allocated less than sizeof(long) bytes for the bitmask we
would be accessing invalid memory when working with the bitmask.
Change the allocator to allocate sizeof(long) multiples for the bitmask.
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_pasid.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
b/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
index 2458ab7..71699ad 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_pasid.c
@@ -32,8 +32,7 @@ int kfd_pasid_init(void)
{
pasid_limit = max_num_of_processes;
- pasid_bitmap = kzalloc(DIV_ROUND_UP(pasid_limit, BITS_PER_BYTE),
- GFP_KERNEL);
+ pasid_bitmap = kzalloc(BITS_TO_LONGS(pasid_limit), GFP_KERNEL);
if (!pasid_bitmap)
return -ENOMEM;
--
2.1.0
[PATCH v16 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
On Thu, Dec 04, 2014 at 12:01:25AM +0800, Andy Yan wrote: > Hi Russell: > Do you mean I just neet to do like bellow? > > + > +config DRM_DW_HDMI > + bool > + depends on DRM > + select DRM_KMS_HELPER Yep. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
On Thu, Dec 04, 2014 at 12:56:24AM +0800, Andy Yan wrote:
> Hi Russell:
> On 2014å¹´12æ04æ¥ 00:33, Russell King - ARM Linux wrote:
> >On Thu, Dec 04, 2014 at 12:30:23AM +0800, Andy Yan wrote:
> >>On 2014å¹´12æ04æ¥ 00:11, Russell King - ARM Linux wrote:
> >>>I meant that imx_hdmi_bind should be passed these, so that it needs to
> >>>know nothing about the struct device beyond the generic device structure.
> >>>In other words, the dw-hdmi core should not assume that the struct device
> >>>is part of a platform device.
> >>>
> >>if so, how about the device tree properties ddc-i2c-bus, reg-io-width,
> >>iahb, isfr,
> >> they are all found by device?
> >If the device has a device tree node associated with it, it will have a
> >non-NULL dev->of_node - which is part of the generic device structure.
> >
> so , I just need get the resource and irq number in the
> dw_hdmi-imx/rockchip ,than
> pass them to imx_hdmi_bind, as the properties ddc-i2c-bus, reg-io-width,
> iahb,isfr, they
> are still can be handled in imx_hdmi_bind ?
Basically, what I'm suggesting is just this change to imx_hdmi_bind():
int imx_hdmi_bind(struct device *dev, struct device *master,
void *data, struct drm_encoder *encoder,
+ const struct resource *iores, int irq,
const struct imx_hdmi_plat_data *plat_data)
{
- struct platform_device *pdev = to_platform_device(dev);
...
}
- irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
...
return ret;
- iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hdmi->regs = devm_ioremap_resource(dev, iores);
if (IS_ERR(hdmi->regs))
and supplying those as arguments from the caller.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
