On Thu, Jul 03, 2014 at 06:17:24PM -0400, Rob Clark wrote:
> On Thu, Jul 3, 2014 at 12:49 PM, Russell King
> wrote:
> > Add a helper to allow encoders to find their possible CRTCs from the
> > OF graph without having to re-implement this functionality. We add a
> > device_node to drm_crtc which c
On Thu, Jul 3, 2014 at 6:54 PM, Esben Stien wrote:
>
> I was running the Xonotic game and the gpu locked up. I have compiled
> the radeon driver inside the kernel.
>
> 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Oland PRO [Radeon R7 240]
> Linux quasar 3.16.0-rc3 #
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/a4f4127e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #61 from Tobias Droste ---
I'm currently running drm-next from that day+your patch.
It does not seem to be the same problem for me, because mlck is 12 for
every level as soon as there's a second screen and only level 2 stays stuck
kernel bug).
GPU: Radeon HD 4850 (RV770)
--
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/20140703/a5285078/attachment.html>
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/20140703/c4502b30/attachment-0001.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/031858b5/attachment.html>
On Thu, Jul 03, 2014 at 10:52:00PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
> > >From a brief look, it looks like my comments have been addressed, so I
> > think this is starting to shape up..
> >
> > Laurent/Thierry/Russell, I don't suppo
On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
> >From a brief look, it looks like my comments have been addressed, so I
> think this is starting to shape up..
>
> Laurent/Thierry/Russell, I don't suppose any of you are likely to have
> time before 3.17 merge window to give sti one las
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/20140703/ee53b43b/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/9f71ce6f/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140703/5dc7d3e6/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/1f06874a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/49fb0ffa/attachment.html>
le as a 35MB gzipped C file (>300MB uncompressed).
--
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/20140703/6b1dd1fd/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/fe12433e/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/02fb95ca/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/22354239/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #64 from kilobug at kilobug.org ---
Great news !
I tried the -wip branch, and so far no crash (with and without hyperz). I will
keep running it and see how it works. I'll do more tests during the week-end,
and hopefully they won't cras
On Thu, Jul 3, 2014 at 8:27 PM, Ben Skeggs wrote:
> On Fri, Jul 4, 2014 at 5:27 AM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Based on a recent discussion in #radeon, and also my own observation that the
>> 'full' scaling causes no end of confusion among users.
>>
>> See http
https://bugzilla.kernel.org/show_bug.cgi?id=42787
Stephan Diestelhorst changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [ 2870.976188] Setting up static identity map for 0x4043c0d8 - 0x4043c130
> [ 2920.607946] CPU1: Booted secondary processor
> [ 2920.607979] CPU1: update cpu_capacity 1024
> [ 2920.607983] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
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/20140703/2134db1f/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/20140703/18e41aa0/attachment.html>
From: mark
This patch is a DRM Driver for Rockchip Socs and now only add the
framework of Rockchips Socs, but we will add Rockchips Socs soon.
Signed-off-by: mark
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers
From: mark
This patch is a DRM Driver for Rockchip Socs and now only add the
framework of Rockchips Socs, but we will add Rockchips Socs soon.
mark (1):
drm: Add Drm driver for Rockchip Socs
--
1.7.9.5
While this series is more correct from the DMA API point of view, it
is also much heavier as it strictly disables the use of any cache on
all user-space mapped BOs, and is also much more restricted in terms
of which memory it can use.
I have a v4 in the works that lets us use TTM for user-mapped o
g/archives/dri-devel/attachments/20140703/faa0446a/attachment.html>
houghts on the IRC:
AbortRetryFail: 1:1 unscaled output for LCDs would be awesome.
AbortRetryFail: 1280x720 looks horrible scaled up to fit a 1366x768 LCD
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/20140703/4fa4714f/attachment.html>
On Thu, Jul 3, 2014 at 12:49 PM, Russell King
wrote:
> Add a helper to allow encoders to find their possible CRTCs from the
> OF graph without having to re-implement this functionality. We add a
> device_node to drm_crtc which corresponds with the port node in the
> DT description of the CRTC dev
On Thu, 3 Jul 2014 16:43:25 +0100
Russell King - ARM Linux wrote:
> What you're doing in kirkwood-i2s is providing two plain DAI links,
> and then insisting that only one can be active any any one time.
>
> A DPCM solution provides at least one frontend DAI link and at least
> one backend DAI li
On Thu, Jul 3, 2014 at 12:49 PM, Russell King
wrote:
> Add a helper to allow encoders to find their possible CRTCs from the
> OF graph without having to re-implement this functionality. We add a
> device_node to drm_crtc which corresponds with the port node in the
> DT description of the CRTC dev
On Thu, Jul 3, 2014 at 5:52 PM, Russell King - ARM Linux
wrote:
> On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
>> >From a brief look, it looks like my comments have been addressed, so I
>> think this is starting to shape up..
>>
>> Laurent/Thierry/Russell, I don't suppose any of you
Add a helper to allow encoders to find their possible CRTCs from the
OF graph without having to re-implement this functionality. We add a
device_node to drm_crtc which corresponds with the port node in the
DT description of the CRTC device.
We can then scan the DRM device list for CRTCs to find t
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #60 from Mathias Tillman ---
I've done some further tests with overriding the power state level values as
detailed above, here are my results:
The stock values are
level 0: sclk: 1, mclk: 3, vddc: 950, vddci: 950
level 1: sclk
From: Sachin Kamat
Makes the code a bit more readable.
Signed-off-by: Sachin Kamat
Signed-off-by: Sachin Kamat
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/dr
>From a brief look, it looks like my comments have been addressed, so I
think this is starting to shape up..
Laurent/Thierry/Russell, I don't suppose any of you are likely to have
time before 3.17 merge window to give sti one last once-over to see
what I missed ;-)
BR,
-R
On Wed, Jun 18, 2014 at
On Thu, 3 Jul 2014 14:43:46 +0100
Russell King - ARM Linux wrote:
> > But, this means that there will be a lot of errors when DPCM will be
> > used, because, in most cases for the Cubox (kirkwood audio + tda998x),
> > both ways I2S and S/PDIF will be activated at the same time for a
> > single st
On Thu, Jul 3, 2014 at 7:08 AM, mark yao wrote:
> From: mark
>
> This patch is a DRM Driver for Rockchip Socs and now only add the
> framework of Rockchips Socs, but we will add Rockchips Socs soon.
just a very quick skim over this.. I expect I'll have some more
comments when I see a usage of t
On Thu, Jul 03, 2014 at 05:29:09PM +0200, Jean-Francois Moine wrote:
> I think that you did not look at my code.
>
> Both S/PDIF and I2S work with the TDA998x. It is a choice of the audio
> subsystem to do this choice, not Russell King.
If you think I'm arguing because I personally want something
Hi Rob,
> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> add necessary DT support so that we can use drm/msm on upstream kernel.
>
> Signed-off-by: Rob Clark
> ---
> Commence bikeshedding :-)
>
> diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
> b/Docu
Hello,
It's been almost a month and I only got reviews pointing minor issues.
I'd really like to get feedback/reviews from DRM/KMS maintainers and/or
experienced developers (this is my first DRM/KMS driver I'm pretty sure
there are things to fix).
Best Regards,
Boris
On Mon, 9 Jun 2014 18:04
On Thu, 3 Jul 2014 12:59:24 +0100
Mark Brown wrote:
> > > Your board happens to only be able to present the same input on both I2S
> > > and S/PDIF but that might not apply to other boards, they may be able to
> > > route different signals to each which would present a practical problem.
>
> >
Signed-off-by: Ilia Mirkin
---
Based on a recent discussion in #radeon, and also my own observation that the
'full' scaling causes no end of confusion among users.
See https://bugs.freedesktop.org/show_bug.cgi?id=80868 for some more details,
although it is more radeon-specific.
Side-note: the s
vel/attachments/20140703/a02ec3e9/attachment.html>
Hello Thierry,
I haven't had any feedback from you on this pretty straightforward
patch series adding support for a new LCD panel.
Did you receive it in the first place ?
Best Regards,
Boris
On Thu, 5 Jun 2014 15:53:30 +0200
Boris BREZILLON wrote:
> Hello,
>
> This series adds a new entry
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #59 from Mathias Tillman ---
I was using the 3.15 kernel (with your patch applied manually) on my last
reply, but I just updated to the drm-fixes-3.16 branch and unfortunately there
is no difference; it still gets stuck in the highest
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #40 from sdh ---
Hi. Do we close this bug report now that I can successfully boot into 3.15
along with the radeon module?
--
You are receiving this mail because:
You are watching the assignee of the bug.
The patch puts repeated code sequence into one function, removes verbose
comments and decreases log verbosity.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 74 ++---
1 file changed, 21 insertions(+), 53 deletions(-)
diff --git a/drivers/
There is no gain in passing id by pointer to be filled.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exy
In case of error callback prints already corresponding message.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_d
The patch simplifies ipp_find_obj and removes debug messages.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos
Argument checks are redundant, clients always check ippdrv before calling
these functions.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_dr
The only thing function should check is if there are buffers in respective
queues.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 44 -
1 file changed, 10 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ip
list_first_entry does not return NULL on empty list so this check
does not make sense. Moreover there is already code which prevents calling
list_first_entry on empty lists.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ---
1 file changed, 15 deletion
There is no reason to allocate intermediate variable.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
ind
exynos_drm_gem_get_dma_addr returns dma_addr_t, type casting to void* and
back is not necessary.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gp
struct exynos_drm_ipp_private contains only one pointer so all occurrences
of the struct can be replaced by the pointer itself.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 30 +-
drive
The patch removes unused event_list field from struct exynos_drm_ipp_private.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/d
The patch replaces type casting with proper pointer.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index a1888e1..f3f1
This set of independent patches contains various improvement and fixes
for exynos_drm ipp framework.
The patchset is based on exynos-drm-next branch.
Regards
Andrzej
Andrzej Hajda (12):
drm/exynos/ipp: remove type casting
drm/exynos/ipp: remove unused field from exynos_drm_ipp_private
drm/
https://bugzilla.kernel.org/show_bug.cgi?id=78661
--- Comment #7 from Nikolaus Waxweiler ---
Created attachment 142021
--> https://bugzilla.kernel.org/attachment.cgi?id=142021&action=edit
Rebuilt kernel with patch, just got a hang again :(
--
You are receiving this mail because:
You are watch
Dave, a fix to a 3.15 commit.
The following changes since commit 0fcb70c30131aac40f62ba13f89963d5c13b48a7:
Merge tag 'drm-intel-fixes-2014-06-26' of
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-06-27 15:04:06
+1000)
are available in the git repository at:
git://people.fre
Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.
This patch is Cc'd stable because of the unknown e
On Thu, Jul 03, 2014 at 03:28:26PM +0200, Jean-Francois Moine wrote:
> OK. no problem, I can do that: only the first stream is switched and
> the second is rejected.
>
> But, this means that there will be a lot of errors when DPCM will be
> used, because, in most cases for the Cubox (kirkwood audi
On Thu, Jul 3, 2014 at 12:36 PM, wrote:
> Hi Rob,
>
>> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
>> add necessary DT support so that we can use drm/msm on upstream kernel.
>>
>> Signed-off-by: Rob Clark
>> ---
>> Commence bikeshedding :-)
>>
>
>> diff --git a/Docu
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #58 from Alex Deucher ---
What kernel did you try? I haven't been able to reproduce this for a while. I
just tested a bunch of boards yesterday with 3.16 and multi-head dpm worked
properly on all of them.
--
You are receiving this
On Thu, 3 Jul 2014 11:44:32 +0100
Mark Brown wrote:
> > > I'd expect this to return an error for the busy DAI rather than just
> > > silently ignore it failing to start or (better) implement some control
> > > to let the user select which of the DAIs is active.
>
> > This is not an error. If t
r by
rejecting the second interface.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/d5383422/attachment.sig>
On 03.07.2014 04:31, Christian K?nig wrote:
>> FWIW, I've also had successful runs with the first three of the split
>> changes, and with all of them.
> Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page
> table allocation to the end of VRAM. Please try with this memory layout
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/e1aa60d6/attachment-0001.html>
DSI support has been fixed to support continuous clock behavior that the
panel used on SHIELD requires, so finally add its device tree node since
it is functional.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Removed unneeded regulator-always-on property for vdd_lcd regulator
Only pat
On 07/03/2014 12:55 AM, Stephen Warren wrote:
> On 07/02/2014 06:19 AM, Alexandre Courbot wrote:
>> DSI support has been fixed to support continuous clock behavior that the
>> panel used on SHIELD requires, so finally add its device tree node since
>> it is functional.
>
>> diff --git a/arch/arm/bo
ion/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/d93d80ab/attachment-0001.sig>
On Thu, Jul 03, 2014 at 01:51:19AM +0200, Laurent Pinchart wrote:
> On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote:
> > On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> > > A while back, Laurent raised some comments about the component helper,
> > > whi
If there are error flags in the aux transaction return
-EIO rather than -EBUSY. -EIO restarts the whole transaction
while -EBUSY jus retries. Fixes problematic aux transfers.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80684
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
Hi Dave -
Fixes for 3.16-rc3; most importantly Jesse brings back VGA he took away
on a bunch of machines. Also a vblank fix for BDW and a power workaround
fix for VLV.
BR,
Jani.
The following changes since commit 8525a235c96a548873c6c5644f50df32b31f04c6:
drm/i915: vlv_prepare_pll is only nee
Hi,
In Exynos DRM driver I found a NULL pointer exception when there were no
components set for DRM driver:
https://lkml.org/lkml/2014/6/30/331
The NULL pointer will happen during driver suspend if drm_driver.load()
is not called. The load() won't be called if no components are added.
After look
Hi Alexandre,
Thanks for the patch.
On 07/02/2014 02:19 PM, Alexandre Courbot wrote:
> As per section 5.6.1 of the DSI specification, all DSI transmitters must
> support continuous clock behavior on the clock lane, while non-continuous
> mode support is only optional. Add a flag that allows devi
On Wed, Jul 02, 2014 at 10:01:40PM +0100, Rob Clark wrote:
> On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland wrote:
> > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
> >> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> >> add necessary DT support so that we can
The VGA arbiter does not allow devices to "own" resources that it
doesn't "decode". However, it does allow devices to "lock" resources
that it doesn't decode. This gets us into trouble because locking
the resource goes through the same bridge routing updates regardless
of whether we decode the re
Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.
There has been some reports of incorrect rendering
From: Christian K?nig
bo->mem.placement is not initialized when ttm_bo_man_get_node is called,
so the flag had no effect at all.
v2: change nouveau and vmwgfx as well
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 3 +++
driver
if (r == 0)
> + dssdev->driver->set_hdmi_infoframe(dssdev, &avi);
> + }
> }
>
> static void omap_encoder_prepare(struct drm_encoder *encoder)
>
-- 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/20140703/abe2d6f8/attachment-0001.sig>
Am 02.07.2014 21:53, schrieb Alex Deucher:
> On Wed, Jul 2, 2014 at 3:28 PM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> Userspace shouldn't be able to access them.
>>
>> Signed-off-by: Christian K?nig
>> Cc: stable at vger.kernel.org
> I assume this is for 3.15. I had to tweak it
Am 03.07.2014 05:48, schrieb Michel D?nzer:
> On 03.07.2014 04:31, Christian K?nig wrote:
>>> FWIW, I've also had successful runs with the first three of the split
>>> changes, and with all of them.
>> Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page
>> table allocation to t
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/0ece015a/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #63 from Michel D?nzer ---
(In reply to perry3d from comment #61)
> Things are getting worse. Now i got a kernel panic.
That panic is fixed in the current drm-fixes trees, and hopefully soon in
Linus' tree.
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #62 from perry3d at gmail.com ---
Created attachment 142011
--> https://bugzilla.kernel.org/attachment.cgi?id=142011&action=edit
jounralctl -k before kernel panic
I also get crashes of the snd_hda module as you can see in the log.
-
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #61 from perry3d at gmail.com ---
Created attachment 142001
--> https://bugzilla.kernel.org/attachment.cgi?id=142001&action=edit
Kernel panic
Things are getting worse. Now i got a kernel panic. But i was able to take a
picture of the
On Wed, 2 Jul 2014 20:42:52 +0100
Mark Brown wrote:
> > I tested this CODEC with both DAPM and DPCM. If the audio subsystem
> > asks for streaming on both I2S and S/PDIF, only the last call is served
> > (this depends on the order of the DAI links in the audio card creation
> > table).
>
> I'd
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/ffd3f259/attachment.html>
Hi Ajay,
Thanks a lot for your work on this.
Am 11.06.2014 20:26, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-s
On Thu, Jul 3, 2014 at 5:15 AM, Mark Rutland wrote:
> On Wed, Jul 02, 2014 at 10:01:40PM +0100, Rob Clark wrote:
>> On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland wrote:
>> > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
>> >> Now that we (almost) have enough dependencies in place (MMC
sts.freedesktop.org/archives/dri-devel/attachments/20140703/2ff7047a/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/c16847e2/attachment.html>
- Original Message -
> Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
> vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
> SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
> SVGA_REG_PITCHLOCK.
>
> There h
Hi Russell,
Sorry for the late review.
On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote:
> On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> > A while back, Laurent raised some comments about the component helper,
> > which this patch set starts to addre
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/3aae7036/attachment.html>
2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux :
> On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
>> > Hi Russell,
>> >
>> > On Tue, Jun 24, 2014 at 9:29 PM, Russell King
>> > wrote:
>> > [...]
>> > >
1 - 100 of 101 matches
Mail list logo
