Hi
On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski
wrote:
> Would it make sense for the initial mode on a memfd inode to be 000?
> Anyone who finds this to be problematic could use fchmod to fix it.
memfd_create() should be subject to umask() just like anything else.
That should solve any pos
Hi
On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski wrote:
> /proc/pid/fd is a really weird corner case in which the mode of an
> inode that doesn't have a name matters. I suspect that almost no one
> will ever want to open one of these things out of /proc/self/fd, and
> those who do should be m
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
wrote:
> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
> incrementing the page reference counts when the I/O is submitted,
> allowing the pages to be modified by DMA even if they are no longer
> mapped in the address spa
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/be80a7c7/attachment.html>
ll. Somehow it seems like
runtime pm is still getting applied to the integrated card.
--
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/
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/1124346b/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/20140411/9a32ebae/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/0d0b7f41/attachment-0001.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/81c7eb60/attachment.html>
atch v4
radeon module parameters at default settings
--
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/20140411/6bb68e6d/attachment.html>
Hi Tomasz,
On 10 April 2014 21:02, Tomasz Figa wrote:
> Hi Rahul,
>
> On 02.04.2014 19:13, Rahul Sharma wrote:
>>
>> From: Rahul Sharma
>>
>> Exynos drm hdmi driver used to get dummy hdmiphy clock to
>> control the PMU bit for hdmiphy. This clock is removed
>> during CCF migration. This should a
Thanks Tomasz,
This patch is not longer required after rebasing to Tomasz Stanislawski's
Simple Phy patches.
Regards,
Rahul Sharma.
On 10 April 2014 22:30, Tomasz Figa wrote:
> Hi Rahul,
>
> On 02.04.2014 19:13, Rahul Sharma wrote:
>>
>> From: Rahul Sharma
>>
>> Hdmiphy control bit needs to be
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/20140411/a10f7ad6/attachment.html>
Thanks Tomasz,
On 10 April 2014 22:47, Tomasz Figa wrote:
> Hi Rahul,
>
> On 02.04.2014 19:13, Rahul Sharma wrote:
>>
>> From: Rahul Sharma
>>
>> Previous SoCs have hdmi phys which are accessible through
>> dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
>> Hdmi driver is modified to
e:
http://people.freedesktop.org/~agd5f/BONAIRE_mc.bin
--
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/20140411/faf7a9d9/attachment.html>
archives/dri-devel/attachments/20140411/db5a2cb3/attachment.html>
Hi,
On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, just a
On Friday 11 April 2014 12:10 PM, Tomi Valkeinen wrote:
>> Does drm_framebuffer_remove get called when we abort the application, or
>> unload omapdrm, or both?
>
> Both. When we abort an app, drm_framebuffer_remove gets called for the
> fb that the app created. When we unload omapdrm, it gets ca
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/f044381a/attachment.html>
On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, jus
These are based over Tomi's 3.15/omapdrm-fixes branch.
Archit Taneja (5):
drm/omap: gem sync: wait on correct events
drm/omap: Fix crash when using LCD3 overlay manager
drm/omap: Allow allocation of larger buffers
drm/omap: Use old_fb to synchronize between successive page flips
drm/omap
From: Subhajit Paul
In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to
be free'd in the function itself.
Make sure we free the waiter for this case.
Signed-off-by: Subhajit Paul
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_gem.c | 2 ++
1 file cha
A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.
Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.
This sho
The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.
Reported-by: Somnath Mukherjee
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 1 +
1 file changed, 1 ins
The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are
greater than what is specified in the driver through dev->mode_config.
Create helpers for DISPC which return the max manager width and height supported
by the device. The maximum width for a framebuffer is set to the com
omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.
Initialize old_fb to the fb that we intend to flip to through page_fl
The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.
Use the same spinlock in page_flip, to make sure the above omap_c
On Thu, Apr 10, 2014 at 02:18:06PM -0700, Matt Roper wrote:
> The src_w / src_h parameters to update_plane include a subpixel offset;
> we need to shift off the subpixel bits before comparing to CRTC size
> when checking for primary plane scaling.
>
> Signed-off-by: Matt Roper
Reviewed-by: Danie
On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot wrote:
> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>> wrote:
>>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
GK20A's timer is directly attached to the syste
On 04/11/2014 04:31 PM, Ben Skeggs wrote:
> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot
> wrote:
>> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>>> wrote:
On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>
On Thu, Apr 10, 2014 at 5:33 AM, Andreas Noever
wrote:
> 457e77b2 effectively replaces (... & 0xff00) << 8 with (... >> 8) << 8.
> Which does not do the same and breaks boot on my machine.
>
> Restore the old behaviour and remove the unnecessary cast.
>
> Signed-off-by: Andreas Noever
Signed-
plain that a bit please? =)
Thank you
Greetings
--
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/20140411/3474ad3f/attachment.html>
On Thu, 10 Apr 2014 21:30:03 +0200
Christian K?nig wrote:
> >>> Quick thought from someone entirely unfamiliar with the hardware:
> >>> perhaps you can get the performance benefit without the size increase
> >>> by moving the else portion into a non-inline function? I'm guessing
> >>> that most a
Am 11.04.2014 09:52, schrieb Lauri Kasanen:
> On Thu, 10 Apr 2014 21:30:03 +0200
> Christian K?nig wrote:
>
> Quick thought from someone entirely unfamiliar with the hardware:
> perhaps you can get the performance benefit without the size increase
> by moving the else portion into a no
is 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/20140411/14abc910/attachment.html>
is 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/20140411/669fe98c/attachment.html>
+shared = nshared;
> +memcpy(shared, fobj->shared, sizeof(*shared) *
> shared_count);
> +} else
> +shared_count = 0;
> +fence_excl = obj->fence_excl;
> +
> +retry = read_seqcount_retry(&obj->seq, seq);
> +if (retry)
> +goto unlock;
> +
> +if (!fence_excl || fence_get_rcu(fence_excl)) {
> +unsigned i;
> +
> +for (i = 0; i < shared_count; ++i) {
> +if (fence_get_rcu(shared[i]))
> +continue;
> +
> +/* uh oh, refcount failed, abort and retry */
> +while (i--)
> +fence_put(shared[i]);
> +
> +if (fence_excl) {
> +fence_put(fence_excl);
> +fence_excl = NULL;
> +}
> +
> +retry = 1;
> +break;
> +}
> +} else
> +retry = 1;
> +
> +unlock:
> +rcu_read_unlock();
> +}
> +*pshared_count = shared_count;
> +if (shared_count)
> +*pshared = shared;
> +else {
> +*pshared = NULL;
> +kfree(shared);
> +}
> +*pfence_excl = fence_excl;
> +
> +return ret;
> +}
> +EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
> +
Thanks,
Thomas
-- next part --
A non-text attachment was scrubbed...
Name: wake_up_sparse.diff
Type: text/x-patch
Size: 1843 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/ba8fe9af/attachment-0001.bin>
the above
mentioned error in my dmesg is still there.
--
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/20140411/b4b05d82/attachment.html>
applications and yeah. Lets see :)
--
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/20140411/1b062619/attachment.html>
op 11-04-14 10:38, Thomas Hellstrom schreef:
> Hi, Maarten.
>
> Here I believe we encounter a lot of locking inconsistencies.
>
> First, it seems you're use a number of pointers as RCU pointers without
> annotating them as such and use the correct rcu
> macros when assigning those pointers.
>
> Som
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140411/c1cb3fd5/attachment.html>
On Fri, 11 Apr 2014 10:33:08 +0200
Christian K?nig wrote:
> >> Actually direct register access shouldn't be necessary so often. Apart
> >> from page flips, write/read pointer updates and irq processing there
> >> shouldn't be so many of them. Could you clarify a bit more what issue
> >> you are s
On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>>> GK20A's timer is directly attached to the system timer and cannot be
>>> calibrated. Skip the calibration phase o
mention that if I comment out the unref in
drm_plane_force_disable(), the ref counts match and all looks fine. And
also that I didn't see this issue with 3.14.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/dab12e52/attachment-0001.sig>
ubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/3c53b7ff/attachment-0001.sig>
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong
---
drivers/gpu/drm/tegra/gem.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bc
On 04/11/2014 04:13 AM, Matthew Garrett wrote:
> The list of machines in the "Use native backlight" table is getting longer
> and longer, which is a solid indication that we're doing something wrong.
> Disable the ACPI backlight interface if the system claims to be Windows 8
> or later.
And has a
qemu as used by xend/xm toolstack uses a different subvendor id.
Bind the drm driver also to this emulated card.
Signed-off-by: Olaf Hering
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
> op 11-04-14 10:38, Thomas Hellstrom schreef:
>> Hi, Maarten.
>>
>> Here I believe we encounter a lot of locking inconsistencies.
>>
>> First, it seems you're use a number of pointers as RCU pointers without
>> annotating them as such and use the co
On Tue, Apr 08, 2014 at 02:19:24PM +0200, Benjamin Gaignard wrote:
> Make the link between all the hardware drivers and DRM/KMS interface.
> Create the driver itself and make it register all the sub-components.
> Use GEM CMA helpers for buffer allocation.
>
> Signed-off-by: Benjamin Gaignard
> Si
re 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/20140411/4f39bbee/attachment.html>
ani Nikula, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/085e43d5/attachment.html>
On Fri, 11 Apr 2014, Aaron Lu wrote:
> On 04/11/2014 04:13 AM, Matthew Garrett wrote:
>> The list of machines in the "Use native backlight" table is getting longer
>> and longer, which is a solid indication that we're doing something wrong.
>> Disable the ACPI backlight interface if the system cla
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/20140411/a129829d/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/95f48937/attachment.html>
Hi everyone,
This patchset adds support for sii9234 HD Mobile Link Bridge. The chip is used
to convert HDMI signal into MHL. The driver enables HDMI output on Trats and
Trats2 boards.
The code is based on the driver [1] developed by:
Adam Hampson
Erik Gilling
with additional cont
Add driver for HDMI bridge using MHL connection.
Contains refactored code for MHL driver developed by:
Adam Hampson
Erik Gilling
Shankar Bandal
Dharam Kumar
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
Documentation/devicetree/bindings/sii9234.txt | 22 +
drivers/m
This patch adds configuration of SiI9234 bridge to Trats2 board.
Signed-off-by: Tomasz Stanislawski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exyn
On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, jus
linux-git
'Tested-by: Ed Tomlinson '
THANKS!
--
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/20140411/d2f0200e/attachment.html>
For Z order property we have take example on exynos driver and keep
the same property name to avoid forking.
I would prefer to not hardcode Z order because we use it to do a kind
of composition between graphical planes and video planes.
It allow us to manage the Z order of some windows without usi
By the time drm_mode_config_cleanup calls this all the hw state should
be cleaned up already - we even have a WARN right before calling
plane->destroy callbacks asserting that all framebuffers are gone.
So trying to disable things harder is a bit a bug. Caught by Thierry
since it resulted in some
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/20140411/8e51c62f/attachment.html>
Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> On Fri, 11 Apr 2014 10:33:08 +0200
> Christian K?nig wrote:
>
Actually direct register access shouldn't be necessary so often. Apart
from page flips, write/read pointer updates and irq processing there
shouldn't be so many of them. Could
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #33 from Dzianis Kahanovich ---
Created attachment 131911
--> https://bugzilla.kernel.org/attachment.cgi?id=131911&action=edit
patch: port from <3.7
Try this patch. I have some happy uptime (I have this Gigabyte mb on work
desktop a
Hi,
as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current access to an X server terminal
to access the GPU memory of the active X server, without being
authenticated to the X server and thereby
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/24d63132/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140411/9fb71e7e/attachment.html>
vel/attachments/20140411/200edc27/attachment-0001.html>
Am 11.04.2014 04:29, schrieb Alex Deucher:
> Don't try and runtime suspend the APU in PX systems. We
> only want to power down the dGPU.
>
> v2: fix harder
> v3: fix stupid typo
> v4: consolidate runpm enablement to a single flag
>
> bugs:
> https://bugs.freedesktop.org/show_bug.cgi?id=75127
> htt
--
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/20140411/39a5550d/attachment.html>
> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 9:10 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: fix runpm handling on APUs (v
From: Thierry Reding
The only reason why struct drm_bus is still around is because the
SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
provides a fallback implementation if a device either doesn't have a bus
associated with it or if it doesn't implement .set_busid(). The
1 deletion(-)
Reviewed-by: Thierry Reding
Tested-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/27e08315/attachment.sig>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/e26a4627/attachment.html>
|--- |WORKSFORME
--
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/20140411/7a82263e/attachment.html>
Hi Inki,
This patchset refactors drm device initialization. Details are described
in respective patches. It is an alternative to DT supernode concept.
The first patch uses linker sections to get rid of ifdef macros, it is not
essential for 2nd patch but it makes code more readable. Similar approa
The patch removes driver registration code based on preprocessor conditionals.
Instead it uses private linker section to create array of drm drivers.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/Makefile | 2 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
driver
The patch adds function to block/unblock drm master device initialization.
exynos_drm_dev_ready(pdev, bool) informs exynos_drm core if given device is
ready. exynos_drm master is initialized only if all devices are ready,
exynos_drm master is also removed if any device becomes not ready.
During mod
ing 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/20140411/8fbee770/attachment.html>
On Fri, Apr 11, 2014 at 02:12:10PM +0200, Daniel Vetter wrote:
> By the time drm_mode_config_cleanup calls this all the hw state should
> be cleaned up already - we even have a WARN right before calling
> plane->destroy callbacks asserting that all framebuffers are gone.
>
> So trying to disable t
May fix stability issues with some newer cards.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ucode.h | 3 +++
drivers/gpu/drm/radeon/si.c | 34 +-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --
If the new mc ucode is available.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 18e91ee..10dae41 100
Fixes mclk stability on certain asics.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 25 -
drivers/gpu/drm/radeon/radeon_ucode.h | 4 +++-
2 files changed, 19
Am 11.04.2014 16:52, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Why adding *_mc2.bin for the MC firmware? To distinct if people have the
new or the old firmware?
If that's the case I would rather print
> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 11:03 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH 1/3] drm/radeon: add support for newer mc
May fix stability issues with some newer cards.
v2: print out mc firmware version used and size
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ucode.h | 3 +++
drivers/gpu/drm/radeon/si.c | 35 ++-
2 files c
Fixes mclk stability on certain asics.
v2: print out mc firmware version used and size
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 26 +-
drivers/gpu/drm/ra
If the new mc ucode is available.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 18e91ee..10dae41 100
From: Christian K?nig
Letting post and refernce divider get to big is bad for signal stability.
v2: increase the limit to 210
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display
Am 11.04.2014 17:21, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> v2: print out mc firmware version used and size
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
All three added to my drm-fixes-3.15 queue.
Christian.
> ---
> drivers/gpu/drm/radeon
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140411/06613f01/attachment.html>
On Fri, Apr 11, 2014 at 11:24 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Letting post and refernce divider get to big is bad for signal stability.
>
> v2: increase the limit to 210
Maybe mention the bug number?
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
>
On 04/11/2014 02:36 AM, Duan Jiong wrote:
> This patch fixes coccinelle error regarding usage of IS_ERR and
> PTR_ERR instead of PTR_ERR_OR_ZERO.
Same comment as the other patch; I prefer the existing code (although
I'll defer to Thierry as maintainer of both these pieces of code).
It would help
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Anyway, I would do like Ilia suggested and only put the else branch into
> a separate, not inlined function.
>
> BTW: It's probably a good idea to do the same for the write function as
> well.
I tested it. The majority of the size in
07:59:47 (GMT)
--
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/20140411/27846a73/attachment-0001.html>
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> > On Fri, 11 Apr 2014 10:33:08 +0200
> > Christian K?nig wrote:
> >
> Actually direct register access shouldn't be necessary so often. Apart
> from page flips, write/read pointer u
On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The only reason why struct drm_bus is still around is because the
> SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
> provides a fallback implementation if a device either doesn't h
1 - 100 of 144 matches
Mail list logo
