the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/da308a94/attachment.html>
On 2014? 05? 13? 13:44, Shirish S wrote:
> Hi,
>
> On Wed, Feb 19, 2014 at 4:02 PM, Inki Dae wrote:
>> 2014-02-14 16:34 GMT+09:00 Shirish S :
>>> In DVI mode the video preamble and Guard band should
>>> be disabled whereas it should be applied in HDMI mode,
>>> the re-applying of preamble and gua
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Bug ID: 76321
Summary: Incorrect hwmon temperature when radeon card is turned
off
Product: Drivers
Version: 2.5
Kernel Version: 3.15-rc3
Hardware: All
OS
On Fri, May 16, 2014 at 7:25 AM, Lee, Chon Ming
wrote:
>> > Cherryview display allow the primary plane to be position at any
>> > location similiar to sprite plane for certain port. So, this shouldn't
>> > need to
>> check here.
>> >
>> > And the width/height doesn't need to cover the whole scre
ves/dri-devel/attachments/20140516/b8fb5388/attachment.sig>
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work
What initially seemed to be a typo in fglrx (using register 0x740c
instead of 0x74dc) appeared to be a correct behavior. DCE3 has ACR and
CRC registers swapped which explains why we needed
WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);
This has been tested for possible regressions on DCE3 HD347
Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bu
Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.
This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)
For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231
Signed-off-by: Rafa?
On Thu, May 15, 2014 at 06:17:25PM -0700, Matt Roper wrote:
> Cursor planes are a bit trickier to support via the universal plane interface
> than primary planes were. Legacy cursor ioctls take handles to driver buffers
> directly whereas the universal plane API takes drm_framebuffer's that
> rep
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -0,0 +1,222 @@
> +#include
> +#include
Adding the copyright header to new files would be nice.
Apart from that the series looks good to me.
Christian.
Am 16.05.2014 11:10, schrieb Rafa? Mi?ecki:
> DCE 3.1 and 3.2 should be programmed in a diffe
DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work
On 16 May 2014 03:14, Tomasz Figa wrote:
> On 15.05.2014 06:01, Rahul Sharma wrote:
>> Thanks Tomasz,
>>
>> On 15 May 2014 01:31, Tomasz Figa wrote:
>>> Hi Rahul, Tomasz,
>> [snip]
+ simplephys: simple-phys at 1004 {
+ compatible = "samsung,exynos5250-simple-phy";
>>
On 16 May 2014 15:12, Rahul Sharma wrote:
> On 16 May 2014 03:14, Tomasz Figa wrote:
>> On 15.05.2014 06:01, Rahul Sharma wrote:
[snip]
the PHY provider.
>>>
>>> Please correct me if I got you wrong. You want somthing like this:
>>>
>>> pmu_system_controller: system-controller at 100400
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
> The DRM core will translate calls to legacy cursor ioctls into universal
> cursor calls automatically, so there's no need to maintain the legacy
> cursor support. This greatly simplifies the transition since we don't
> have to handle re
On 16.05.2014 12:35, Rahul Sharma wrote:
> On 16 May 2014 15:12, Rahul Sharma wrote:
>> On 16 May 2014 03:14, Tomasz Figa wrote:
>>> On 15.05.2014 06:01, Rahul Sharma wrote:
> [snip]
> the PHY provider.
>
Please correct me if I got you wrong. You want somthing like this:
>>
On 16 May 2014 16:20, Tomasz Figa wrote:
> On 16.05.2014 12:35, Rahul Sharma wrote:
>> On 16 May 2014 15:12, Rahul Sharma wrote:
>>> On 16 May 2014 03:14, Tomasz Figa wrote:
On 15.05.2014 06:01, Rahul Sharma wrote:
>> [snip]
>> the PHY provider.
>>
>
> Please correct me if I
On 16.05.2014 16:30, Rahul Sharma wrote:
> On 16 May 2014 16:20, Tomasz Figa wrote:
>> On 16.05.2014 12:35, Rahul Sharma wrote:
>>> On 16 May 2014 15:12, Rahul Sharma wrote:
On 16 May 2014 03:14, Tomasz Figa wrote:
> On 15.05.2014 06:01, Rahul Sharma wrote:
>>> [snip]
>>> the PHY pr
rong
as I can't find a revision that works.
--
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/20140516/67f37a3a/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/00a097f0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
On Fri, May 16, 2014 at 10:51:44AM +0800, Lee, Chon Ming wrote:
...
> > +int drm_primary_helper_check_update(struct drm_plane *plane,
> > + struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct
On Thu, May 15, 2014 at 06:17:26PM -0700, Matt Roper wrote:
> If drivers support universal planes and have registered a cursor plane
> with the DRM core, we should use that universal plane support when
> handling legacy cursor ioctls. Drivers that transition to universal
> planes won't have to mai
On Thu, May 15, 2014 at 06:17:27PM -0700, Matt Roper wrote:
> Universal plane support had placeholders for cursor planes, but didn't
> actually do anything with them. Save the cursor plane reference inside
> the crtc and update the cursor plane parameter from void* to drm_plane.
>
> Signed-off-by
On Thu, May 15, 2014 at 06:17:28PM -0700, Matt Roper wrote:
> Refactor cursor buffer setting such that the code to actually update the
> cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
> a GEM object as a parameter. The existing legacy cursor ioctl handler,
> intel_crtc_curs
On Thu, May 15, 2014 at 06:17:29PM -0700, Matt Roper wrote:
> The DRM core will translate calls to legacy cursor ioctls into universal
> cursor calls automatically, so there's no need to maintain the legacy
> cursor support. This greatly simplifies the transition since we don't
> have to handle re
commands are affected by the regression.
--
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/20140516/ab2406c1/attachment-0001.html>
Adds a NvReclock boolean option to allow the user to enable (or disable)
reclocking. All chipsets default to off, except NVAA/NVAC, which are
reportedly complete.
Signed-off-by: Ilia Mirkin
---
Ben, I know you've been saying that reclocking is in a pretty bad state, but I
do think that there are
Hi Dave,
drm-intel-next-2014-05-06:
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder->mode_set callback removal (Daniel)
- 64b reloc f
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/4105ba75/attachment.html>
g.cgi?id=78717
--
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/20140516/ca640b9d/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #2 from Pali Roh?r ---
Here is output from sensors with your patch (when card is turned off):
radeon-pci-0100
Adapter: PCI adapter
ERROR: Can't get value of subfeature temp1_crit: Can't read
ERROR: Can't get value of subfeature temp1_
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/23409106/attachment.html>
dri-devel/attachments/20140516/41fd8cae/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/e6b8b9f7/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/a30a37d1/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/692e4053/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #14 from Tasev Nikola ---
Hi
I try today with a Medion 1280x1024 monitor and everything work without
problem.
It seem's that only the combinaison RS880 + Belinea 2080S2 have problem
with the new PLL code.
I tried different value from
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #6 from maxis11 ---
BTW runpm works with 3.12.7 and 3.12.8 (with 3.13 and later runpm=1 freezes
laptop during boot)
--
You are receiving this mail because:
You are watching the assignee of the bug.
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/b1a3eb69/attachment-0001.html>
On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki wrote:
> What initially seemed to be a typo in fglrx (using register 0x740c
> instead of 0x74dc) appeared to be a correct behavior. DCE3 has ACR and
> CRC registers swapped which explains why we needed
> WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #7 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
ypes
3d single_level -fbo -auto | grep result; done
and always fail
--
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/20140516/b3a9ab4c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140516/c3e7dbb1/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/4640f604/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Alex Deucher changed:
What|Removed |Added
Attachment #136331|0 |1
is obsolete|
Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly. The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl ha
Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID. We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.
Signed-off-by: Matt Roper
---
driv
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
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/20140516/18584439/attachment-0001.html>
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/a93fa8bf/attachment.html>
> -Original Message-
> From: Rob Clark [mailto:robdclark at gmail.com]
> Sent: Friday, May 16, 2014 11:05 AM
> To: Lee, Chon Ming
> Cc: Roper, Matthew D; Intel Graphics Development; dri-
> devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/4] drm/plane-helper: Add
> drm_pr
On 13/05/2014 09:51, Thierry Reding wrote:
> On Fri, May 09, 2014 at 04:16:40PM +0200, Boris BREZILLON wrote:
>> Hello Thierry,
>>
>> I noticed you're describing each new panel with a new entry in the
>> of_platform_match table and a new compatible string.
>> I guess you have a good reason to do i
> > HDMI Encoder).
>
> Probably not, as your kernel is much older than the one that driver has
> been written on. The omapdss driver has changed quite a bit.
>
> Tomi
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/cdaa1caf/attachment.html>
Hi Dave,
this is the next pull quested for stashed up radeon fixes for 3.15.
Highlights are:
1. Avoid sending SIGBUS on CPU access just because kernel can't handle
buffer placement.
2. Some fixes for VM page table updates and buffer placements.
3. Fixing two typos in the PLL and SI register spec
From: Andi Kleen
Saves about 5k of text
textdata bss dec hex filename
140803602008168 1507328 1759585610c7dd0 vmlinux-before-radeon
140749782008168 1507328 1759047410c68ca vmlinux-radeon
Cc: alexander.deucher at amd.com
Cc: dri-devel at lists.f
On 04/30 10:07, Matt Roper wrote:
> Pull the parameter checking from drm_primary_helper_update() out into
> its own function; drivers that provide their own setplane()
> implementations rather than using the helper may still want to share
> this parameter checking logic.
>
> A few of the checks he
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140516/23fb1bba/attachment-0001.sig>
On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs wrote:
> On 17 May 2014 02:43, "Ilia Mirkin" wrote:
>>
>> Adds a NvReclock boolean option to allow the user to enable (or disable)
>> reclocking. All chipsets default to off, except NVAA/NVAC, which are
>> reportedly complete.
> Hey Ilia,
>
> I think I
60 matches
Mail list logo
