Hi,
git branch drm-fixes-3.12, git commit
cdf6e8058415ba4d808537e30a0a6be9fb29e95a
In si_dpm.c, the vddc phase shedding mask does overwrite the vddc
voltage mask (lines 3889 and 3920 in
si_populate_smc_voltage_tables function). Expected?
(my tahiti based board seems not to have vddc phase shedd
On Tue, Oct 29, 2013 at 11:09:40AM -0400, Ilija Hadzic wrote:
> The following patch series fixes the mutex corruption problem
> due to bit-copying of drm_crtc structure that happens when
> drm_crtc_helper_set_config function takes the error-recovery
> path. The patch series is the alternative solut
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik_sdma.c | 3 +++
drivers/gpu/drm/radeon/ni_dma.c | 3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 24
drivers/gpu/drm/radeon/si_dma.c | 3 +++
4 files changed, 33 inser
From: Christian K?nig
Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one function.
Activate all waiters and remember if the reset was already done instead of
trying to reset from only one thread.
v2: clear res
From: Christian K?nig
The DMA ring seems to be stable now.
v2: remove pt_ring_index as well
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/cik.c | 61 -
drivers/gpu/drm/radeon/cik_sdma.c| 21 --
drivers/gpu/drm/radeon/ni.c |
From: Christian K?nig
Clear page tables after allocating them in case
we don't completely fill them later.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index fd109d3..8a83b
On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa wrote:
> Hi,
>
> On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>> > I think we need to start considering a framework where subdrivers
>> > just
>> > add drm objects themsel
On Tue, 29 Oct 2013, Daniel Vetter wrote:
> Aside: The horribly ad-hoc calling convetions with some of the (x, y, fb,
> mode) parameters being set before calling a lower-level functions, some
> being restored, some of them being the old backup value and some of them
> being expected to be update
On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote:
> On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa
wrote:
> > Hi,
> >
> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
wrote:
> >> > I think we need to start considering
Hi,
On 29/10/13 20:23, Tomasz Figa wrote:
>> It's a very deeply nested structure, I'm not sure there's a need to
>> > make a ports {} subnode really.
>> >
>> > Also, I don't know if it makes sense to always name it
>> > remote-endpoint, or to use a more flexible name depending on what is
>> > act
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/9a557dcf/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64021
Bug ID: 64021
Summary: nouveau: Second card output corrupted after suspend /
resume
Product: Drivers
Version: 2.5
Kernel Version: linux-3.11
Hardware: x86-64
https://bugzilla.kernel.org/show_bug.cgi?id=64021
--- Comment #1 from thomas.bettler at gmail.com ---
Created attachment 112671
--> https://bugzilla.kernel.org/attachment.cgi?id=112671&action=edit
corrupted screen (image)
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=64021
--- Comment #2 from thomas.bettler at gmail.com ---
Created attachment 112681
--> https://bugzilla.kernel.org/attachment.cgi?id=112681&action=edit
expected screen
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Oct 29, 2013 at 8:22 PM, Ilija Hadzic
wrote:
>
>>> The actual fix is implemented in patch #6; preceding
>>> 5 patches are necessary prerequisites.
>>
>>
>> Hm, I don't really see why patches 1,2&4 are required. If we reorder them
>> to the end of the series as follow-up cleanups then we'd
On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote:
> Hi,
>
> On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>> > I think we need to start considering a framework where subdrivers
>> > just
>> > add drm objects themsel
https://bugzilla.kernel.org/show_bug.cgi?id=64021
--- Comment #3 from thomas.bettler at gmail.com ---
Created attachment 112691
--> https://bugzilla.kernel.org/attachment.cgi?id=112691&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=64021
thomas.bettler at gmail.com changed:
What|Removed |Added
URL||https://bugs.freedesktop.or
Hi Sean,
On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
wrote:
> > Hi,
> >
> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
wrote:
> >> > I think we need to start consid
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/5e890fb8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64021
thomas.bettler at gmail.com changed:
What|Removed |Added
Kernel Version|linux-3.11 |3.11
--
You are receiving t
On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
> wrote:
>> > Hi,
>> >
>> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> >> On Wed, Oct 23, 2013 at 11:53 AM,
https://bugzilla.kernel.org/show_bug.cgi?id=64021
thomas.bettler at gmail.com changed:
What|Removed |Added
Attachment #112691|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=64021
thomas.bettler at gmail.com changed:
What|Removed |Added
Kernel Version|3.11|3.12_rc7
--
You are receivi
From: Ian Romanick
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
Signed-off-by: Ian Romanick
Cc: Mika Kuoppala
Cc: Daniel Vetter
---
include
From: Ian Romanick
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
Signed-off-by: Ian Rom
to test and debug, than several smaller
> drivers, which could be developed separately.
>
This is the opposite of our experience, though. A series of small drivers
like what's in drm/exynos can become really tedious/difficult to
coordinate. If you have separate drivers, everything needs to be
synchronized, but also has to account for potentially different loading
order.
It seems you're only thinking about the basic case, where you only support
a single resolution, no dpms, no suspend to ram... But when you want full
fledged functionality, then the issues I described become much more
prevalent.
St?phane
>
> Unless there is a misunderstanding here, I think this is broken.
>
> > An example: exynos_drm_drv would be a platform_driver which implements
> > drm_driver. On drm_load, it would enumerate the various dt nodes for
> > its IP blocks and initialize them with direct calls (like
> > exynos_drm_fimd_initialize). If the board uses a bridge (say for
> > eDP->LVDS), that bridge driver would be a real driver with its own
> > probe.
> >
> > I think the ideal situation would be for the drm layer to manage the
> > standalone drivers in a way that is transparent to the main driver,
> > such that it doesn't need to know which type of hardware can hang off
> > it. It will need to know if one exists since it might need to forego
> > creating a connector, but it need not know anything else about it.
> >
> > To accomplish this, I think we need:
> > (1) Some way for drm to enumerate the standalone drivers, so it can
> > know when all of them have been probed
> > (2) A drm registration function that's called by the standalone
> > drivers once they're probed, and a hook with drm_device pointer called
> > during drm_load for them to register their drm_* implementations
> > (3) Something that will allow for deferred probe if the main driver
> > kicks off before the standalones are in, it would need to be called
> > before drm_platform/pci_init
> >
> > I think we'll need to expand on the media bindings to achieve (1).
>
> Could you elaborate on why you think so?
>
> I believe the video interface bindings contain everything needed for this
> case, except, of course, some device/bus specific parts, but those are to
> be defined by separate device/bus specific bindings.
>
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/1f1d1739/attachment.html>
101 - 128 of 128 matches
Mail list logo
