https://bugs.freedesktop.org/show_bug.cgi?id=34495
--- Comment #65 from Lars G ---
Tried the new branch now.
Selecting/moving is nice and fast in blender,
but somehow i get no textures displayed on the objects.
This is with radeon hd 6320 (e-450 apu) built against llvm-git, using
blender-git.
-
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson
>>> wrote:
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson
wrote:
> On Tu
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>> >
>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is t
FYI: the error snapshout below was generated on a vanilla linux 3.10.6
kernel build.
I have not bisected the kernel to find the appropiate
delta (not git capable on principal machine)
Original Message
Subject: Re: kernel reporting of radeon/workqueue on 3.10.6 build
Date: Tue,
Hello,
I'm testing linux-3.11-rc5 with my radeon graphics card HD 6470M.
Finally hibernate and suspend mode started working without hangs.
But now I see this error message in dmesg before notebook it
hibernated or suspended:
[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
Is this ERR
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
> wrote:
>> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
>>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nig
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
>> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
>> > wrote:
>> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek w
This function is unused.
Signed-off-by: Stéphane Marchesin
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_modes.c | 37 -
include/drm/drm_crtc.h | 3 ---
2 files changed, 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/d
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please att
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson
>> wrote:
>>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson
wro
When building kernels for a preliminary hardware target, having to add a
kernel command-line option can prove inconvenient. Add a Kconfig option
that changes the default of this option to 1.
Signed-off-by: Josh Triplett
---
I dropped the indication of the default in the module parameter
documen
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
>
> I won't repeat all the background information from the versions one and two
> here, you can read it at http://lwn.net/Articles/512363/ and
> http://lwn.net/Articles
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart
wrote:
> MIPI DBI is a configurable-width parallel display bus that transmits
> commands and data.
>
> Add a new DBI Linux bus type that implements the usual bus
> infrastructure (including devices and drivers (un)registration and
> matching, and bu
The conditional is usually a recoverable driver bug, and so WARNing, and
preventing the drm_mm code from doing potential damage (BUG) is
desirable.
This issue was hit and fixed twice while developing the i915 multiple
address space code. The first fix is the patch just before this, and is
hit on a
https://bugzilla.kernel.org/show_bug.cgi?id=60741
--- Comment #5 from Eastern Heart ---
(In reply to Alex Deucher from comment #4)
> Might be a duplicate of bug 60674. Can you try the patch on that bug? If
> that doesn't help, can you bisect?
I cannot try now... And I cannot even boot, not inc
https://bugzilla.kernel.org/show_bug.cgi?id=60741
--- Comment #6 from Alex Deucher ---
(In reply to Eastern Heart from comment #5)
> I cannot try now... And I cannot even boot, not incorrect display!
> I said, my boot paused when start the kernel radeon module.
> Sorry.
The patch is still be rel
https://bugzilla.kernel.org/show_bug.cgi?id=60741
--- Comment #7 from Eastern Heart ---
(In reply to Alex Deucher from comment #6)
> (In reply to Eastern Heart from comment #5)
> > I cannot try now... And I cannot even boot, not incorrect display!
> > I said, my boot paused when start the kernel
https://bugzilla.kernel.org/show_bug.cgi?id=60741
--- Comment #8 from Alex Deucher ---
(In reply to Eastern Heart from comment #7)
>
> Although I haven't apply this patch, can I ask: will this patch be merged to
> linux-3.10.7?
It should make it's way to 3.10 eventually. I'm not sure which 3.1
https://bugs.freedesktop.org/show_bug.cgi?id=67876
--- Comment #4 from jim.cro...@gmail.com ---
So Ive apparently got bad rlc firmware from last Dec:
[jimc@groucho ~]$ sum radeon-fw/* /lib/firmware/radeon/CEDAR_* | sort
05888 3 /lib/firmware/radeon/CEDAR_rlc.bin
23436 3 radeon-fw/CEDAR_rl
As I mentioned already on internal messenger, you first may need discuss
with Rahul Sharma who is preparing hdmiphy patch set.
The patch set will move all hdmiphy related codes from hdmi to hdmiphy
driver. So we may need a separated hdmiphy node, not in hdmi node. And it'd
better to move the hdmip
On Tue, Aug 13, 2013 at 05:01:38PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 35 ++---
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nou
https://bugs.freedesktop.org/show_bug.cgi?id=68085
--- Comment #2 from Michel Dänzer ---
Looks like swrast_dri.so is picking up driDriverAPI from radeonsi_dri.so.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
On Tue, Aug 13, 2013 at 06:09:08PM -0700, Ben Widawsky wrote:
> The conditional is usually a recoverable driver bug, and so WARNing, and
> preventing the drm_mm code from doing potential damage (BUG) is
> desirable.
>
> This issue was hit and fixed twice while developing the i915 multiple
> addres
https://bugs.freedesktop.org/show_bug.cgi?id=67790
Pali Rohár changed:
What|Removed |Added
Summary|error message on suspend: |error message on suspend
More typo fallout:
On Wednesday 14 August 2013 00:17:27 Damien Lespiau wrote:
> This can then be used by DRM drivers to setup their vendor infoframes.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 36
> include/drm/drm_edid.h |
On Wednesday 14 August 2013 00:17:16 Damien Lespiau wrote:
> Following up the first instance of this series:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
>
> Here is a v2 with Ville's review pass and a few additions:
> - Alternate clock modes for 4k resolutions
>
On Wed, Aug 14, 2013 at 12:17:18AM +0100, Damien Lespiau wrote:
> A few styles issues have crept in here, fix them before touching this
> code again.
>
> v2: constify arguments that can be (Ville Syrjälä)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 15 ---
Minor typo - feel free to ignore:
On Wednesday 14 August 2013 00:17:19 Damien Lespiau wrote:
> HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
>
> With this commit, we now parse this block and expose the 4k modes that
> we find there.
>
> v2: Fix the "4096x2160" string (nic
On Wed, Aug 14, 2013 at 12:17:20AM +0100, Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gp
On Wed, Aug 14, 2013 at 12:17:22AM +0100, Damien Lespiau wrote:
> Just like:
>
> Author: Damien Lespiau
> Date: Mon Aug 12 11:53:24 2013 +0100
>
> video/hdmi: Don't let the user of this API create invalid infoframes
>
> But this time for the horizontal/vertical bar data present bits
A few minor things:
On Wednesday 14 August 2013 00:17:20 Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
> Provide the programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of vendor
On Wed, Aug 14, 2013 at 12:17:26AM +0100, Damien Lespiau wrote:
> With this last bit, hdmi_infoframe_pack() is now able to pack any
> infoframe we support.
>
> At the same time, because it's impractical to make two commits out of
> this, we get rid of the version that encourages the open coding of
On Wed, Aug 14, 2013 at 12:17:24AM +0100, Damien Lespiau wrote:
> I just wrote the bits to define and pack HDMI vendor specific infoframe.
> Port the host1x driver to use those so I can refactor the infoframe code
> a bit more.
>
> Cc: Thierry Reding
> Cc: Terje Bergström
> Cc: linux-te...@vger.
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
> Provide the programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of vendor
On Wed, Aug 14, 2013 at 12:17:16AM +0100, Damien Lespiau wrote:
> Following up the first instance of this series:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
>
> Here is a v2 with Ville's review pass and a few additions:
> - Alternate clock modes for 4k resolution
https://bugs.freedesktop.org/show_bug.cgi?id=67530
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Aug 14, 2013 at 8:16 AM, Russell King - ARM Linux
wrote:
> On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote:
>> From: Russell King
>>
>> TDA19988 devices need their RAM enabled in order to read EDID
>> information. Add support for this.
>>
>> Signed-off-by: Russell K
Hi Shirish,
On Tuesday 13 of August 2013 12:39:27 Shirish S wrote:
> For various revision of chipset if the signal pattern is changed for
> every board, then the phy setting need to be updated correspondingly by
> measuring the signal.
> With the hdmiphy settings fixed in the driver the only way c
https://bugs.freedesktop.org/show_bug.cgi?id=67876
--- Comment #5 from Alex Deucher ---
The rlc ucode was updated for UVD support. You need the newer rlc ucode if you
want to use UVD. But either version should work if you don't need UVD.
--
You are receiving this mail because:
You are the ass
Hi
This series removes any access to gem_obj->driver_private from all drivers and
then drops drm_gem_object_alloc() with its ->gem_init_object() driver callback.
All this is only needed if a gem object is not embedded into the driver's bo.
However, all drivers (except for nouveau, see patch #6) e
gem_bo->driver_private is never read by ast nor DRM core. No need to set
it. Besides, drm core clears it during setup, anyway.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drive
gem_bo->driver_private is never read by mgag200 nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/m
gem_bo->driver_private is never read by cirrus nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirru
These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 3 ---
This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.
Cc: Dave Airlie
Cc: Alex Deucher
Signed-off-by: David Herrmann
---
drivers/gpu/drm/radeon/radeon_object.c | 1 -
drivers/gpu/drm/radeon/radeon_prime.c | 1 -
2 files changed, 2 deletio
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.
The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie
Cc: Ale
On Wed, Aug 14, 2013 at 9:07 AM, David Herrmann wrote:
> This field is never read. No need to set it in radeon. Besides, DRM gem
> core clears it during setup, anyway.
>
> Cc: Dave Airlie
> Cc: Alex Deucher
> Signed-off-by: David Herrmann
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/ra
On Wed, Aug 14, 2013 at 03:07:13PM +0200, David Herrmann wrote:
> Hi
>
> This series removes any access to gem_obj->driver_private from all drivers and
> then drops drm_gem_object_alloc() with its ->gem_init_object() driver
> callback.
>
> All this is only needed if a gem object is not embedded
Op 14-08-13 15:07, David Herrmann schreef:
> There is no reason to keep the gem object separately allocated. nouveau is
> the last user of gem_obj->driver_private, so if we embed it, we can get
> rid of 8bytes per gem-object.
>
> The implementation follows the radeon driver. bo->gem is only valid,
> >> > Turning to DRM/KMS, it seems the supported formats of a plane
> >> > can be queried using drm_mode_get_plane. However, there doesn't
> >> > seem to be a way to query the supported formats of a crtc? If
> >> > display HW only supports scanning out from a single buffer
> >> > (like pl111 d
> >> > > > So in the above, after X receives the second DRI2SwapBuffers,
> >> > > > it doesn't need to get scheduled again for the next frame to
> >> > > > be both rendered by the GPU and issued to the display for
> >> > > > scanout.
> >> > >
> >> > > well, this is really only an issue if you ar
On Wed, Aug 14, 2013 at 4:14 AM, Ville Syrjälä
wrote:
> On Tue, Aug 13, 2013 at 05:01:38PM -0400, Alex Deucher wrote:
>> This adds a helper function to extract the speaker allocation
>> data block from the EDID. This data block describes what speakers
>> are present on the display device.
>>
>> S
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 53 ++---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/rad
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on
On Wed, Aug 14, 2013 at 12:08:13PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrjälä's comments
>
> Signed-off-by: Al
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
v2: update per Ville Syrjälä's comments
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 52 +++
On Wed, Aug 14, 2013 at 12:17 PM, Ville Syrjälä
wrote:
> On Wed, Aug 14, 2013 at 12:08:13PM -0400, Alex Deucher wrote:
>> This adds a helper function to extract the speaker allocation
>> data block from the EDID. This data block describes what speakers
>> are present on the display device.
>>
>>
2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> + u32 r;
> +
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> + r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset)
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation
Signed-off-by: Alex Deucher
---
Fixed the mall
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on
On Wed, Aug 14, 2013 at 12:30:21PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrjälä's comments
> v3: fix copy/paste t
https://bugs.freedesktop.org/show_bug.cgi?id=56659
--- Comment #7 from russianneuroman...@ya.ru ---
Still issue with Linux 3.11rc5, radeon driver 7.1.99+git20130730.6a278369, Mesa
9.2.0~git20130729 and KDE 4.11rc2.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #9 from Yves G. (theYinYeti) ---
Sorry for the long time without an answer; I was on holidays. Just to be clear:
the kernel (and associated packages for my setup) is the only component that
changes; here’s the exact list: linux, linux-
Follow up on v2:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
With the quick and nice reviews from Ville and Simon, it's time for a v3:
- Fix embarrassing hmdi typo
- Fix the sending of vendor specific infoframes for side-by-side half modes
- Smaller changes here
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file changed, 7 insertions(+), 5 deleti
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
re
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deleti
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau
Date: Tue Aug 6 20:3
Just like:
Author: Damien Lespiau
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/video
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.
v2: Pimp up the commit
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side (ha
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
detai
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau
Reviewed-by: Simon Farnsworth
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 file
(CC'ing the proper people since I'm still on parental leave).
On 08/13/2013 11:44 PM, David Herrmann wrote:
Please see inline comments.
Hi
On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote:
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
I h
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #40 from Aaron Watry ---
Can you apply the following LLVM 2 code series, build the latest upstream
libclc version, and try again?
LLVM Patch series:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184088.html
htt
On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
> Provide the same programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of ve
On Wed, Aug 14, 2013 at 06:19:03PM +0100, Damien Lespiau wrote:
> Follow up on v2:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
>
> With the quick and nice reviews from Ville and Simon, it's time for a v3:
> - Fix embarrassing hmdi typo
> - Fix the sending of ven
This patchset adds the drm_bridge abstraction as well as the PTN3460
DisplayPort to LVDS bridge driver (using drm_bridge, of course).
Changed in v2:
- Added PTN3460 driver to show drm_bridge usage
- Removed connector detect() re-route in favor of implementing the connector
in the bridge drive
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disa
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
d
On Thu, Aug 08, 2013 at 09:10:38AM +0200, Daniel Vetter wrote:
> Makes it more obviously correct what tricks we play by reusing the drm
> prime release helper.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Daniel Vetter
Ok, to get things going I've merged the two i915 patches to dinq.
-Daniel
Hi all,
So I've finally tracked down the last thing which I didn't really understand in
my earlier patches and made sure it won't ever break again by writing testcases.
The one thing still left to do (but I have tests for it already) is to make sure
we don't duplicate buffers when importing forei
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae
Cc: Intel Graphics Development
Signe
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Sim
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 77c7d19..b1d9e25
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.
So scream into dmesg with a big WARN in case that ever happens.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a z
handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for
1 - 100 of 279 matches
Mail list logo
