[Bug 96361] New: [Bisected, radeon]Non-infinite boot loop since v3.13
https://bugzilla.kernel.org/show_bug.cgi?id=96361 Bug ID: 96361 Summary: [Bisected, radeon]Non-infinite boot loop since v3.13 Product: Drivers Version: 2.5 Kernel Version: 3.19 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: servuswiegehtz at yahoo.de Regression: No For a while now my desktop pc experiences boot issues. I try to boot and after grub the screen just goes in standby mode and sometimes it reboots and sometimes just nothing happens. After a few tries it usually succeeds in booting. So I bisected the kernel and this is the first bad commit: 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 Steps to reproduce: not sure, seems to be a rare bug. install a linux kernel newer than 3.13 and boot Hardware: AMD Phenom X4 955 AMD 5770 (Evergreen, Juniper) I tried to get a log from systemd (journalctl --boot=-1) but there is none for the failed boot attempt. -- You are receiving this mail because: You are watching the assignee of the bug.
[git pull] drm fixes
Hi Linus, Final drm fixes, one core locking imbalance regression, and a bunch of i915 baytrail s/r fixes. going to be away for a few days, but should still have email at least. Dave. The following changes since commit f22e6e847115abc3a0e2ad7bb18d243d42275af1: Linux 4.0-rc7 (2015-04-06 15:39:45 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to f4274e23fb16721449d973ed607505f5dbdcd2df: Merge tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-04-09 06:59:50 +1000) Dave Airlie (1): Merge tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel into drm-fixes Deepak S (1): drm/i915/chv: Remove Wait for a previous gfx force-off Jesse Barnes (2): drm/i915/vlv: save/restore the power context base reg drm/i915/vlv: remove wait for previous GFX clk disable request Tommi Rantala (1): drm: fix drm_mode_getconnector() locking imbalance regression drivers/gpu/drm/drm_crtc.c | 4 +++- drivers/gpu/drm/i915/i915_drv.c | 14 ++ drivers/gpu/drm/i915/i915_drv.h | 1 + 3 files changed, 6 insertions(+), 13 deletions(-)
[Bug 89944] GPU crash in Civilization 5
https://bugs.freedesktop.org/show_bug.cgi?id=89944 Sami Liedes changed: What|Removed |Added CC||kenneth at whitecape.org --- Comment #3 from Sami Liedes --- I bisected this down to this commit: commit 30f51f1a1a70bc838d5bed449daff0dd9f2e8ef2 Author: Kenneth Graunke Date: Wed Oct 22 20:48:21 2014 -0700 glsl: Optimize "if (cond) discard;" to a conditional discard. st_glsl_to_tgsi and ir_to_mesa have handled conditional discards for a long time; the previous patch added that capability to i965. i965 (Haswell) shader-db stats: Without NIR: total instructions in shared programs: 5792133 -> 5776360 (-0.27%) instructions in affected programs: 737585 -> 721812 (-2.14%) helped:6300 HURT: 68 GAINED:2 With NIR: total instructions in shared programs: 5787538 -> 5769569 (-0.31%) instructions in affected programs: 767843 -> 749874 (-2.34%) helped:6522 HURT: 35 GAINED:6 Signed-off-by: Kenneth Graunke Reviewed-by: Connor Abbott Reviewed-by: Matt Turner Reviewed-by: Eric Anholt I can also confirm that reverting that commit on top of recent HEAD (4deca127) fixes the issue. I can attach R600_DEBUG=ps,gs,vs output from the offending commit and its parent if you think comparing them is of any use. -- 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/20150408/39842a9f/attachment-0001.html>
[Bug 88364] Xorg hangs after videocard switching
https://bugs.freedesktop.org/show_bug.cgi?id=88364 --- Comment #8 from Liss --- Error still reproducible on kernel 4.0-rc7. -- 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/20150408/c5d86e11/attachment.html>
[PATCH] drm/nouveau/bios: 0 means success for nvbios_extend
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=89047
CC: David Airlie
CC: Ben Skeggs
CC: dri-devel at lists.freedesktop.org
CC: linux-kernel at vger.kernel.org
Signed-off-by: Jan Vesely
---
It's needed for 3.19 too
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 8c2b7cb..f566ac8 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -44,7 +44,7 @@ shadow_fetch(struct nvkm_bios *bios, u32 upto)
const u32 limit = (upto + 3) & ~3;
const u32 start = bios->size;
void *data = mthd->data;
- if (nvbios_extend(bios, limit) > 0) {
+ if (nvbios_extend(bios, limit) >= 0) {
u32 read = mthd->func->read(data, start, limit - start, bios);
bios->size = start + read;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
index 1fbd93b..f9d0eb5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
@@ -52,7 +52,7 @@ acpi_read_fast(void *data, u32 offset, u32 length, struct
nvkm_bios *bios)
u32 start = offset & ~0x0fff;
u32 fetch = limit - start;
- if (nvbios_extend(bios, limit) > 0) {
+ if (nvbios_extend(bios, limit) >= 0) {
int ret = nouveau_acpi_get_bios_chunk(bios->data, start, fetch);
if (ret == fetch)
return fetch;
@@ -73,7 +73,7 @@ acpi_read_slow(void *data, u32 offset, u32 length, struct
nvkm_bios *bios)
u32 start = offset & ~0xfff;
u32 fetch = 0;
- if (nvbios_extend(bios, limit) > 0) {
+ if (nvbios_extend(bios, limit) >= 0) {
while (start + fetch < limit) {
int ret = nouveau_acpi_get_bios_chunk(bios->data,
start + fetch,
--
2.0.5
[Intel-gfx] [PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport compliance testing
2015-04-08 18:43 GMT-03:00 Todd Previte :
>
>
> On 4/8/2015 9:51 AM, Paulo Zanoni wrote:
>>
>> 2015-03-31 14:15 GMT-03:00 Todd Previte :
>>>
>>> Displayport compliance test 4.2.2.6 requires that a source device be
>>> capable of detecting
>>> a corrupt EDID. To do this, the test sets up an invalid EDID header to be
>>> read by the source
>>> device. Unfortunately, the DRM EDID reading and parsing functions are
>>> actually too good in
>>> this case and prevent the source from reading the corrupted EDID. The
>>> result is a failed
>>> compliance test.
>>>
>>> In order to successfully pass the test, the raw EDID header must be
>>> checked on each read
>>> to see if has been "corrupted". If an invalid raw header is detected, a
>>> flag is set that
>>> allows the compliance testing code to acknowledge that fact and react
>>> appropriately. The
>>> flag is automatically cleared on read.
>>>
>>> This code is designed to expressly work for compliance testing without
>>> disrupting normal
>>> operations for EDID reading and parsing.
>>>
>>> Signed-off-by: Todd Previte
>>> Cc: dri-devel at lists.freedesktop.org
>>> ---
>>> drivers/gpu/drm/drm_edid.c | 33 +
>>> drivers/gpu/drm/i915/intel_dp.c | 17 +
>>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>>> include/drm/drm_edid.h | 5 +
>>> 4 files changed, 56 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 53bc7a6..3d4f473 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -990,6 +990,32 @@ static const u8 edid_header[] = {
>>> 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
>>> };
>>>
>>> +
>>> +/* Flag for EDID corruption testing
>>> + * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
>>> + */
>>> +static bool raw_edid_header_corrupted;
>>
>> A static variable like this is not a good design, especially for a
>> module like drm.ko. If you really need this, please store it inside
>> some struct. But see below first.
>
> Per our discussion this morning, I concur. This has been removed in favor of
> a different solution that uses a new boolean flag in the drm_connector
> struct.
>
> Capturing more of the discussion here, the static boolean was a bad idea to
> begin with and needed to be removed. One solution was to make the flag
> non-static and non-clear-on-read, then add a separate clear() function. But
> it still had the problem of potential misuse other places in the code. The
> current solution (which will be posted with V5) modifies the is_valid()
> function and adds a flag in the drm_connector struct that can be used to
> detect this low-level header corruption.
>
>
>>
>>> +
>>> +/**
>>> + * drm_raw_edid_header_valid - check to see if the raw header is
>>> + * corrupt or not. Used solely for Displayport compliance
>>> + * testing and required by Link CTS Core 1.2 rev1.1 4.2.2.6.
>>> + * @raw_edid: pointer to raw base EDID block
>>> + *
>>> + * Indicates whether the original EDID header as read from the
>>> + * device was corrupt or not. Clears on read.
>>> + *
>>> + * Return: true if the raw header was corrupt, otherwise false
>>> + */
>>> +bool drm_raw_edid_header_corrupt(void)
>>> +{
>>> + bool corrupted = raw_edid_header_corrupted;
>>> +
>>> + raw_edid_header_corrupted = 0;
>>> + return corrupted;
>>> +}
>>> +EXPORT_SYMBOL(drm_raw_edid_header_corrupt);
>>> +
>>> /**
>>>* drm_edid_header_is_valid - sanity check the header of the base EDID
>>> block
>>>* @raw_edid: pointer to raw base EDID block
>>> @@ -1006,6 +1032,13 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
>>> if (raw_edid[i] == edid_header[i])
>>> score++;
>>>
>>> + if (score != 8) {
>>> + /* Log and set flag here for EDID corruption testing
>>> +* Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
>>> +*/
>>> + DRM_DEBUG_DRIVER("Raw EDID header invalid\n");
>>> + raw_edid_header_corrupted = 1;
>>> + }
>>
>> The problem is that here we're limiting ourselves to just a bad edid
>> header, not a bad edid in general, so there are many things which we
>> might not get - such as a simple wrong checksum edid value. I remember
>> that on the previous patch you calculated the whole checksum manually,
>> but I don't see that code anymore. What was the reason for the change?
>
> So this code is specifically for the 4.2.2.6 compliance test that is looking
> for nothing more than an invalid EDID header.
On the version of the spec I have (1.2 Core, Aug 22 2011), 4.2.2.6 is
"EDID Corruption Detection", and it mentions "EDID corruption" without
really getting into the details of header corruption. On the "Test
procedure" description, it mentions "Reference Sink sets up EDID with
incorrect checksum", which we don't check. Of course, changing the
header may produce an incorrect checksum, but maybe
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3] ASoC: max98090: add shutdown callback for max98090
To fix pop noise when shutdown,the pop noise during shutdown
is the pmic cutoff power of codec without any notice.
Signed-off-by: jay.xu
Signed-off-by: zhengxing
Signed-off-by: Caesar Wang
---
Changes in v3:
- modify the shutdown function before remove(..)
- fix the `Serien-cc`
Changes in v2:
- remove the dev_info(..)
- fix the comment style
- add the max98090_i2c_shutdown() in remove() fuction
sound/soc/codecs/max98090.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..3e33ef2 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2605,8 +2605,24 @@ err_enable:
return ret;
}
+static void max98090_i2c_shutdown(struct i2c_client *i2c)
+{
+ struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
+
+ /*
+* Enable volume smoothing, disable zero cross. This will cause
+* a quick 40ms ramp to mute on shutdown.
+*/
+ regmap_write(max98090->regmap,
+ M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
+ regmap_write(max98090->regmap,
+ M98090_REG_DEVICE_SHUTDOWN, 0x00);
+ msleep(40);
+}
+
static int max98090_i2c_remove(struct i2c_client *client)
{
+ max98090_i2c_shutdown(client);
snd_soc_unregister_codec(&client->dev);
return 0;
}
@@ -2696,6 +2712,7 @@ static struct i2c_driver max98090_i2c_driver = {
.acpi_match_table = ACPI_PTR(max98090_acpi_match),
},
.probe = max98090_i2c_probe,
+ .shutdown = max98090_i2c_shutdown,
.remove = max98090_i2c_remove,
.id_table = max98090_i2c_id,
};
--
1.9.1
[PATCH v2] ASoC: max98090: add shutdown callback for max98090
Kever, å¨ 2015å¹´04æ08æ¥ 18:51, Kever Yang åé: > Hi Caesar, > > On 04/08/2015 06:18 PM, Caesar Wang wrote: >> To fix pop noise when shutdown,the pop noise during shutdown >> is the pmic cutoff power of codec without any notice. >> >> Signed-off-by: jay.xu >> Signed-off-by: zhengxing >> Signed-off-by: Caesar Wang >> >> Serien-cc: linux-kernel at vger.kernel.org >> Serien-cc: devicetree at vger.kernel.org >> Serien-cc: dianders at chromium.org > Typo? Should be "Series-cc" here I guess. > Yeah,it's a mistake from my finger. I fix it in v3 patch. Thanks! > Thanks, > - Kever > > > -- ** çæè ¾Caesar Wang ç³»ç»äº§åä¸é¨ Product R&D Dept.III ç¦å·çè¯å¾®çµåæéå ¬å¸ Fuzhou Rockchip Electronics Co.Ltd å°åï¼ç¦å»ºçç¦å·å¸éç路软件大é89å·è½¯ä»¶åAåº18å·æ¥¼ ï¼ç¦å·æ»é¨ï¼ æ·±å³åå±±åºç§æä¸ä¸è·¯ä¸å©è¾¾å¤§å¦21å± ï¼æ·±å³åå ¬å¸ï¼ Addrï¼ NO.18 Building, A District, Fuzhou Software Park,Gulou District,Fuzhou, Fujian,China(Fuzhou Headquarters) 21F,Malata Building,Kejizhongyi Avenue,Nanshan District,Shenzhen (Shenzhen Office) Telï¼+86-591-83991906/07 - 8221 Mobile:+86 15059456742 E-mail : wxt at rock-chips.com *** *** ä¿å¯æ示ï¼æ¬é®ä»¶åå ¶é件å«ææºå¯ä¿¡æ¯ï¼ä» åéç»æ¬é®ä»¶ææç¹å®æ¶ä»¶äººãè¥é该ç¹å®æ¶ä»¶äººï¼è¯·å¿å¤å¶ã 使ç¨ææ«é²æ¬é®ä»¶çä»»ä½å 容ã è¥è¯¯æ¶æ¬é®ä»¶ï¼è¯·ä»ç³»ç»ä¸æ°¸ä¹ æ§å é¤æ¬é®ä»¶åææé件ï¼å¹¶ä»¥åå¤é®ä»¶æå ¶ä»æ¹å¼å³å»åç¥å件人ãç¦å·çè¯å¾®çµåæéå ¬å¸æ¥ææ¬é®ä»¶ä¿¡ æ¯çèä½æå解éæï¼ç¦æ¢ä»»ä½æªç»ææ许å¯çä¾µæè¡ä¸ºã IMPORTANT NOTICE: This email is from Fuzhou Rockchip Electronics Co., Ltd .The contents of this email and any attachments may contain information that is privileged, confidential and/or exempt from disclosure under applicable law and relevant NDA. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information is STRICTLY PROHIBITED. Please immediately contact the sender as soon as possible and destroy the material in its entirety in any format. Thank you. ***
[PATCH v2] ASoC: max98090: add shutdown callback for max98090
Hi Caesar, On 04/08/2015 06:18 PM, Caesar Wang wrote: > To fix pop noise when shutdown,the pop noise during shutdown > is the pmic cutoff power of codec without any notice. > > Signed-off-by: jay.xu > Signed-off-by: zhengxing > Signed-off-by: Caesar Wang > > Serien-cc: linux-kernel at vger.kernel.org > Serien-cc: devicetree at vger.kernel.org > Serien-cc: dianders at chromium.org Typo? Should be "Series-cc" here I guess. Thanks, - Kever
[Bug 96351] New: System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 Bug ID: 96351 Summary: System hangs up after update to any kernel newer than 3.12* Product: Drivers Version: 2.5 Kernel Version: 3.19.3-100.fc20.i686 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: georgechebanmk at gmail.com Regression: No Good day to you, comrades! Have some problems with my notebook Packard Bell Easynote lj-71. It has an old graphic HD 4650. Now working on Fedora 20 with kernel 3.12.7-300.fc20.i686. After update to any newer kernel, for example 3.17*/3.19* with any distro (*buntu, fedora), 4.0* on Fedora 22 Alpha, system starts for a few minutes and then always hangs up with black screen, especially when running video on youtube for example. Alt+Ctrl+F2 doesn't work, only hard reset Can start with "nomodeset" parameter, so I think that it's a radeon driver problems. Works normally only with stock kernel 3.12. Also, described method in this topic https://bugzilla.kernel.org/show_bug.cgi?id=71891 with radeon.dpm=0 doesn't solves my problem. Please advice, what else outputs I need to provide for more detailed information? Working with linux for a few months, so don't have enough skills to solve this problem on my own. lspci -k | grep -A3 VGA 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730/M96 [Mobility Radeon HD 4650/5165] Subsystem: Acer Incorporated [ALI] Device 027e Kernel driver in use: radeon Kernel modules: radeon -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2] ASoC: max98090: add shutdown callback for max98090
To fix pop noise when shutdown,the pop noise during shutdown
is the pmic cutoff power of codec without any notice.
Signed-off-by: jay.xu
Signed-off-by: zhengxing
Signed-off-by: Caesar Wang
Serien-cc: linux-kernel at vger.kernel.org
Serien-cc: devicetree at vger.kernel.org
Serien-cc: dianders at chromium.org
---
Changes in v2:
- remove the dev_info(..)
- fix the comment style
- add the max98090_i2c_shutdown() in remove() fuction
sound/soc/codecs/max98090.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..e59013a 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2607,10 +2607,26 @@ err_enable:
static int max98090_i2c_remove(struct i2c_client *client)
{
+ max98090_i2c_shutdown(client);
snd_soc_unregister_codec(&client->dev);
return 0;
}
+static void max98090_i2c_shutdown(struct i2c_client *i2c)
+{
+ struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
+
+ /*
+* Enable volume smoothing, disable zero cross. This will cause
+* a quick 40ms ramp to mute on shutdown.
+*/
+ regmap_write(max98090->regmap,
+ M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
+ regmap_write(max98090->regmap,
+ M98090_REG_DEVICE_SHUTDOWN, 0x00);
+ msleep(40);
+}
+
#ifdef CONFIG_PM
static int max98090_runtime_resume(struct device *dev)
{
@@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
},
.probe = max98090_i2c_probe,
.remove = max98090_i2c_remove,
+ .shutdown = max98090_i2c_shutdown,
.id_table = max98090_i2c_id,
};
--
1.9.1
[PATCH] ASoC: max98090: add shutdown callback for max98090
Mark,
å¨ 2015å¹´04æ08æ¥ 17:50, Mark Brown åé:
> On Wed, Apr 08, 2015 at 04:52:08PM +0800, Caesar Wang wrote:
>
>> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
>> +{
>> +struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
>> +
>> +dev_info(&i2c->dev, "shut down device\n");
> Remove this, it's adding noise.
Done
>> +
>> +/* Enable volume smoothing, disable zero cross. This will cause
>> + * a quick 40ms ramp to mute on shutdown.
>> + */
>> +regmap_write(max98090->regmap,
>> +M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
>> +regmap_write(max98090->regmap,
>> +M98090_REG_DEVICE_SHUTDOWN, 0x00);
>> +msleep(40);
>> +}
> This is OK but equivalent code should be being added to the driver
> remove path as the same thing should be happening there.
Yeah.I will fix it in v2 patch.
Thanks!
--
**
çæè
¾Caesar Wang
ç³»ç»äº§åä¸é¨ Product R&D Dept.III
ç¦å·çè¯å¾®çµåæéå
¬å¸ Fuzhou Rockchip Electronics Co.Ltd
å°åï¼ç¦å»ºçç¦å·å¸éç路软件大é89å·è½¯ä»¶åAåº18å·æ¥¼
ï¼ç¦å·æ»é¨ï¼
æ·±å³åå±±åºç§æä¸ä¸è·¯ä¸å©è¾¾å¤§å¦21å± ï¼æ·±å³åå
¬å¸ï¼
Addrï¼ NO.18 Building, A District, Fuzhou Software Park,Gulou
District,Fuzhou, Fujian,China(Fuzhou Headquarters)
21F,Malata Building,Kejizhongyi Avenue,Nanshan District,Shenzhen
(Shenzhen Office)
Telï¼+86-591-83991906/07 - 8221
Mobile:+86 15059456742
E-mail : wxt at rock-chips.com
***
***
ä¿å¯æ示ï¼æ¬é®ä»¶åå
¶é件å«ææºå¯ä¿¡æ¯ï¼ä»
åéç»æ¬é®ä»¶ææç¹å®æ¶ä»¶äººãè¥é该ç¹å®æ¶ä»¶äººï¼è¯·å¿å¤å¶ã
使ç¨ææ«é²æ¬é®ä»¶çä»»ä½å
容ã
è¥è¯¯æ¶æ¬é®ä»¶ï¼è¯·ä»ç³»ç»ä¸æ°¸ä¹
æ§å
é¤æ¬é®ä»¶åææé件ï¼å¹¶ä»¥åå¤é®ä»¶æå
¶ä»æ¹å¼å³å»åç¥å件人ãç¦å·çè¯å¾®çµåæéå
¬å¸æ¥ææ¬é®ä»¶ä¿¡
æ¯çèä½æå解éæï¼ç¦æ¢ä»»ä½æªç»ææ许å¯çä¾µæè¡ä¸ºã
IMPORTANT NOTICE: This email is from Fuzhou Rockchip Electronics Co., Ltd .The
contents of this email and any attachments may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law and relevant NDA.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the
information is STRICTLY PROHIBITED. Please immediately contact the sender as
soon as possible and destroy the material
in its entirety in any format. Thank you.
***
[PATCH] ASoC: max98090: add shutdown callback for max98090
Heiko,
å¨ 2015å¹´04æ08æ¥ 17:25, Heiko Stübner åé:
> Hi Caesar,
>
> Am Mittwoch, 8. April 2015, 16:52:08 schrieb Caesar Wang:
>> To fix pop noise when shutdown,the pop noise during shutdown
>> is the pmic cutoff power of codec without any notice.
>>
>> Signed-off-by: jay.xu
>> Signed-off-by: zhengxing
>> Signed-off-by: Caesar Wang
>>
>> Serien-cc: linux-kernel at vger.kernel.org
>> Serien-cc: devicetree at vger.kernel.org
>> Serien-cc: dianders at chromium.org
>>
>> ---
>>
>> sound/soc/codecs/max98090.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
>> index b112b1c..066954a0 100644
>> --- a/sound/soc/codecs/max98090.c
>> +++ b/sound/soc/codecs/max98090.c
>> @@ -2611,6 +2611,22 @@ static int max98090_i2c_remove(struct i2c_client
>> *client) return 0;
>> }
>>
>> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
>> +{
>> +struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
>> +
>> +dev_info(&i2c->dev, "shut down device\n");
> is this dev_info really necessary? dev_dbg might be better, or leave it out
> completely, as it doesn't really provide any additional benefit.
>
As Mark suggestion, I will remove it.
>> +
>> +/* Enable volume smoothing, disable zero cross. This will cause
>> + * a quick 40ms ramp to mute on shutdown.
>> + */
> Comment style is off ... should be
>
> /*
> * Enable volume smoothing, disable zero cross. This will cause
> * a quick 40ms ramp to mute on shutdown.
> */
>
Done
>> +regmap_write(max98090->regmap,
>> +M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
>> +regmap_write(max98090->regmap,
>> +M98090_REG_DEVICE_SHUTDOWN, 0x00);
>> +msleep(40);
>> +}
>> +
>> #ifdef CONFIG_PM
>> static int max98090_runtime_resume(struct device *dev)
>> {
>> @@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
>> },
>> .probe = max98090_i2c_probe,
>> .remove = max98090_i2c_remove,
>> +.shutdown = max98090_i2c_shutdown,
>> .id_table = max98090_i2c_id,
>> };
>
>
>
--
**
çæè
¾Caesar Wang
ç³»ç»äº§åä¸é¨ Product R&D Dept.III
ç¦å·çè¯å¾®çµåæéå
¬å¸ Fuzhou Rockchip Electronics Co.Ltd
å°åï¼ç¦å»ºçç¦å·å¸éç路软件大é89å·è½¯ä»¶åAåº18å·æ¥¼
ï¼ç¦å·æ»é¨ï¼
æ·±å³åå±±åºç§æä¸ä¸è·¯ä¸å©è¾¾å¤§å¦21å± ï¼æ·±å³åå
¬å¸ï¼
Addrï¼ NO.18 Building, A District, Fuzhou Software Park,Gulou
District,Fuzhou, Fujian,China(Fuzhou Headquarters)
21F,Malata Building,Kejizhongyi Avenue,Nanshan District,Shenzhen
(Shenzhen Office)
Telï¼+86-591-83991906/07 - 8221
Mobile:+86 15059456742
E-mail : wxt at rock-chips.com
***
***
ä¿å¯æ示ï¼æ¬é®ä»¶åå
¶é件å«ææºå¯ä¿¡æ¯ï¼ä»
åéç»æ¬é®ä»¶ææç¹å®æ¶ä»¶äººãè¥é该ç¹å®æ¶ä»¶äººï¼è¯·å¿å¤å¶ã
使ç¨ææ«é²æ¬é®ä»¶çä»»ä½å
容ã
è¥è¯¯æ¶æ¬é®ä»¶ï¼è¯·ä»ç³»ç»ä¸æ°¸ä¹
æ§å
é¤æ¬é®ä»¶åææé件ï¼å¹¶ä»¥åå¤é®ä»¶æå
¶ä»æ¹å¼å³å»åç¥å件人ãç¦å·çè¯å¾®çµåæéå
¬å¸æ¥ææ¬é®ä»¶ä¿¡
æ¯çèä½æå解éæï¼ç¦æ¢ä»»ä½æªç»ææ许å¯çä¾µæè¡ä¸ºã
IMPORTANT NOTICE: This email is from Fuzhou Rockchip Electronics Co., Ltd .The
contents of this email and any attachments may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law and relevant NDA.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the
information is STRICTLY PROHIBITED. Please immediately contact the sender as
soon as possible and destroy the material
in its entirety in any format. Thank you.
***
[PATCH v3] ASoC: max98090: add shutdown callback for max98090
On Wed, Apr 08, 2015 at 07:05:56PM +0800, Caesar Wang wrote: > To fix pop noise when shutdown,the pop noise during shutdown > is the pmic cutoff power of codec without any notice. Applied, thanks. Please do make an effort to only send patches to relevant people - sending people patches that aren't relevant to them adds to the volume of mail they have to handle which can get in the way of things that need the attention. For example I'm not sure why the dri-devel list is on this. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/205c6ef6/attachment.sig>
[PATCH libdrm 3/3] man: rework the Makefile.am
Remove GNU make specific constructs and take into consideration that Solaris man 7 is not the same as Linux man 7. This commit introduces a dependency of xorg-macros 1.12 (released 4+ years ago) which is used to handle the above man section discrepancies. Cc: Niveditha Rau Signed-off-by: Emil Velikov --- If people prefer I can split this patch into separate ones, but considering how much of a rework/rewrite of man/Makefile.am this turned up to be it might not be worth it. Niveditha, If you can grab the tarball [1] for your test it should handle most/all of the GNU make dependencies, as it's based on my for-solaris branch at https://github.com/evelikov/libdrm Thanks, Emil [1] http://people.freedesktop.org/~evelikov/for-solaris/libdrm-2.4.60.tar.gz --- Makefile.am | 8 +- configure.ac| 10 ++-- man/Makefile.am | 80 ++--- 3 files changed, 57 insertions(+), 41 deletions(-) diff --git a/Makefile.am b/Makefile.am index 42d3d7f..13df80c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -73,6 +73,12 @@ if HAVE_TEGRA TEGRA_SUBDIR = tegra endif +if BUILD_MANPAGES +if HAVE_MANPAGES_STYLESHEET +MAN_SUBDIR = man +endif +endif + SUBDIRS = \ . \ $(LIBKMS_SUBDIR) \ @@ -84,7 +90,7 @@ SUBDIRS = \ $(FREEDRENO_SUBDIR) \ $(TEGRA_SUBDIR) \ tests \ - man + $(MAN_SUBDIR) libdrm_la_LTLIBRARIES = libdrm.la libdrm_ladir = $(libdir) diff --git a/configure.ac b/configure.ac index 320e482..f8adf4f 100644 --- a/configure.ac +++ b/configure.ac @@ -29,6 +29,13 @@ AC_CONFIG_SRCDIR([Makefile.am]) AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_AUX_DIR([build-aux]) +# Require xorg-macros minimum of 1.12 for XORG_WITH_XSLTPROC +m4_ifndef([XORG_MACROS_VERSION], + [m4_fatal([must install xorg-macros 1.12 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.12) +XORG_WITH_XSLTPROC +XORG_MANPAGE_SECTIONS + AM_INIT_AUTOMAKE([1.10 foreign dist-bzip2]) # Enable quiet compiles on automake 1.11. @@ -378,9 +385,8 @@ AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes]) # xsltproc for docbook manpages AC_ARG_ENABLE([manpages], - AS_HELP_STRING([--disable-manpages], [disable manpages @<:@default=enabled@:>@]), + AS_HELP_STRING([--enable-manpages], [enable manpages @<:@default=auto@:>@]), [MANS=$enableval], [MANS=auto]) -AC_PATH_PROG(XSLTPROC, xsltproc) AM_CONDITIONAL([BUILD_MANPAGES], [test "x$XSLTPROC" != "x" -a "x$MANS" != "xno"]) # check for offline man-pages stylesheet diff --git a/man/Makefile.am b/man/Makefile.am index d25a293..44b63a5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,63 +1,67 @@ # # This generates man-pages out of the Docbook XML files. Simply add your files -# to the $MANPAGES array. If aliases are created, please add them to the -# MANPAGES_ALIASES array so they get installed correctly. +# to the relevant *man_PRE array. If aliases are created, please add them to the +# *man_aliases_PRE array so they get installed correctly. # -MANPAGES = \ - drm.7 \ - drm-kms.7 \ - drm-memory.7 \ - drmAvailable.3 \ - drmHandleEvent.3 \ - drmModeGetResources.3 -MANPAGES_ALIASES = \ - drm-mm.7 \ - drm-gem.7 \ - drm-ttm.7 +libman_PRE = \ + drmAvailable.xml \ + drmHandleEvent.xml \ + drmModeGetResources.xml -XML_FILES = \ - $(patsubst %.1,%.xml,$(patsubst %.3,%.xml,$(patsubst %.5,%.xml,$(patsubst %.7,%.xml,$(MANPAGES) +miscman_PRE = \ + drm.xml \ + drm-kms.xml \ + drm-memory.xml -EXTRA_DIST = $(XML_FILES) -CLEANFILES = $(MANPAGES) $(MANPAGES_ALIASES) .man_fixup -man_MANS = +miscman_aliases_PRE = \ + drm-mm.xml \ + drm-gem.xml \ + drm-ttm.xml + +libmandir = $(LIB_MAN_DIR) +miscmandir = $(MISC_MAN_DIR) +miscman_aliasesdir = $(MISC_MAN_DIR) -if BUILD_MANPAGES -if HAVE_MANPAGES_STYLESHEET +libman_DATA = $(libman_PRE:.xml=.$(LIB_MAN_SUFFIX)) +miscman_DATA = $(miscman_PRE:.xml=.$(MISC_MAN_SUFFIX)) +miscman_aliases_DATA = $(miscman_aliases_PRE:.xml=.$(MISC_MAN_SUFFIX)) -man_MANS += $(MANPAGES) $(MANPAGES_ALIASES) +XML_FILES = \ + $(libman_PRE) \ + $(miscman_PRE) + +MAN_FILES = \ + $(libman_DATA) \ + $(miscman_DATA) \ + $(miscman_aliases_DATA) + +EXTRA_DIST = $(XML_FILES) +CLEANFILES = $(MAN_FILES) .man_fixup XSLTPROC_FLAGS = \ --stringparam man.authors.section.enabled 0 \ --stringparam man.copyright.section.enabled 0 \ --stringparam funcsynopsis.style ansi \ --stringparam man.output.quietly 1 \ - --nonet + --nonet \ + $(MANPAGES_STYLESHEET) XSLTPROC_PROCESS_MAN = \ - $(AM_V_GEN)$(MKDIR_P) $(dir $@) && \ - $(XSLTPROC) -o "$@" $(XSLTPROC_FLAGS) $(MANPAGES_STYLESHEET) "$<" && \ + $(AM_V_GEN)$(XSLTPROC) -o "$@" $(XSLTPROC_FLAGS) "$<" && \ touch .man_fixup -# Force .man_fixup if $(MANPAGES) are not built -.
[PATCH libdrm 2/3] drm: use c99 __func__ over __FUNCTION__
Signed-off-by: Emil Velikov
---
intel/intel_bufmgr_fake.c | 19 +++
tests/drmstat.c | 7 +--
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/intel/intel_bufmgr_fake.c b/intel/intel_bufmgr_fake.c
index 54a3983..75387b7 100644
--- a/intel/intel_bufmgr_fake.c
+++ b/intel/intel_bufmgr_fake.c
@@ -52,11 +52,6 @@
#include "libdrm_macros.h"
#include "libdrm_lists.h"
-/* Support gcc's __FUNCTION__ for people using other compilers */
-#if !defined(__GNUC__) && !defined(__FUNCTION__)
-# define __FUNCTION__ __func__ /* C99 */
-#endif
-
#define DBG(...) do { \
if (bufmgr_fake->bufmgr.debug) \
drmMsg(__VA_ARGS__);\
@@ -278,7 +273,7 @@ _fence_emit_internal(drm_intel_bufmgr_fake *bufmgr_fake)
ret = drmCommandWriteRead(bufmgr_fake->fd, DRM_I915_IRQ_EMIT,
&ie, sizeof(ie));
if (ret) {
- drmMsg("%s: drm_i915_irq_emit: %d\n", __FUNCTION__, ret);
+ drmMsg("%s: drm_i915_irq_emit: %d\n", __func__, ret);
abort();
}
@@ -545,7 +540,7 @@ evict_lru(drm_intel_bufmgr_fake *bufmgr_fake, unsigned int
max_fence)
{
struct block *block, *tmp;
- DBG("%s\n", __FUNCTION__);
+ DBG("%s\n", __func__);
DRMLISTFOREACHSAFE(block, tmp, &bufmgr_fake->lru) {
drm_intel_bo_fake *bo_fake = (drm_intel_bo_fake *) block->bo;
@@ -572,7 +567,7 @@ evict_mru(drm_intel_bufmgr_fake *bufmgr_fake)
{
struct block *block, *tmp;
- DBG("%s\n", __FUNCTION__);
+ DBG("%s\n", __func__);
DRMLISTFOREACHSAFEREVERSE(block, tmp, &bufmgr_fake->lru) {
drm_intel_bo_fake *bo_fake = (drm_intel_bo_fake *) block->bo;
@@ -632,7 +627,7 @@ clear_fenced(drm_intel_bufmgr_fake *bufmgr_fake, unsigned
int fence_cookie)
}
}
- DBG("%s: %d\n", __FUNCTION__, ret);
+ DBG("%s: %d\n", __func__, ret);
return ret;
}
@@ -717,7 +712,7 @@ evict_and_alloc_block(drm_intel_bo *bo)
if (alloc_block(bo))
return 1;
- DBG("%s 0x%lx bytes failed\n", __FUNCTION__, bo->size);
+ DBG("%s 0x%lx bytes failed\n", __func__, bo->size);
return 0;
}
@@ -1027,12 +1022,12 @@ static int
bo_fake->name, bo_fake->bo.size / 1024);
if (bo->virtual != NULL) {
- drmMsg("%s: already mapped\n", __FUNCTION__);
+ drmMsg("%s: already mapped\n", __func__);
abort();
} else if (bo_fake->flags & (BM_NO_BACKING_STORE | BM_PINNED)) {
if (!bo_fake->block && !evict_and_alloc_block(bo)) {
- DBG("%s: alloc failed\n", __FUNCTION__);
+ DBG("%s: alloc failed\n", __func__);
bufmgr_fake->fail = 1;
return 1;
} else {
diff --git a/tests/drmstat.c b/tests/drmstat.c
index c800ebb..023aa06 100644
--- a/tests/drmstat.c
+++ b/tests/drmstat.c
@@ -48,11 +48,6 @@
#endif
#include "xf86drm.h"
-/* Support gcc's __FUNCTION__ for people using other compilers */
-#if !defined(__GNUC__) && !defined(__FUNCTION__)
-# define __FUNCTION__ __func__ /* C99 */
-#endif
-
int sigio_fd;
static double usec(struct timeval *end, struct timeval *start)
@@ -87,7 +82,7 @@ static void process_sigio(char *device)
int fd;
if ((fd = open(device, 0)) < 0) {
- drmError(-errno, __FUNCTION__);
+ drmError(-errno, __func__);
exit(1);
}
--
2.3.1
[PATCH libdrm 1/3] configure: request/set the compiler in C99 mode
Required by intel and drmstat at least. Considering that every compiler
used to build libdrm is C99 compatible, just enable it for the whole
build.
Signed-off-by: Emil Velikov
---
configure.ac | 5 +
intel/Makefile.am | 2 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e715262..320e482 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,6 +36,11 @@ m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
# Check for programs
AC_PROG_CC
+AC_PROG_CC_C99
+
+if test "x$ac_cv_prog_cc_c99" = xno; then
+ AC_MSG_ERROR([Building libdrm requires C99 enabled compiler])
+fi
AC_USE_SYSTEM_EXTENSIONS
AC_SYS_LARGEFILE
diff --git a/intel/Makefile.am b/intel/Makefile.am
index de3baab..d004568 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -42,8 +42,6 @@ libdrm_intel_la_LIBADD = ../libdrm.la \
libdrm_intel_la_SOURCES = $(LIBDRM_INTEL_FILES)
-intel_bufmgr_gem_o_CFLAGS = $(AM_CFLAGS) -c99
-
libdrm_intelincludedir = ${includedir}/libdrm
libdrm_intelinclude_HEADERS = $(LIBDRM_INTEL_H_FILES)
--
2.3.1
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #31 from MirceaKitsune --- I poked the developers about this on IRC, since I stopped getting replies here. I was reminded about posting an API trace, so other developers could replicate the problem without having to install Second Life. I already generated one a while ago, which I re-uploaded on my Google Drive at the following link: https://drive.google.com/file/d/0B5lE6Cy2gg_rZXV6aW1RQV80ODg/view?usp=sharing Playing back this trace reproduces the GPU freeze for me, so it should contain the trigger for the issue. I understand this is specific to Radeon 6xxx cards and related to the "fast clear" feature, so it needs to be tested on a similar model of card. I will await for feedback on the issue... thank you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/660c21dc/attachment-0001.html>
[Bug 89957] vm protection faults in piglit lest: texsubimage cube_map_array pbo
https://bugs.freedesktop.org/show_bug.cgi?id=89957 --- Comment #1 from Alex Deucher --- Possibly fixed by this patch: http://lists.freedesktop.org/archives/mesa-dev/2015-April/081426.html See also: http://lists.freedesktop.org/archives/mesa-dev/2015-April/081424.html -- 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/20150408/f55a030a/attachment.html>
[Bug 89957] vm protection faults in piglit lest: texsubimage cube_map_array pbo
https://bugs.freedesktop.org/show_bug.cgi?id=89957 Bug ID: 89957 Summary: vm protection faults in piglit lest: texsubimage cube_map_array pbo Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: tstellar at gmail.com QA Contact: dri-devel at lists.freedesktop.org To reproduce: /home/tstellar/piglit/bin/texsubimage cube_map_array pbo -auto -fbo I've spent some time debugging this and it appears the result from the v_cubeid_f32 instruction is causing the shader to access memory outside the bounds of the texture. If I replace v_cubeid_f32 $dst, $src0, $src1, $src2 instructions with v_mov_f32 $dst, 0.0 or v_mov_f32 $dst, 1.0 I no longer see vm protection faults. However, if I replace the v_cubeid_f32 instructions with v_mov_f32 $dst, 2.0 then the vm protection faults return. So, it seems the bad case is whenever the face id is computed as >= 2.0f. -- 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/20150408/6acdc1eb/attachment.html>
[PATCH] ASoC: max98090: add shutdown callback for max98090
To fix pop noise when shutdown,the pop noise during shutdown
is the pmic cutoff power of codec without any notice.
Signed-off-by: jay.xu
Signed-off-by: zhengxing
Signed-off-by: Caesar Wang
Serien-cc: linux-kernel at vger.kernel.org
Serien-cc: devicetree at vger.kernel.org
Serien-cc: dianders at chromium.org
---
sound/soc/codecs/max98090.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..066954a0 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2611,6 +2611,22 @@ static int max98090_i2c_remove(struct i2c_client *client)
return 0;
}
+static void max98090_i2c_shutdown(struct i2c_client *i2c)
+{
+ struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
+
+ dev_info(&i2c->dev, "shut down device\n");
+
+ /* Enable volume smoothing, disable zero cross. This will cause
+* a quick 40ms ramp to mute on shutdown.
+*/
+ regmap_write(max98090->regmap,
+ M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
+ regmap_write(max98090->regmap,
+ M98090_REG_DEVICE_SHUTDOWN, 0x00);
+ msleep(40);
+}
+
#ifdef CONFIG_PM
static int max98090_runtime_resume(struct device *dev)
{
@@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
},
.probe = max98090_i2c_probe,
.remove = max98090_i2c_remove,
+ .shutdown = max98090_i2c_shutdown,
.id_table = max98090_i2c_id,
};
--
1.9.1
[PATCH 0/1] ASoC: max98090: add shutdown callback for max98090
Tested on veyron devices,play music then shutdown device,here carefully to speaker or headphone. Caesar Wang (1): ASoC: max98090: add shutdown callback for max98090 sound/soc/codecs/max98090.c | 17 + 1 file changed, 17 insertions(+) -- 1.9.1
[PATCH 1/1] drm/exynos: Fix FIMD buffer size calculation
Commit adacb228d72b ("drm: Exynos: Respect framebuffer pitch for
FIMD/Mixer") fixed the buffer size calculation by using the FB
pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
struct *_win_data abstraction on planes") added a regression so
fix the buffer size calculation again.
Tested on Chromebook Snow / Peach Pit.
Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on
planes")
Signed-off-by: Daniel Stone
Tested-by: Javier Martinez Canillas
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7964b278eefb..90111b87c963 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -662,7 +662,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
writel(val, ctx->regs + VIDWx_BUF_START(win, 0));
/* buffer end address */
- size = plane->pitch * plane->crtc_height * (plane->bpp >> 3);
+ size = plane->pitch * plane->crtc_height;
val = (unsigned long)(dma_addr + size);
writel(val, ctx->regs + VIDWx_BUF_END(win, 0));
@@ -672,7 +672,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
plane->crtc_width, plane->crtc_height);
/* buffer size */
- buf_offsize = (plane->fb_width - plane->crtc_width) * (plane->bpp >> 3);
+ buf_offsize = plane->pitch - (plane->crtc_width * (plane->bpp >> 3));
line_size = plane->crtc_width * (plane->bpp >> 3);
val = VIDW_BUF_SIZE_OFFSET(buf_offsize) |
VIDW_BUF_SIZE_PAGEWIDTH(line_size) |
--
2.1.4
[Intel-gfx] [PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport compliance testing
On 4/8/2015 9:51 AM, Paulo Zanoni wrote:
> 2015-03-31 14:15 GMT-03:00 Todd Previte :
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of detecting
>> a corrupt EDID. To do this, the test sets up an invalid EDID header to be
>> read by the source
>> device. Unfortunately, the DRM EDID reading and parsing functions are
>> actually too good in
>> this case and prevent the source from reading the corrupted EDID. The result
>> is a failed
>> compliance test.
>>
>> In order to successfully pass the test, the raw EDID header must be checked
>> on each read
>> to see if has been "corrupted". If an invalid raw header is detected, a flag
>> is set that
>> allows the compliance testing code to acknowledge that fact and react
>> appropriately. The
>> flag is automatically cleared on read.
>>
>> This code is designed to expressly work for compliance testing without
>> disrupting normal
>> operations for EDID reading and parsing.
>>
>> Signed-off-by: Todd Previte
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_edid.c | 33 +
>> drivers/gpu/drm/i915/intel_dp.c | 17 +
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> include/drm/drm_edid.h | 5 +
>> 4 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 53bc7a6..3d4f473 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -990,6 +990,32 @@ static const u8 edid_header[] = {
>> 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
>> };
>>
>> +
>> +/* Flag for EDID corruption testing
>> + * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
>> + */
>> +static bool raw_edid_header_corrupted;
> A static variable like this is not a good design, especially for a
> module like drm.ko. If you really need this, please store it inside
> some struct. But see below first.
Per our discussion this morning, I concur. This has been removed in
favor of a different solution that uses a new boolean flag in the
drm_connector struct.
Capturing more of the discussion here, the static boolean was a bad idea
to begin with and needed to be removed. One solution was to make the
flag non-static and non-clear-on-read, then add a separate clear()
function. But it still had the problem of potential misuse other places
in the code. The current solution (which will be posted with V5)
modifies the is_valid() function and adds a flag in the drm_connector
struct that can be used to detect this low-level header corruption.
>
>> +
>> +/**
>> + * drm_raw_edid_header_valid - check to see if the raw header is
>> + * corrupt or not. Used solely for Displayport compliance
>> + * testing and required by Link CTS Core 1.2 rev1.1 4.2.2.6.
>> + * @raw_edid: pointer to raw base EDID block
>> + *
>> + * Indicates whether the original EDID header as read from the
>> + * device was corrupt or not. Clears on read.
>> + *
>> + * Return: true if the raw header was corrupt, otherwise false
>> + */
>> +bool drm_raw_edid_header_corrupt(void)
>> +{
>> + bool corrupted = raw_edid_header_corrupted;
>> +
>> + raw_edid_header_corrupted = 0;
>> + return corrupted;
>> +}
>> +EXPORT_SYMBOL(drm_raw_edid_header_corrupt);
>> +
>> /**
>>* drm_edid_header_is_valid - sanity check the header of the base EDID
>> block
>>* @raw_edid: pointer to raw base EDID block
>> @@ -1006,6 +1032,13 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
>> if (raw_edid[i] == edid_header[i])
>> score++;
>>
>> + if (score != 8) {
>> + /* Log and set flag here for EDID corruption testing
>> +* Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
>> +*/
>> + DRM_DEBUG_DRIVER("Raw EDID header invalid\n");
>> + raw_edid_header_corrupted = 1;
>> + }
> The problem is that here we're limiting ourselves to just a bad edid
> header, not a bad edid in general, so there are many things which we
> might not get - such as a simple wrong checksum edid value. I remember
> that on the previous patch you calculated the whole checksum manually,
> but I don't see that code anymore. What was the reason for the change?
So this code is specifically for the 4.2.2.6 compliance test that is
looking for nothing more than an invalid EDID header. In fact, the test
unit only sets that header as invalid once, so if you miss it on the
first read, you can't go back and check it again later - the test will
now fail. So catching the general case isn't really what this is about -
it's about being able to detect a corrupt EDID header even if it only
happens once.
Honestly, the DRM EDID code is VERY good about catching corruption cases
and in the case of corrupted headers, fixing them and moving on. I had
to tie into it at a fairly low level in order to catch the invalid
header before the code fi
[PATCH 2/3] drm:msm: Initial Add Writeback Support
> On Tue, Apr 07, 2015 at 03:55:45PM -, jilaiw at codeaurora.org wrote: >> > On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote: >> >> So, from a quick look, it seems like there is a lot of potential to >> >> split the v4l part out into some drm helpers.. it looks pretty >> >> generic(ish), or at least it could be with some strategically placed >> >> vfuncs in drm_v4l2_helper_funcs. >> >> >> >> I do think we need to figure out the auth/security situation. We >> >> probably don't want to let arbitrary processes open a v4l device and >> >> snoop on the screen contents. We perhaps could re-use the dri2 drm >> >> auth stuff (v4l2_drm_get_magic ioctl?). Or, well, it would be nice >> if >> >> the wb device could be made to not exist in /dev at all, and >> >> pre-open'd fd returned from an ioctl on the drm device, but not >> really >> >> sure if that is possible (or too weird). Once the compositor process >> >> has the v4l device open and authenticated somehow, I expect it would >> >> use fd passing to pass the fd off to a trusted helper process. >> > >> > Please don't resurrect the magic stuff ;-) >> > >> > Anyway I discussed this a bit with Laurent and we figured the best way >> to >> > wire up writeback support is by using drm framebuffers. Then you can >> use >> > atomic flips to create a new snapshot. Of course that won't work with >> hw >> > where writeback is continuous, there v4l is a much better fit. And we >> also >> > have hardware where some v4l pipeline could directly feed into a drm >> > output pipeline, so we need a generic way to connect v4l and drm >> anyway. >> > For that I think we should add a new flag to addfb2 (or a new >> addfbv4l) >> > which creates a magic framebuffer from a v4l input/output. Some values >> > like stride don't make sense in such a virtual framebuffer, but pixel >> > format and size are all needed. >> > >> > This way we don't need parallel abis for single-shot writeback >> directly >> > into framebuffers and for continuous writeback through v4l, we can >> reuse >> > the same drm framebuffer ones. And this also solves the security >> issues >> > since no one can start writeback without the drm device owner's >> consent, >> > so no need to reinvent anything there. And with atomic we already have >> > almost everything there: For the writeback framebuffer we only need a >> new >> > "WRITEBACK" property (which takes an fb id) and the small extension to >> > create v4l-backed framebuffers. >> > >> > Cheers, Daniel >> > -- >> > Daniel Vetter >> > Software Engineer, Intel Corporation >> > http://blog.ffwll.ch >> > >> Hi Daniel, >> >> 1. This change is to implement a continuous writeback. >> 2. As you said, we need "a generic way to connect v4l and drm". >> Especially how to share the buffer information between v4l and drm for >> writeback output. >> >> Below are just some details of this change: >> >> In current implementation, I expect the output buffer is dma buffer >> which could be from GEM object (drm) or from video encoder (V4l). Once >> the buffer is queued into V4l driver, it will be converted into a GEM >> object and then pass it to drm as writeback output buffer. Once the >> buffer is captured, it will notify V4l driver to let user dequeue >> buffer. >> >> Drm will notice there is a Virtual Connector (maybe a new type WRITEBACK >> can be added), but it will only be "connected" until V4l >> starts streaming. > > Yes we definitely should add a new connector type WRITEBACK. And just the > connector kinda works for your hw design where writeback works like a > separate encoder. But there's also hw out there where any crtc can be > written back, and for those cases we need explicit properties. Then > there's also the one-shot vs. continuous issues. yes, this change is specific for msm chip. In order to cover the other writeback use cases, new properties and framework changes are required. > > Given all that I still think you want an explicit drm framebuffer to > connect the kms and the v4l side of things. That would also help a bit > with making it clear which v4l connects to which drm device. yes, it will help. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >
[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions
https://bugs.freedesktop.org/show_bug.cgi?id=88493 --- Comment #17 from Timo Aaltonen --- Not sure if I'm seeing the same, but I have the HDMI/DP audio device available with 4.0-rcN, just get no sound through it. This worked with 3.19. Another datapoint is that pulling most of core drm changes from 4.0-rc1 (for SKL backport) also broke it, so that the HDMI audio device isn't even available. -- 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/20150408/cfb891cc/attachment-0001.html>
[Intel-gfx] [PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport compliance testing
2015-03-31 14:15 GMT-03:00 Todd Previte :
> Displayport compliance test 4.2.2.6 requires that a source device be capable
> of detecting
> a corrupt EDID. To do this, the test sets up an invalid EDID header to be
> read by the source
> device. Unfortunately, the DRM EDID reading and parsing functions are
> actually too good in
> this case and prevent the source from reading the corrupted EDID. The result
> is a failed
> compliance test.
>
> In order to successfully pass the test, the raw EDID header must be checked
> on each read
> to see if has been "corrupted". If an invalid raw header is detected, a flag
> is set that
> allows the compliance testing code to acknowledge that fact and react
> appropriately. The
> flag is automatically cleared on read.
>
> This code is designed to expressly work for compliance testing without
> disrupting normal
> operations for EDID reading and parsing.
>
> Signed-off-by: Todd Previte
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_edid.c | 33 +
> drivers/gpu/drm/i915/intel_dp.c | 17 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> include/drm/drm_edid.h | 5 +
> 4 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 53bc7a6..3d4f473 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -990,6 +990,32 @@ static const u8 edid_header[] = {
> 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
> };
>
> +
> +/* Flag for EDID corruption testing
> + * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
> + */
> +static bool raw_edid_header_corrupted;
A static variable like this is not a good design, especially for a
module like drm.ko. If you really need this, please store it inside
some struct. But see below first.
> +
> +/**
> + * drm_raw_edid_header_valid - check to see if the raw header is
> + * corrupt or not. Used solely for Displayport compliance
> + * testing and required by Link CTS Core 1.2 rev1.1 4.2.2.6.
> + * @raw_edid: pointer to raw base EDID block
> + *
> + * Indicates whether the original EDID header as read from the
> + * device was corrupt or not. Clears on read.
> + *
> + * Return: true if the raw header was corrupt, otherwise false
> + */
> +bool drm_raw_edid_header_corrupt(void)
> +{
> + bool corrupted = raw_edid_header_corrupted;
> +
> + raw_edid_header_corrupted = 0;
> + return corrupted;
> +}
> +EXPORT_SYMBOL(drm_raw_edid_header_corrupt);
> +
> /**
> * drm_edid_header_is_valid - sanity check the header of the base EDID block
> * @raw_edid: pointer to raw base EDID block
> @@ -1006,6 +1032,13 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
> if (raw_edid[i] == edid_header[i])
> score++;
>
> + if (score != 8) {
> + /* Log and set flag here for EDID corruption testing
> +* Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
> +*/
> + DRM_DEBUG_DRIVER("Raw EDID header invalid\n");
> + raw_edid_header_corrupted = 1;
> + }
The problem is that here we're limiting ourselves to just a bad edid
header, not a bad edid in general, so there are many things which we
might not get - such as a simple wrong checksum edid value. I remember
that on the previous patch you calculated the whole checksum manually,
but I don't see that code anymore. What was the reason for the change?
Also, while reviewing the patch I just discovered
connector->bad_edid_counter. Can't we just use it instead of this
patch? I mean: grab the current counter, check edid, see if the
counter moved.
> return score;
> }
> EXPORT_SYMBOL(drm_edid_header_is_valid);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dc87276..57f8e43 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3824,6 +3824,9 @@ update_status:
>&response, 1);
> if (status <= 0)
> DRM_DEBUG_KMS("Could not write test response to sink\n");
> +
> + /* Clear flag here, after testing is complete*/
> + intel_dp->compliance_edid_invalid = 0;
> }
>
> static int
> @@ -3896,6 +3899,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
> + struct drm_connector *connector = &intel_dp->attached_connector->base;
> + struct i2c_adapter *adapter = &intel_dp->aux.ddc;
> + struct edid *edid_read = NULL;
> +
> u8 sink_irq_vector;
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> @@ -3912,6 +3919,16 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> return;
> }
>
> + /* Compliance testing requires an EDID read for all HPD events
> +* Li
[PATCH 1/1] drm/exynos: Fix FIMD buffer size calculation
2015-04-08 Daniel Stone :
> Commit adacb228d72b ("drm: Exynos: Respect framebuffer pitch for
> FIMD/Mixer") fixed the buffer size calculation by using the FB
> pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
> struct *_win_data abstraction on planes") added a regression so
> fix the buffer size calculation again.
>
> Tested on Chromebook Snow / Peach Pit.
>
> Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on
> planes")
> Signed-off-by: Daniel Stone
> Tested-by: Javier Martinez Canillas
Reviewed-by: Gustavo Padovan
Gustavo
[Bug 89954] Dota2 crashes computer while playing when probably loading new particles
https://bugs.freedesktop.org/show_bug.cgi?id=89954 Bug ID: 89954 Summary: Dota2 crashes computer while playing when probably loading new particles Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: dogmadefe at hotmail.com QA Contact: dri-devel at lists.freedesktop.org It's been happening during the last month or so, around the first big team clash, when the ultis are used, the computer freezes for like 5 seconds, and then reboots. Before this, the computer used to freeze during the first clash, but it recovered. Before that, I played Dota2 for a lot of months without any problem. I have an FX6100 and HD7770. I use the open source drivers. Checking the error out log, I get something like this: Apr 06 21:39:24 arch gdm-Xorg-:0[307]: (WW) RADEON(0): flip queue failed: Device or resource busy Apr 06 21:39:24 arch gdm-Xorg-:0[307]: (WW) RADEON(0): Page flip failed: Device or resource busy Apr 06 21:40:21 arch steam.desktop[6478]: [2015-04-0Installing breakpad exception handler for appid(steam)/version(1424305157) Apr 06 21:40:22 arch steam.desktop[6478]: Installing breakpad exception handler for appid(steam)/version(1424305157) Apr 06 21:40:23 arch steam.desktop[6478]: Installing breakpad exception handler for appid(steam)/version(1424305157) Apr 06 21:48:08 arch gdm-Xorg-:0[307]: (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 331918 < target_msc 331919 Apr 06 21:51:52 arch kernel: radeon :01:00.0: GPU fault detected: 147 0x000c0401 Apr 06 21:51:52 arch kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0FF8 Apr 06 21:51:52 arch kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C004001 Apr 06 21:51:52 arch kernel: VM fault (0x01, vmid 6) at page 267911168, read from TC (4) Apr 06 21:52:02 arch kernel: radeon :01:00.0: ring 4 stalled for more than 10083msec Apr 06 21:52:02 arch kernel: radeon :01:00.0: GPU lockup (current fence id 0x00028b69 last fence id 0x00028b6e on ring 4) Apr 06 21:52:03 arch kernel: radeon :01:00.0: Saved 652 dwords of commands on ring 0. Apr 06 21:52:03 arch kernel: radeon :01:00.0: GPU softreset: 0x00ED Apr 06 21:52:03 arch kernel: radeon :01:00.0: GRBM_STATUS = 0xE65E4028 Apr 06 21:52:03 arch kernel: radeon :01:00.0: GRBM_STATUS_SE0 = 0xCF80 Apr 06 21:52:03 arch kernel: radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 -- 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/20150408/35644e6b/attachment.html>
[PATCH RFC 000/111] Etnaviv DRM driver
Hi Lucas, Thanks for the patch series ! It sounds great, even if it probably needs to be squashed down to some patches, as most of the patches are fixes. 2015-04-02 22:01 GMT+02:00 Robert Nelson : > On Thu, Apr 2, 2015 at 10:59 AM, Lucas Stach > wrote: >> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM >> Linux: >>> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote: >>> > Hey all, >>> > >>> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily >>> > influenced by the MSM driver, as can be clearly seen with the first >>> > commits. >>> >>> You should be copying Greg KH for staging too. >>> >> I didn't do that on purpose. As stated below in the cover letter I'm not >> really happy to push things into staging. Especially after the >> experience with imx-drm, where it took us a considerable amount of work >> to even get people to look at the code after it had landed in staging. >> >> If possible I would like to collect feedback now and only if someone >> feels genuinely unhappy about this code living under drivers/gpu/drm >> then keep it in staging. Otherwise I would like to move it when removing >> the RFC from this patchset. > > Looks good so far Lucas on my wand quad.. > > Where's your libdrm/mesa tree located that you've been working on? > > debian at arm:~$ uname -r > 4.0.0-rc6-armv7-devel-r24 > debian at arm:~$ dmesg | grep etnaviv > [3.711866] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops) > [3.718015] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops) > [3.724133] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops) > [3.730351] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > [3.771045] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 > [3.802887] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > [3.848287] [drm] Initialized etnaviv 1.0.0 20150302 on minor 1 Exactly the same question, I would like to give it a try on my board, how can I test it ? Thanks, JM
[PATCH 1/4] drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
On 31.03.2015 18:13, Alex Deucher wrote: > On Tue, Mar 31, 2015 at 11:36 AM, Christian König > wrote: >> From: Christian König >> >> We somehow try to free the SG table twice. >> >> Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 >> >> Signed-off-by: Christian König >> Cc: > For the series: > Reviewed-by: Alex Deucher > > I've added the first two to my -fixes tree. Could you add the other two to your -next tree? You probably need to merge with -fixes to do so. Regards, Christian. > > Alex > >> --- >> drivers/gpu/drm/radeon/radeon_ttm.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >> b/drivers/gpu/drm/radeon/radeon_ttm.c >> index d02aa1d..b292aca 100644 >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c >> @@ -598,6 +598,10 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt >> *ttm) >> enum dma_data_direction direction = write ? >> DMA_BIDIRECTIONAL : DMA_TO_DEVICE; >> >> + /* double check that we don't free the table twice */ >> + if (!ttm->sg->sgl) >> + return; >> + >> /* free the sg table and pages again */ >> dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction); >> >> -- >> 1.9.1 >>
[PATCH 2/2] drm/msm: dsi: Provide option to force continuous HS clock
Some DSI peripherals rely on the HS clock on DSI clock lane as their clock source. If the clock lane transitions between HS and LP states, it can disrupt the functioning of such peripherals. The mipi dsi mode flag MIPI_DSI_CLOCK_NON_CONTINUOUS already exists for such peripheral drivers. Use it to configure the bit CLKLN_HS_FORCE_REQUEST in DSI_LANE_CTRL. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/dsi/dsi_host.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index fdc54e3..169e06e 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -787,6 +787,11 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable, dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL, DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_0123)); } + + if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) + dsi_write(msm_host, REG_DSI_LANE_CTRL, + DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST); + data |= DSI_CTRL_ENABLE; dsi_write(msm_host, REG_DSI_CTRL, data); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/2] drm/msm: dsi: Update headers (add DSI_LANE_CTRL register)
DSI_LANE_CTRL provides bitfield CLKLN_HS_FORCE_REQUEST that forces the DSI clock lane to always enter HS mode. This is needed by some DSI peripherals which rely on the DSI clock lane as their clock source. If the clock lane transitions between different states, it can disrupt the functioning of such peripherals. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/dsi/dsi.xml.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h b/drivers/gpu/drm/msm/dsi/dsi.xml.h index 1dcfae2..e0f3e62 100644 --- a/drivers/gpu/drm/msm/dsi/dsi.xml.h +++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h @@ -8,8 +8,8 @@ http://github.com/freedreno/envytools/ git clone https://github.com/freedreno/envytools.git The rules-ng-ng source files this header was generated from are: -- /usr2/hali/local/envytools/envytools/rnndb/dsi/dsi.xml ( 18681 bytes, from 2015-03-04 23:08:31) -- /usr2/hali/local/envytools/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2015-01-28 21:43:22) +- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/dsi/dsi.xml( 18802 bytes, from 2015-04-05 09:42:01) +- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2015-02-09 03:18:10) Copyright (C) 2013-2015 by the following authors: - Rob Clark (robclark) @@ -394,6 +394,9 @@ static inline uint32_t DSI_CLKOUT_TIMING_CTRL_T_CLK_POST(uint32_t val) #define DSI_EOT_PACKET_CTRL_TX_EOT_APPEND 0x0001 #define DSI_EOT_PACKET_CTRL_RX_EOT_IGNORE 0x0010 +#define REG_DSI_LANE_CTRL 0x00a8 +#define DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST 0x1000 + #define REG_DSI_LANE_SWAP_CTRL 0x00ac #define DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL__MASK 0x0007 #define DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL__SHIFT 0 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[GIT PULL] Use of-graph helpers to loop over endpoints
On Wed, Apr 08, 2015 at 11:23:29AM +1000, Dave Airlie wrote: > On 31 March 2015 at 21:58, Philipp Zabel wrote: > > Hi Dave, > > > > now that the of-graph helper tag has been merged into > > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next > > could you merge it and these patches that use it to clean up looping > > over of-graph endpoints in drm drivers: > > This causes build failures fixed by a patch in Rob's tree, you > probably unfortunately need to rebase on Rob's tree > and send me that so I get a tree that builds out of this. > > Dave. Rebased on Rob's tree, the following changes since commit 01218bf14ee60d4a2d6c667ebdbba3ae9a7a1d66: of: Explicitly include linux/types.h in of_graph.h (2015-03-26 12:14:56 -0500) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/of-graph-drm-2015-04-08 for you to fetch changes up to ecaa490fd4d28692203bec028513fbac29c7: drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break (2015-04-08 11:14:27 +0200) drm: Use of-graph helpers to loop over endpoints Convert all drm callers that use of_graph_get_next_endpoint to loop over of-graph endpoints to the newly introduced for_each_endpoint_of_node helper macro. Philipp Zabel (4): drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id drm/rcar-du: use for_each_endpoint_of_node macro drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break drivers/gpu/drm/drm_of.c| 10 +++--- drivers/gpu/drm/imx/imx-drm-core.c | 11 --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16 +++- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11 --- 4 files changed, 14 insertions(+), 34 deletions(-) regards Philipp
[PATCH] rnndb: dsi: Add DSI_LANE_CTRL info
DSI_LANE_CTRL register provides a bitfield CLKLN_HS_FORCE_REQUEST that forces the clock lane to always enter HS mode. This is needed by certain DSI peripherals which rely on the DSI host as their external clock source. Signed-off-by: Archit Taneja --- rnndb/dsi/dsi.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml index 480ec46..e645c45 100644 --- a/rnndb/dsi/dsi.xml +++ b/rnndb/dsi/dsi.xml @@ -187,6 +187,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
st_TexSubImage: unaligned memcpy performance
Hi, I have an issue where st_TexSubImage causes very high CPU load in __memcpy_sse2_unaligned (Mesa 10.1.3, Xorg 1.15.1, radeon driver, HD 7870). Any obvious causes / tips for this? e.g. align textures or use different format/type? I 've tried using GL_BGRA/GL_UNSIGNED_BYTE and GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85 85../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85 #1 0x7fffb572f154 in memcpy (__len=7680, __src=, __dest=0x7fff5835f800) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #2 st_TexSubImage (ctx=0x1b91420, dims=, texImage=0x1f81710, xoffset=0, yoffset=0, zoffset=0, width=1920, height=1080, depth=1, format=32993, type=5121, pixels=0xdacf90, unpack=0x1bad590) at ../../../../src/mesa/state_tracker/st_cb_texture.c:752 #3 0x7fffb56c283d in texsubimage (ctx=0x1b91420, dims=dims at entry=2, target=3553, level=0, xoffset=0, yoffset=0, zoffset=zoffset at entry=0, width=1920, height=1080, depth=depth at entry=1, format=format at entry=32993, type=type at entry=5121, pixels=pixels at entry=0xdacf90) at ../../../../src/mesa/main/teximage.c:3445 #4 0x7fffb56c659c in _mesa_TexSubImage2D (target=, level=, xoffset=, yoffset=, width=, height=, format=32993, type=5121, pixels=0xdacf90) at ../../../../src/mesa/main/teximage.c:3483 #5 0x7346191a in ?? () from /opt/build/Qt/5.4/gcc_64/lib/libQt5Gui.so.5 #6 0x7345e6ab in ?? () from /opt/build/Qt/5.4/gcc_64/lib/libQt5Gui.so.5 #7 0x7345ea32 in QOpenGLTexture::setData(int, QOpenGLTexture::PixelFormat, QOpenGLTexture::PixelType, void*, QOpenGLPixelTransferOptions const*) () from /opt/build/Qt/5.4/gcc_64/lib/libQt5Gui.so.5 thanks for any help, - Vasilis -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/5ed89b25/attachment-0001.html>
[PATCH] ASoC: max98090: add shutdown callback for max98090
Hi Caesar,
Am Mittwoch, 8. April 2015, 16:52:08 schrieb Caesar Wang:
> To fix pop noise when shutdown,the pop noise during shutdown
> is the pmic cutoff power of codec without any notice.
>
> Signed-off-by: jay.xu
> Signed-off-by: zhengxing
> Signed-off-by: Caesar Wang
>
> Serien-cc: linux-kernel at vger.kernel.org
> Serien-cc: devicetree at vger.kernel.org
> Serien-cc: dianders at chromium.org
>
> ---
>
> sound/soc/codecs/max98090.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
> index b112b1c..066954a0 100644
> --- a/sound/soc/codecs/max98090.c
> +++ b/sound/soc/codecs/max98090.c
> @@ -2611,6 +2611,22 @@ static int max98090_i2c_remove(struct i2c_client
> *client) return 0;
> }
>
> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
> +{
> + struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
> +
> + dev_info(&i2c->dev, "shut down device\n");
is this dev_info really necessary? dev_dbg might be better, or leave it out
completely, as it doesn't really provide any additional benefit.
> +
> + /* Enable volume smoothing, disable zero cross. This will cause
> + * a quick 40ms ramp to mute on shutdown.
> + */
Comment style is off ... should be
/*
* Enable volume smoothing, disable zero cross. This will cause
* a quick 40ms ramp to mute on shutdown.
*/
> + regmap_write(max98090->regmap,
> + M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
> + regmap_write(max98090->regmap,
> + M98090_REG_DEVICE_SHUTDOWN, 0x00);
> + msleep(40);
> +}
> +
> #ifdef CONFIG_PM
> static int max98090_runtime_resume(struct device *dev)
> {
> @@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
> },
> .probe = max98090_i2c_probe,
> .remove = max98090_i2c_remove,
> + .shutdown = max98090_i2c_shutdown,
> .id_table = max98090_i2c_id,
> };
[GIT PULL] Use of-graph helpers to loop over endpoints
On 31 March 2015 at 21:58, Philipp Zabel wrote: > Hi Dave, > > now that the of-graph helper tag has been merged into > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next > could you merge it and these patches that use it to clean up looping > over of-graph endpoints in drm drivers: This causes build failures fixed by a patch in Rob's tree, you probably unfortunately need to rebase on Rob's tree and send me that so I get a tree that builds out of this. Dave.
[PATCH] drm/bridge: dw-hdmi: Staticize dw_hdmi_bridge_funcs
On Thu, Apr 02, 2015 at 07:11:04PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Staticize dw_hdmi_bridge_funcs to fix the following sparse warning: > > drivers/gpu/drm/bridge/dw_hdmi.c:1458:25: warning: symbol > 'dw_hdmi_bridge_funcs' was not declared. Should it be static? > > Signed-off-by: Fabio Estevam > --- > drivers/gpu/drm/bridge/dw_hdmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/7c0bc66f/attachment-0001.sig>
[PATCH RFC 003/111] staging: etnaviv: add drm driver
Am Mittwoch, den 08.04.2015, 10:13 +1000 schrieb Dave Airlie: > >> Okay got it. > >> > >> > In the common case when nothing has disturbed the context we don't want > >> > to insert the context buffer, as we really want minimal state updates in > >> > that case. We need a way to tell the kernel which command buffer is the > >> > context buffer, so the kernel only splices this buffer into the stream > >> > if the context is dirty. > >> > >> So the context buffer holds the full GPU context and the kernel does the > >> partial > >> update of the current hardware context. This makes the user space a lot > >> simpler > >> as we can send the whole context and do not need take care of partial > >> updates. > >> > >> I like the idea. > >> > > I still think your understanding is not completely what I wanted to say > > with that. > > > > You are right that I want to kick out all this state tracking on > > individual registers. But I don't want to move it into the kernel, but > > scrap it altogether. > > > > Let me try to explain this in a bit more detail: > > > > First let's postulate that we already have pretty good dirty state > > tracking on the gallium state object level. I don't think it buys us > > anything to do more fine grained state tracking. > > > > The gallium userspace driver only pushes state _changes_ to a normal > > command buffer. For example this means that if nothing has changed since > > the last submit of this process except some vertex buffers the only > > thing that will be contained in the command buffer are a few SET_STATEs > > for the vertex buffer addresses and the DRAW call. > > > > The context buffer in contrast holds the full GPU context as of the last > > flush. So if you flush the stream MESA dumps the full Gallium state into > > the context buffer. > > > > Now if you submit both buffers together the kernel can check if your > > context is still valid (nothing other has touched the GPU since your > > last submit) and in that case only splice the normal command bo into the > > stream. If something has changed since your last submit the kernel will > > splice the context buffer first, then the command buffer. This way you > > always get a predictable state without tracking any GPU state on a > > register level. > > > > My memory of trying to make this work in some other driver > in some other time is pretty bad. > > I think I realised that you never had the "last known good" state, you'd just > generate the latest state, > > so it was really hard to split things into two state buffers, one containing > the > "current" state and one with state updates, in the end I gave up and just > submitted everything everytime. > > I'm not saying its not possible, but the userspace driver model didn't > lend itself > to making it easy. > Hm, this together with the argument that we have to push out all state with relocs anyway on a single submit really makes me think we should do away with the context buffer stuff and just dirty all state on flush in the userspace driver. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state
Am Dienstag, den 07.04.2015, 18:14 -0400 schrieb Rob Clark: > On Tue, Apr 7, 2015 at 12:59 PM, Christian Gmeiner > wrote: > >>> And each Core(/FE) has its own device node. Does this make any sense? > >>> > >> And I don't get why each core needs to have a single device node. IMHO > >> this is purely an implementation decision weather to have one device > >> node for all cores or one device node per core. > >> > > > > It is an important decision. And I think that one device node per core > > reflects the > > hardware design to 100%. > > > > Although I haven't really added support for devices with multiple > pipe, the pipe param in msm ioctls is intended to deal with hw that > has multiple pipes. (And I assume someday adreno will sprout an extra > compute pipe, where we'll need this.) > > in your case, it sounds a bit like you should have an ioctl to > enumerate the pipes, and a getcap that returns a bitmask of compute > engine(s) supported by a given pipe. Or something roughly like that. > The current interface already allows for that. Each core get a simple integer assigned. The userspace can then just ask for the feature bits of a core with an increasing integer as index. The feature bits tell you if the core is capable of executing 2D, 3D or VG pipe states. Since we construct the DRM device only when all cores are probed and tear it down when one of them goes away there are no holes in the index space. So once you hit ENODEV when asking for the feature bits of a core you know that there are no more cores to enumerate. > >> For now I could only see that one device node per core makes things > >> harder to get right, while I don't see a single benefit. > >> > > > > What makes harder to get it right? The needed changes to the kernel > > driver are not that > > hard. The user space is an other story but thats because of the > > render-only thing, where we > > need to pass (prime) buffers around and do fence syncs etc. In the end > > I do not see a > > showstopper in the user space. > > I assume the hw gives you a way to do fencing between pipes? It seems > at least convenient not to need to expose that via dmabuf+fence, since > that is a bit heavyweight if you end up needing to do things like > texture uploads/downloads or msaa resolve on one pipe synchronized to > rendering happening on another.. > The cores are separate entities with no internal synchronization AFAIK. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state
Am Dienstag, den 07.04.2015, 22:25 +0100 schrieb Russell King - ARM Linux: > On Tue, Apr 07, 2015 at 06:59:59PM +0200, Christian Gmeiner wrote: > > Hi Lucas. > > > > 2015-04-07 17:29 GMT+02:00 Lucas Stach : > > > And I don't get why each core needs to have a single device node. IMHO > > > this is purely an implementation decision weather to have one device > > > node for all cores or one device node per core. > > > > It is an important decision. And I think that one device node per core > > reflects the hardware design to 100%. > > Since when do the interfaces to userspace need to reflect the hardware > design? > > Isn't the point of having a userspace interface, in part, to abstract > the hardware design details and provide userspace with something that > is relatively easy to use without needlessly exposing the variation > of the underlying hardware? > > Please get away from the idea that userspace interfaces should reflect > the hardware design. > > > What makes harder to get it right? The needed changes to the kernel > > driver are not that hard. The user space is an other story but thats > > because of the render-only thing, where we need to pass (prime) > > buffers around and do fence syncs etc. In the end I do not see a > > showstopper in the user space. > > The fence syncs are an issue when you have multiple cores - that's > something I started to sort out in my patch series, but when you > appeared to refuse to accept some of the patches, I stopped... > > The problem when you have multiple cores is one global fence event > counter which gets compared to the fence values in each buffer > object no longer works. > > Consider this scenario: > > You have two threads, thread A making use of a 2D core, and thread B > using the 3D core. > > Thread B submits a big long render operation, and the buffers get > assigned fence number 1. > > Thread A submits a short render operation, and the buffers get assigned > fence number 2. > > The 2D core finishes, and sends its interrupt. Etnaviv updates the > completed fence position to 2. > > At this point, we believe that fence numbers 1 and 2 are now complete, > despite the 3D core continuing to execute and operate on the buffers > with fence number 1. > > I'm certain that the fence implementation we currently have can't be > made to work with multiple cores with a few tweeks - we need something > better to cater for what is essentially out-of-order completion amongst > the cores. > > A simple resolution to that _would_ be your argument of exposing each > GPU as a separate DRM node, because then we get completely separate > accounting of each - but it needlessly adds an expense in userspace. > Userspace would have to make multiple calls - to each GPU DRM node - > to check whether the buffer is busy on any of the GPUs as it may not > know which GPU could be using the buffer, especially if it got it via > a dmabuf fd sent over the DRI3 protocol. To me, that sounds like a > burden on userspace. > And even simpler would be to have the monotonic increasing fence queue to be per core and allow each to GEM object to be on multiple queues. So when waiting for buffer idle, the kernel can easily make sure the object is idle on all attached fence queues. Same principle as with the MMU mappings right now: a single GEM object mapped to possibly different positions in the VM space of each core. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] ASoC: max98090: add shutdown callback for max98090
On Wed, Apr 08, 2015 at 04:52:08PM +0800, Caesar Wang wrote:
> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
> +{
> + struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
> +
> + dev_info(&i2c->dev, "shut down device\n");
Remove this, it's adding noise.
> +
> + /* Enable volume smoothing, disable zero cross. This will cause
> + * a quick 40ms ramp to mute on shutdown.
> + */
> + regmap_write(max98090->regmap,
> + M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
> + regmap_write(max98090->regmap,
> + M98090_REG_DEVICE_SHUTDOWN, 0x00);
> + msleep(40);
> +}
This is OK but equivalent code should be being added to the driver
remove path as the same thing should be happening there.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/c43d88ca/attachment.sig>
[PATCH] drm/msm: Fix a couple of 64-bit build warnings
From: Thierry Reding
Avoid casts from pointers to fixed-size integers to prevent the compiler
from warning. Print virtual memory addresses using %p instead. Also turn
a couple of %d/%x specifiers into %zu/%zd/%zx to avoid further warnings
due to mismatched format strings.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/msm/edp/edp_aux.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 8
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_iommu.c | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 5f5a84f6074c..208f9d47f82e 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -132,7 +132,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
/* msg sanity check */
if ((native && (msg->size > AUX_CMD_NATIVE_MAX)) ||
(msg->size > AUX_CMD_I2C_MAX)) {
- pr_err("%s: invalid msg: size(%d), request(%x)\n",
+ pr_err("%s: invalid msg: size(%zu), request(%x)\n",
__func__, msg->size, msg->request);
return -EINVAL;
}
@@ -155,7 +155,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
*/
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
- pr_err("%s: aux timeout, %d\n", __func__, ret);
+ pr_err("%s: aux timeout, %zd\n", __func__, ret);
goto unlock_exit;
}
DBG("completion");
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a4269119f9ea..f29ec362eb0a 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -94,7 +94,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, const
char *name,
}
if (reglog)
- printk(KERN_DEBUG "IO:region %s %08x %08lx\n", dbgname,
(u32)ptr, size);
+ printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr,
size);
return ptr;
}
@@ -102,7 +102,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev,
const char *name,
void msm_writel(u32 data, void __iomem *addr)
{
if (reglog)
- printk(KERN_DEBUG "IO:W %08x %08x\n", (u32)addr, data);
+ printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
writel(data, addr);
}
@@ -110,7 +110,7 @@ u32 msm_readl(const void __iomem *addr)
{
u32 val = readl(addr);
if (reglog)
- printk(KERN_ERR "IO:R %08x %08x\n", (u32)addr, val);
+ printk(KERN_ERR "IO:R %p %08x\n", addr, val);
return val;
}
@@ -177,7 +177,7 @@ static int get_mdp_ver(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(match_types, dev->of_node);
if (match)
- return (int)match->data;
+ return (int)(unsigned long)match->data;
#endif
return 4;
}
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 49dea4fb55ac..aa9c91b57358 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -477,7 +477,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
uint64_t off = drm_vma_node_start(&obj->vma_node);
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %d\n",
+ seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %zu\n",
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
msm_obj->read_fence, msm_obj->write_fence,
obj->name, obj->refcount.refcount.counter,
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 7acdaa5688b7..7ac2f1997e4a 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -60,7 +60,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint32_t iova,
u32 pa = sg_phys(sg) - sg->offset;
size_t bytes = sg->length + sg->offset;
- VERB("map[%d]: %08x %08x(%x)", i, iova, pa, bytes);
+ VERB("map[%d]: %08x %08x(%zx)", i, iova, pa, bytes);
ret = iommu_map(domain, da, pa, bytes, prot);
if (ret)
@@ -99,7 +99,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint32_t iova,
if (unmapped < bytes)
return unmapped;
- VERB("unmap[%d]: %08x(%x)", i, iova, bytes);
+ VERB("unmap[%d]: %08x(%zx)", i, iova, bytes);
BUG_ON(!PAGE_ALIGNED(bytes));
--
2.3.2
[PATCH 0/1] ASoC: max98090: add shutdown callback for max98090
On Wed, Apr 08, 2015 at 04:52:07PM +0800, Caesar Wang wrote: > > Tested on veyron devices,play music then shutdown device,here carefully > to speaker or headphone. > > > > Caesar Wang (1): > ASoC: max98090: add shutdown callback for max98090 Don't send cover letters for single patches, if there's anything that needs saying it should either be in the changelog or after the --- in the mail. If there's any content in the cover letter that's usually a sign that the changelog on the actual patch needs improving. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150408/d5abf5d4/attachment.sig>
[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state
Am Dienstag, den 07.04.2015, 18:59 +0200 schrieb Christian Gmeiner: > Hi Lucas. [...] > >> I don't get you naming scheme - sorry. > >> > >> For me one Core has a single FE. This single FE can have one pipe or > >> multiple pipes. A pipe is the execution unit select via SELECT_PIPE > >> command (2d, 3d, ..). > >> > >> In the Dove use case we have: > >> - 1 Core with one FE > >> - 2 pipelines > >> > >> In the imx6 case we have: > >> - 3 Cores (each has only one FE) > >> - every FE only support one type of pipeline. > >> > > Okay let's keep it at this: a core is an entity with a FE at the front. > > A pipe is the backend fed by the FE selected by the SELECT_PIPE command. > > > > This is currently confusing as I didn't change the naming in the API, > > but really the "pipe" parameter in the IOCTLs means core. I'll rename > > this for the next round. > > > > The current driver was written only for the imx6 use case. So it > combines one pipe > of the 3 GPU cores into one device node. And yes the pipe > parameter could be seen as core. But I think that this design is wrong. I did > not know it better at the time I started working on it. I think that I > would not be > that hard to change the driver in that way that every core has its own > device node > and the pipe parameter really is a pipe of that core. > > >> And each Core(/FE) has its own device node. Does this make any sense? > >> > > And I don't get why each core needs to have a single device node. IMHO > > this is purely an implementation decision weather to have one device > > node for all cores or one device node per core. > > > > It is an important decision. And I think that one device node per core > reflects the > hardware design to 100%. > I'll refer to Russells mail for this. > > For now I could only see that one device node per core makes things > > harder to get right, while I don't see a single benefit. > > > > What makes harder to get it right? The needed changes to the kernel > driver are not that > hard. The user space is an other story but thats because of the > render-only thing, where we > need to pass (prime) buffers around and do fence syncs etc. In the end > I do not see a > showstopper in the user space. > DMA-BUFs and fences on them are no showstopper, but are a burden on userspace that we don't _need_ to impose. So why should we do this? > What would you do if - I know/hope that this will never happen - there is a > SoC, > which integrates two 3d cores? > Please go back and read the patch at the top of this thread. Having multiple cores with the same pipe caps is entirely possible with the current driver. Each core gets assigned a simple integer index and userspace is responsible to look at the feature bits of each core/index, so having multiple 3D cores is not a problem at all. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PULL] drm-intel-fixes
Hi Dave, three commits, all cc: stable, to address Baytrail suspend/resume issues. BR, Jani. The following changes since commit f22e6e847115abc3a0e2ad7bb18d243d42275af1: Linux 4.0-rc7 (2015-04-06 15:39:45 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-04-08 for you to fetch changes up to 5df0582bf036bb5f9a8ad8db5884fe13a55347d1: drm/i915/vlv: remove wait for previous GFX clk disable request (2015-04-07 16:14:12 +0300) Deepak S (1): drm/i915/chv: Remove Wait for a previous gfx force-off Jesse Barnes (2): drm/i915/vlv: save/restore the power context base reg drm/i915/vlv: remove wait for previous GFX clk disable request drivers/gpu/drm/i915/i915_drv.c | 14 ++ drivers/gpu/drm/i915/i915_drv.h | 1 + 2 files changed, 3 insertions(+), 12 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH RFC 003/111] staging: etnaviv: add drm driver
>> Okay got it. >> >> > In the common case when nothing has disturbed the context we don't want >> > to insert the context buffer, as we really want minimal state updates in >> > that case. We need a way to tell the kernel which command buffer is the >> > context buffer, so the kernel only splices this buffer into the stream >> > if the context is dirty. >> >> So the context buffer holds the full GPU context and the kernel does the >> partial >> update of the current hardware context. This makes the user space a lot >> simpler >> as we can send the whole context and do not need take care of partial >> updates. >> >> I like the idea. >> > I still think your understanding is not completely what I wanted to say > with that. > > You are right that I want to kick out all this state tracking on > individual registers. But I don't want to move it into the kernel, but > scrap it altogether. > > Let me try to explain this in a bit more detail: > > First let's postulate that we already have pretty good dirty state > tracking on the gallium state object level. I don't think it buys us > anything to do more fine grained state tracking. > > The gallium userspace driver only pushes state _changes_ to a normal > command buffer. For example this means that if nothing has changed since > the last submit of this process except some vertex buffers the only > thing that will be contained in the command buffer are a few SET_STATEs > for the vertex buffer addresses and the DRAW call. > > The context buffer in contrast holds the full GPU context as of the last > flush. So if you flush the stream MESA dumps the full Gallium state into > the context buffer. > > Now if you submit both buffers together the kernel can check if your > context is still valid (nothing other has touched the GPU since your > last submit) and in that case only splice the normal command bo into the > stream. If something has changed since your last submit the kernel will > splice the context buffer first, then the command buffer. This way you > always get a predictable state without tracking any GPU state on a > register level. > My memory of trying to make this work in some other driver in some other time is pretty bad. I think I realised that you never had the "last known good" state, you'd just generate the latest state, so it was really hard to split things into two state buffers, one containing the "current" state and one with state updates, in the end I gave up and just submitted everything everytime. I'm not saying its not possible, but the userspace driver model didn't lend itself to making it easy. Dave.
[PATCH 2/3] drm:msm: Initial Add Writeback Support
On Tue, Apr 07, 2015 at 03:55:45PM -, jilaiw at codeaurora.org wrote: > > On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote: > >> So, from a quick look, it seems like there is a lot of potential to > >> split the v4l part out into some drm helpers.. it looks pretty > >> generic(ish), or at least it could be with some strategically placed > >> vfuncs in drm_v4l2_helper_funcs. > >> > >> I do think we need to figure out the auth/security situation. We > >> probably don't want to let arbitrary processes open a v4l device and > >> snoop on the screen contents. We perhaps could re-use the dri2 drm > >> auth stuff (v4l2_drm_get_magic ioctl?). Or, well, it would be nice if > >> the wb device could be made to not exist in /dev at all, and > >> pre-open'd fd returned from an ioctl on the drm device, but not really > >> sure if that is possible (or too weird). Once the compositor process > >> has the v4l device open and authenticated somehow, I expect it would > >> use fd passing to pass the fd off to a trusted helper process. > > > > Please don't resurrect the magic stuff ;-) > > > > Anyway I discussed this a bit with Laurent and we figured the best way to > > wire up writeback support is by using drm framebuffers. Then you can use > > atomic flips to create a new snapshot. Of course that won't work with hw > > where writeback is continuous, there v4l is a much better fit. And we also > > have hardware where some v4l pipeline could directly feed into a drm > > output pipeline, so we need a generic way to connect v4l and drm anyway. > > For that I think we should add a new flag to addfb2 (or a new addfbv4l) > > which creates a magic framebuffer from a v4l input/output. Some values > > like stride don't make sense in such a virtual framebuffer, but pixel > > format and size are all needed. > > > > This way we don't need parallel abis for single-shot writeback directly > > into framebuffers and for continuous writeback through v4l, we can reuse > > the same drm framebuffer ones. And this also solves the security issues > > since no one can start writeback without the drm device owner's consent, > > so no need to reinvent anything there. And with atomic we already have > > almost everything there: For the writeback framebuffer we only need a new > > "WRITEBACK" property (which takes an fb id) and the small extension to > > create v4l-backed framebuffers. > > > > Cheers, Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > > Hi Daniel, > > 1. This change is to implement a continuous writeback. > 2. As you said, we need "a generic way to connect v4l and drm". > Especially how to share the buffer information between v4l and drm for > writeback output. > > Below are just some details of this change: > > In current implementation, I expect the output buffer is dma buffer > which could be from GEM object (drm) or from video encoder (V4l). Once > the buffer is queued into V4l driver, it will be converted into a GEM > object and then pass it to drm as writeback output buffer. Once the > buffer is captured, it will notify V4l driver to let user dequeue > buffer. > > Drm will notice there is a Virtual Connector (maybe a new type WRITEBACK > can be added), but it will only be "connected" until V4l > starts streaming. Yes we definitely should add a new connector type WRITEBACK. And just the connector kinda works for your hw design where writeback works like a separate encoder. But there's also hw out there where any crtc can be written back, and for those cases we need explicit properties. Then there's also the one-shot vs. continuous issues. Given all that I still think you want an explicit drm framebuffer to connect the kms and the v4l side of things. That would also help a bit with making it clear which v4l connects to which drm device. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver
On 2015-04-08 09:17, Jianwei.Wang at freescale.com wrote: > Hi Stefan, > >> -Original Message- >> From: Stefan Agner [mailto:stefan at agner.ch] >> Sent: Tuesday, April 07, 2015 8:12 PM >> To: Wang Jianwei-B52261 >> Cc: Wood Scott-B07421; airlied at linux.ie; dri-devel at >> lists.freedesktop.org; >> devicetree at vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux- >> kernel at vger.kernel.org; Jin Zhengxiong-R64188; linux-arm- >> kernel at lists.infradead.org >> Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver >> >> Hi Jianwei, >> >> On 2015-04-07 08:44, Jianwei.Wang at freescale.com wrote: >> > Hi Stefan, >> > >> > Thank you for your review and testing on Vybrid F610 device. This driver >> > just implement the basic functions and it only support the exported >> > framebuffer access. Some DRM interfaces are not implemented now. So your >> > test result is normal. I will implement these interfaces with patches >> soon >> > afterwards. I don't plan to add new features for the initial version >> driver, >> > otherwise it will be a long term for this version. >> > >> > I tested on ls1021a using TFT panel, there are no flickers on the screen >> > when inserting a USB HID device. I will do more test if time permits. >> > >> > By the way, could please give me some guidance on how X-Server use DRM >> > Interface directly? Do you have some papers or webpage about this? >> >> I'm using the modesetting X.org driver. Lots of distributions ship that >> driver as a package (e.g. xserver-xorg-video-modesetting in Debian, or >> xf86-video-modesetting in OpenEmbedded). Since 1.17 this driver has even >> been included into the main source tree of Xorg X-Server >> (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesett >> ing) >> >> This driver is using KMS/DRM interface and should work well for >> un-accelerated graphic devices. This is a a much nicer way to use X.org >> on top of a DRM driver, since it avoids going through the legacy fbdev >> interface. The man page shows how to use it: >> http://linux.die.net/man/4/modesetting >> >> So, when the driver is installed, it is just choosing that driver in >> xorg.conf: >> >> Section "Device" >> Identifier "dcu" >> Driver "modesetting" >> EndSection >> > > Thank you for your guidance. > >> Some more comments below... >> >> > >> > My reply below... >> > >> >> >> >> Hi Jianwei, >> >> >> >> The driver worked on a Vybrid VF610 device using the exported >> >> framebuffer. However, when using X-Server through the DRM interface >> >> directly (by using the modesetting driver) I get just a black screen so >> >> far, still investigating the reason. What user-space interfaces did you >> >> test? >> >> >> >> When using the FB device and insert a USB HID device, I get some >> >> flickers on the screen. I didn't had those on the dcufb driver, did you >> >> notice something like this too? Probably related to the resolution, I'm >> >> using VGA resolution. >> >> >> >> Some comments below. >> >> >> >> >> >> On 2015-03-26 06:37, Jianwei Wang wrote: >> >> > This patch add support for Two Dimensional Animation and Compositing >> >> > Engine (2D-ACE) on the Freescale SoCs. >> >> > >> >> > 2D-ACE is a Freescale display controller. 2D-ACE describes >> >> > the functionality of the module extremely well its name is a value >> >> > that cannot be used as a token in programming languages. >> >> > Instead the valid token "DCU" is used to tag the register names and >> >> > function names. >> >> > >> >> > The Display Controller Unit (DCU) module is a system master that >> >> > fetches graphics stored in internal or external memory and displays >> >> > them on a TFT LCD panel. A wide range of panel sizes is supported >> >> > and the timing of the interface signals is highly configurable. >> >> > Graphics are read directly from memory and then blended in real-time, >> >> > which allows for dynamic content creation with minimal CPU >> >> > intervention. >> >> > >> >> > The features: >> >> > (1) Full RGB888 output to TFT LCD panel. >> >> > (2) For the current LCD panel, WQVGA "480x272" is supported. >> >> > (3) Blending of each pixel using up to 4 source layers >> >> > dependent on size of panel. >> >> >> >> modetest only shows one layer currently... >> > >> > Yes, only one plane and one framebuffer were created now, others >> > maybe create as user requirement or create all when initializing, >> > I'm not sure now. This describe the hardware feature >> > >> >> >> >> > (4) Each graphic layer can be placed with one pixel resolution >> >> > in either axis. >> >> > (5) Each graphic layer support RGB565 and RGB888 direct colors >> >> > without alpha channel >> >> > and BGRA direct colors with an alpha channel. >> >> >> >> The array fsl_dcu_drm_plane_formats below shows more formats, does this >> >> commit log needs updating? >> >> >> > >> > I agree with your suggestion, I will update this commit log >> > >> >> > (6) Each gra
[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock
https://bugs.freedesktop.org/show_bug.cgi?id=89734 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Christian König --- In this case we can probably close this bug report, cause the original issue is fixed. If you find another issue which could be cause by the driver stack feel free to open up a new bug. Thanks for the help, Christian. -- 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/20150408/da40878d/attachment.html>
[Bug 94471] Displayport monitor randomly disconnects
https://bugzilla.kernel.org/show_bug.cgi?id=94471 --- Comment #4 from Leho Kraav --- Forgot to say, on topic of the bug title, I'm also experiencing occasional random monitor disconnections in the middle of work. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94471] Displayport monitor randomly disconnects
https://bugzilla.kernel.org/show_bug.cgi?id=94471 Leho Kraav changed: What|Removed |Added CC||leho at kraav.com --- Comment #3 from Leho Kraav --- Kernel 3.19.3 I can confirm that similar things with that kernel error message is happening here as well. apr 08 12:25:10 papaya kernel: [drm:drm_dp_get_mst_branch_device.isra.17 [drm_kms_helper]] *ERROR* failed to lookup MSTB with lct 2, rad 00 I have an LG 27" 2560 http://www.lg.com/us/monitors/lg-27EA83-D-led-monitor connected to DELL PR02X dock via DisplayPort. * After docking the laptop, if the monitor was powered on and sitting in standby, all xrandr activation attempts fail with "*ERROR* failed to lookup MSTB with lct 2, rad 00" * After docking the laptop, I always have to power cycle the monitor in order for xrandr --output DP1-1-8 --auto to succeed. See above. MST implementation has been very flaky from the time it was implemented, but I do understand it's more like prototype stage thing still and not enough resource is available to make it more bulletproof. I've been able to crash the whole display system with just xrandr-based display connection management consistently, as in the screen goes completely blank with no way to bring it back. Sucks a lot for being able to trust Linux with the basics, as a business mobile desktop platform. Some more adventures for those interested https://bugs.freedesktop.org/show_bug.cgi?id=85913 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state
2015-04-07 23:25 GMT+02:00 Russell King - ARM Linux : > On Tue, Apr 07, 2015 at 06:59:59PM +0200, Christian Gmeiner wrote: >> Hi Lucas. >> >> 2015-04-07 17:29 GMT+02:00 Lucas Stach : >> > And I don't get why each core needs to have a single device node. IMHO >> > this is purely an implementation decision weather to have one device >> > node for all cores or one device node per core. >> >> It is an important decision. And I think that one device node per core >> reflects the hardware design to 100%. > > Since when do the interfaces to userspace need to reflect the hardware > design? > > Isn't the point of having a userspace interface, in part, to abstract > the hardware design details and provide userspace with something that > is relatively easy to use without needlessly exposing the variation > of the underlying hardware? > > Please get away from the idea that userspace interfaces should reflect > the hardware design. > I think that we are in a phase of heavy discussion and we should talk about every aspect to design the driver - keep in mind that we could skip staging and then the interface needs to future proof. >> What makes harder to get it right? The needed changes to the kernel >> driver are not that hard. The user space is an other story but thats >> because of the render-only thing, where we need to pass (prime) >> buffers around and do fence syncs etc. In the end I do not see a >> showstopper in the user space. > > The fence syncs are an issue when you have multiple cores - that's > something I started to sort out in my patch series, but when you > appeared to refuse to accept some of the patches, I stopped... > I hope we can close this chapter soon. I am quite sorry about that but if you only would answered a single mail or a single irc message at that time we could have sorted this out. > The problem when you have multiple cores is one global fence event > counter which gets compared to the fence values in each buffer > object no longer works. > > Consider this scenario: > > You have two threads, thread A making use of a 2D core, and thread B > using the 3D core. > > Thread B submits a big long render operation, and the buffers get > assigned fence number 1. > > Thread A submits a short render operation, and the buffers get assigned > fence number 2. > > The 2D core finishes, and sends its interrupt. Etnaviv updates the > completed fence position to 2. > > At this point, we believe that fence numbers 1 and 2 are now complete, > despite the 3D core continuing to execute and operate on the buffers > with fence number 1. > Yes, this _is_ a problem. > I'm certain that the fence implementation we currently have can't be > made to work with multiple cores with a few tweeks - we need something > better to cater for what is essentially out-of-order completion amongst > the cores. > > A simple resolution to that _would_ be your argument of exposing each > GPU as a separate DRM node, because then we get completely separate > accounting of each - but it needlessly adds an expense in userspace. > Userspace would have to make multiple calls - to each GPU DRM node - > to check whether the buffer is busy on any of the GPUs as it may not > know which GPU could be using the buffer, especially if it got it via > a dmabuf fd sent over the DRI3 protocol. To me, that sounds like a > burden on userspace. > greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Stefan, > -Original Message- > From: Stefan Agner [mailto:stefan at agner.ch] > Sent: Tuesday, April 07, 2015 8:12 PM > To: Wang Jianwei-B52261 > Cc: Wood Scott-B07421; airlied at linux.ie; dri-devel at > lists.freedesktop.org; > devicetree at vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux- > kernel at vger.kernel.org; Jin Zhengxiong-R64188; linux-arm- > kernel at lists.infradead.org > Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver > > Hi Jianwei, > > On 2015-04-07 08:44, Jianwei.Wang at freescale.com wrote: > > Hi Stefan, > > > > Thank you for your review and testing on Vybrid F610 device. This driver > > just implement the basic functions and it only support the exported > > framebuffer access. Some DRM interfaces are not implemented now. So your > > test result is normal. I will implement these interfaces with patches > soon > > afterwards. I don't plan to add new features for the initial version > driver, > > otherwise it will be a long term for this version. > > > > I tested on ls1021a using TFT panel, there are no flickers on the screen > > when inserting a USB HID device. I will do more test if time permits. > > > > By the way, could please give me some guidance on how X-Server use DRM > > Interface directly? Do you have some papers or webpage about this? > > I'm using the modesetting X.org driver. Lots of distributions ship that > driver as a package (e.g. xserver-xorg-video-modesetting in Debian, or > xf86-video-modesetting in OpenEmbedded). Since 1.17 this driver has even > been included into the main source tree of Xorg X-Server > (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesett > ing) > > This driver is using KMS/DRM interface and should work well for > un-accelerated graphic devices. This is a a much nicer way to use X.org > on top of a DRM driver, since it avoids going through the legacy fbdev > interface. The man page shows how to use it: > http://linux.die.net/man/4/modesetting > > So, when the driver is installed, it is just choosing that driver in > xorg.conf: > > Section "Device" > Identifier "dcu" > Driver "modesetting" > EndSection > Thank you for your guidance. > Some more comments below... > > > > > My reply below... > > > >> > >> Hi Jianwei, > >> > >> The driver worked on a Vybrid VF610 device using the exported > >> framebuffer. However, when using X-Server through the DRM interface > >> directly (by using the modesetting driver) I get just a black screen so > >> far, still investigating the reason. What user-space interfaces did you > >> test? > >> > >> When using the FB device and insert a USB HID device, I get some > >> flickers on the screen. I didn't had those on the dcufb driver, did you > >> notice something like this too? Probably related to the resolution, I'm > >> using VGA resolution. > >> > >> Some comments below. > >> > >> > >> On 2015-03-26 06:37, Jianwei Wang wrote: > >> > This patch add support for Two Dimensional Animation and Compositing > >> > Engine (2D-ACE) on the Freescale SoCs. > >> > > >> > 2D-ACE is a Freescale display controller. 2D-ACE describes > >> > the functionality of the module extremely well its name is a value > >> > that cannot be used as a token in programming languages. > >> > Instead the valid token "DCU" is used to tag the register names and > >> > function names. > >> > > >> > The Display Controller Unit (DCU) module is a system master that > >> > fetches graphics stored in internal or external memory and displays > >> > them on a TFT LCD panel. A wide range of panel sizes is supported > >> > and the timing of the interface signals is highly configurable. > >> > Graphics are read directly from memory and then blended in real-time, > >> > which allows for dynamic content creation with minimal CPU > >> > intervention. > >> > > >> > The features: > >> > (1) Full RGB888 output to TFT LCD panel. > >> > (2) For the current LCD panel, WQVGA "480x272" is supported. > >> > (3) Blending of each pixel using up to 4 source layers > >> > dependent on size of panel. > >> > >> modetest only shows one layer currently... > > > > Yes, only one plane and one framebuffer were created now, others > > maybe create as user requirement or create all when initializing, > > I'm not sure now. This describe the hardware feature > > > >> > >> > (4) Each graphic layer can be placed with one pixel resolution > >> > in either axis. > >> > (5) Each graphic layer support RGB565 and RGB888 direct colors > >> > without alpha channel > >> > and BGRA direct colors with an alpha channel. > >> > >> The array fsl_dcu_drm_plane_formats below shows more formats, does this > >> commit log needs updating? > >> > > > > I agree with your suggestion, I will update this commit log > > > >> > (6) Each graphic layer support alpha blending with 8-bit > >> > resolution. > >> > > >> > This is a simplified version, only one primary plane, one > >> > framebuffer created for fbdev, one
