From: Dave Airlie
The atombios tables have an unfortunate restriction on only
being able to write 12 bytes, MST really wants 16-bytes here,
and since the hw can do it, we should just write directly to it.
This uses a module option to allow for it now, and maybe
we should provide the old code as
601
d1b1be3159255a47c2fa21e2ad0735798cbc78b7 Msrc
--
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/20150220/81b4e67f/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/193b2d6a/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/96179de7/attachment-0001.html>
ent15_patch to each of their file names so they are easily
distinguishable. Should I be compiling another kernel with the patches from
comment 19 and 20?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
ving 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/20150220/04c56967/attachment.html>
s 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/20150220/144683a2/attachment.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/20150220/6113a5ee/attachment.html>
eceiving 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/20150220/b390b60e/attachment.html>
||g/show_bug.cgi?id=89228
--
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/20150220/7c06a
||g/show_bug.cgi?id=88561
--
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/20150220/3ffc5
||g/show_bug.cgi?id=88978
--
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/20150220/edf63
||g/show_bug.cgi?id=88561
--
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/20150220/68a97
rrors incase you can help me http://pastebin.com/B2rFD9R0
--
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/20150220/5d9a6822/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #18 from Maciej Gluszek ---
UPDATE: Seems i found a solution. So far almost 48h uptime on my laptop and no
crash. What i did, is i added "radeon.hard_reset=1" to GRUB command line.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=1
lash radeon.dpm=1 radeon.hard_reset=1"
--
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/20150220/9b736015/attachment-0001.html>
of_iomap() doesn't return error pointers, it returns NULL on error.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..9700461 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/
The two CRTC helper operations are called only for non-atomic mode
setting, by either the drm_crtc_helper_set_config() helper or the
drm_helper_resume_force_mode() helper. As the driver has switched to
atomic mode setting and neither of those helpers is used, the operations
are not used anymore. Re
https://bugzilla.kernel.org/show_bug.cgi?id=90851
Christoph Haag changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Dan,
2015-02-20 Dan Carpenter :
> of_iomap() doesn't return error pointers, it returns NULL on error.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 63f02e2..9700461 100644
> --- a/drivers/
no post: no)
[2.255714] fb: switching to radeondrmfb from EFI VGA
[2.440405] [drm] VGA-1
[2.527423] vga_switcheroo: enabled
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/e9487dc4/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/7e58952c/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/5c56f2ea/attachment.html>
On Fri, Feb 20, 2015 at 9:42 AM, Beeresh Gopal
wrote:
> Using fb modifier flag, support NV12MT format
> in MDP4
>
> Change-Id: I3de92b0c3b6d0cb56647aed6e4e35e56eff7adab
> Signed-off-by: Beeresh Gopal
> Signed-off-by: Stephane Viau
on small comment below, and one open question at the end, but o
org/archives/dri-devel/attachments/20150220/c4c6c20f/attachment.html>
Hello Alex,
I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
It worked OK last night and I've reseted Mesa git back to 5c1aac1 but NO
success.
Only thing is I've used LLVM git of today, too and for GOOD result LLVM
from 18th.
Any hints?
For the record:
'geom-outlining-150'
'gsray
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/bfafd8c1/attachment.html>
Hi Linus,
Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
fancy, minor cleanups.
The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723:
Merge tag 'trace-sh-3.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
(2015-01-22 06:26:07 +1
On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel
wrote:
> Hello Alex,
>
> I get _today_ flickering with Mesa-demo 'geom-outlining-150'.
> It worked OK last night and I've reseted Mesa git back to 5c1aac1 but NO
> success.
> Only thing is I've used LLVM git of today, too and for GOOD result LLVM
The atom aux param interface only supports 4 bits for
the total write transfer size (header + payload). This
limits us to 12 bytes of payload rather than 16. Add a
check for this. Reads are not affected.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 7 +++
1 file c
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150220/8145638c/attachment.html>
...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/ad8fe694/attachment.sig>
>> + if (tmp & DP_AUX_SW_RX_TIMEOUT) {
>> + DRM_DEBUG_KMS("dp_aux_ch timed out\n");
>> + ret = -ETIMEDOUT;
>> + goto done;
>> + }
>> + if (tmp & DP_AUX_RX_ERROR_FLAGS) {
>> + DRM_DEBUG_KMS("dp_aux_ch flags not zero: %08x\n", tmp);
>> + ret = -EIO;
>> + goto done;
>> + }
>> +
>> + bytes = DP_AUX_SW_REPLY_GET_BYTE_COUNT(tmp);
>> + if (bytes) {
>> + WREG32(DPREG(DP_AUX_SW_DATA),
>> + DP_AUX_SW_DATA_RW | DP_AUX_SW_AUTOINCREMENT_DISABLE);
>> +
>> + tmp = RREG32(DPREG(DP_AUX_SW_DATA));
>> + ack = (tmp >> 8) & 0xff;
>> +
>> + for (i = 0; i < bytes - 1; i++) {
>> + tmp = RREG32(DPREG(DP_AUX_SW_DATA));
>> + if (buf)
>> + buf[i] = (tmp >> 8) & 0xff;
>> + }
>> + if (buf)
>> + ret = bytes - 1;
>> + }
>> +
>> + WREG32(DPREG(DP_AUX_SW_INTERRUPT_CONTROL), DP_AUX_SW_DONE_ACK);
>> +
>> + if (is_write)
>> + ret = msg->size;
>> +done:
>> + mutex_unlock(&chan->mutex);
>> +
>> + if (ret >= 0)
>> + msg->reply = ack >> 4;
>> + return ret;
>> +}
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 5d684be..0141ce3 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -190,6 +190,7 @@ int radeon_deep_color = 0;
>> int radeon_use_pflipirq = 2;
>> int radeon_bapm = -1;
>> int radeon_backlight = -1;
>> +int radeon_auxch = 0;
>>
>> MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
>> module_param_named(no_wb, radeon_no_wb, int, 0444);
>> @@ -275,6 +276,9 @@ module_param_named(bapm, radeon_bapm, int, 0444);
>> MODULE_PARM_DESC(backlight, "backlight support (1 = enable, 0 = disable, -1
>> = auto)");
>> module_param_named(backlight, radeon_backlight, int, 0444);
>>
>> +MODULE_PARM_DESC(auxch, "Use native auxch experimental support (1 = enable,
>> 0 = disable)");
>> +module_param_named(auxch, radeon_auxch, int, 0444);
>> +
>> static struct pci_device_id pciidlist[] = {
>> radeon_PCI_IDS
>> };
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-program-auxch-directly-v2.patch
Type: text/x-diff
Size: 13804 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/9b39e4f8/attachment-0001.patch>
Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms
changes") has a typo in both mdp5_encoder_helper_funcs and
mdp5_crtc_helper_funcs definitions:
.dpms entry should be replaced by .disable and .enable
Also fixed a typo in mdp5_encoder_enable().
Note that these typos are only prese
On Fri, Feb 20, 2015 at 11:13:06AM -0800, Mike Turquette wrote:
> Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
> > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> > > I agree that it's a bit odd, but I think it has to be like this.
> > > Consider that you request a rate of
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/c9c8791c/attachment.html>
nts/20150220/89e65eed/attachment.html>
The argument contains a pointer to the old state, rename it to old_state
like in all other commit helper functions.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_he
The 4th CRTC could not be accessed because of a missing case entry.
Also, only flush registers when a CRTC is enabled (and thus a CTL is allocated).
This shall fix the cursor move issue that Rob mentioned.
Stephane Viau (2):
drm/msm: update generated headers (add 6th lm.base entry)
drm/msm/md
Some target have up to 6 layer mixers (LM).
Let the header file access the last LM's base address.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL);
in that case we should not try to FLUSH registers and do nothing instead.
This can happen when we try to move a cursor but the CRTC's CTL
(CONTROL) has not been allocated yet (inactive CRTC).
It can also happens when we .atomi
Some target have up to 6 layer mixers (LM). Let the xml file
access the last LM's base address.
Signed-off-by: Stephane Viau
---
rnndb/mdp/mdp5.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index cd3bf37..eaaec47 100644
--- a/rnnd
On Fri, Feb 20, 2015 at 12:35 PM, Jan Vesely wrote:
> Hello radeon devs,
>
> I have been trying to find out more about VM implementation on SI+ hw,
> but unfortunately I could not find much in the public documents[0].
>
> SI ISA manual suggests that there is a limited form of privileged mode
> on
registers, but not display registers) or only executing
> certain packets.
>
> I hope this helps. Let me know if you have any more questions.
>
> Alex
>
> >
> >
> > thank you,
> > Jan
> >
> > [0]http://developer.amd.com/resources/documentation-articles/deve
To avoid ambiguity rename FRAME_SIZE to
SSTILE_FRAME_SIZE
Change-Id: I2c1c763cec31acb6c860220c41a8b33bfad430a3
Signed-off-by: Beeresh Gopal
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/
Using fb modifier flag, support NV12MT format
in MDP4
Change-Id: I3de92b0c3b6d0cb56647aed6e4e35e56eff7adab
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 9 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 +
Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
> On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> > I agree that it's a bit odd, but I think it has to be like this.
> > Consider that you request a rate of 100Hz, but the clock can only
> > produce 99.5Hz, so due to rounding cl
Quoting Russell King - ARM Linux (2015-02-20 11:20:43)
> On Fri, Feb 20, 2015 at 11:13:06AM -0800, Mike Turquette wrote:
> > Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
> > > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> > > > I agree that it's a bit odd, but I think it
49 matches
Mail list logo
