On 02.07.2014 01:46, Dieter N?tzel wrote:
> Am 01.07.2014 10:14, schrieb Michel D?nzer:
>> From: Michel D?nzer
>>
>> But move the programming back to the vertical blank interrupt handler.
>> And signal the flip as being completed immediately after programming it
>> to the hardware.
>>
>> This way
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #56 from Tobias Droste ---
No change here
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=78661
Dieter N?tzel changed:
What|Removed |Added
CC||Dieter at nuetzel-hh.de
--- Comment #6 fr
https://bugzilla.kernel.org/show_bug.cgi?id=64131
Dieter N?tzel changed:
What|Removed |Added
CC||Dieter at nuetzel-hh.de
--- Comment #1 fr
Am 02.07.2014 02:29, schrieb Michel D?nzer:
> On 02.07.2014 01:46, Dieter N?tzel wrote:
>> Am 01.07.2014 10:14, schrieb Michel D?nzer:
>>> From: Michel D?nzer
>>>
>>> But move the programming back to the vertical blank interrupt
>>> handler.
>>> And signal the flip as being completed immediately
On 02.07.2014 12:01, Dieter N?tzel wrote:
> Am 02.07.2014 02:29, schrieb Michel D?nzer:
>> On 02.07.2014 01:46, Dieter N?tzel wrote:
>>> Am 01.07.2014 10:14, schrieb Michel D?nzer:
From: Michel D?nzer
But move the programming back to the vertical blank interrupt handler.
And si
On 02.07.2014 12:11, Michel D?nzer wrote:
> On 02.07.2014 12:01, Dieter N?tzel wrote:
>> Am 02.07.2014 02:29, schrieb Michel D?nzer:
>>> On 02.07.2014 01:46, Dieter N?tzel wrote:
Am 01.07.2014 10:14, schrieb Michel D?nzer:
> From: Michel D?nzer
>
> But move the programming back to
From: Michel D?nzer
The vertical blank interrupt is already enabled/disabled via
drm_vblank_get/put(), and radeon_crtc_handle_flip() now bails gracefully
when there is no page flip ready.
Signed-off-by: Michel D?nzer
---
v2: Remove the pflip atomic as well
drivers/gpu/drm/radeon/cik.c
From: Michel D?nzer
But move the programming back to the vertical blank interrupt handler.
And signal the flip as being completed immediately after programming it
to the hardware.
This way we don't have to guess whether or not the hardware will execute
the flip in a given vertical blank period,
On 2 July 2014 12:31, Darren Etheridge wrote:
> On 07/01/2014 06:39 PM, Guido Mart?nez wrote:
>>
>> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
>>>
>>> [snip]
>>>
>>> Otherwise I think this is a good and useful patch series.
>>
>> It that a Tested-by tag? :)
>
>
> Sure - I wo
On 07/02/2014 05:01 AM, Christopher Friedt wrote:
> I have been unable to reproduce this issue in a plethora of test
> cases, although granted, I do not have access to a Win7 machine. For
> that, I have asked an Ubuntu tester to run through some tests for me.
>
> https://urldefense.proofpoint.com/v
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/2a0bbb7a/attachment.html>
ies described above
are rasterized as two triangles each, which makes the tearing more noticeable.
--
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-
On 01.07.2014 21:16, Christian K?nig wrote:
> Am 01.07.2014 08:48, schrieb Michel D?nzer:
>> On 30.06.2014 16:43, Christian K?nig wrote:
>>> Am 30.06.2014 08:10, schrieb Michel D?nzer:
On 29.06.2014 19:34, Christian K?nig wrote:
> I've just pushed the branch testing-3.15 to
> git://peo
On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This is a requirement f
Hi Marek,
On 07/01/2014 06:08 PM, Marek Szyprowski wrote:
> Hello,
>
> On 2014-07-01 10:52, Tobias Jakobi wrote:
>> Hello Marek,
>>
>> I think you had a similar patch in the tizen tree, but according to
>> Tomasz Figa, it was considered a hack. I don't quite see how this is
>> different.
>>
>> Als
https://bugzilla.kernel.org/show_bug.cgi?id=75241
Dan Merillat changed:
What|Removed |Added
CC||bugzilla at dan.merillat.org
--- Comment #
On 2014/7/2 14:21, Michael S. Tsirkin wrote:
> On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
>> Originally the reason to probe ISA bridge instead of Dev31:Fun0
>> is to make graphics device passthrough work easy for VMM, that
>> only need to expose ISA bridge to let driver know the r
On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote:
> This does not ring any bells to me (but that doesn't prove anything). A
> bisect result would be awesome.
Too bad.
Unless someone else has a better idea I hope to start bisecting one of
these days (that might take quite some time, especially
op 02-07-14 07:37, Greg KH schreef:
> On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote:
>> So after some more hacking I've moved dma-buf to its own subdirectory,
>> drivers/dma-buf and applied the fence patches to its new place. I believe
>> that the
>> first patch should be appli
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #57 from Mathias Tillman ---
No difference here either, unfortunately.
--
You are receiving this mail because:
You are watching the assignee of the bug.
From: Michel D?nzer
As well as enabling the vblank interrupt. These shouldn't take any
significant amount of time, but at least pinning the BO has actually been
seen to fail in practice before, in which case we need to let userspace
know about it.
Signed-off-by: Michel D?nzer
---
drivers/gpu/d
From: Michel D?nzer
Otherwise the DRM core and userspace will be confused about which BO the
CRTC is scanning out.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_display.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/
On Wed, May 14, 2014 at 08:42:17PM +0200, Thierry Reding wrote:
> I've been looking at converting the Tegra DRM driver to the component
> helpers for a while now and had to make some changes to make it work for
> that particular use-case. While updating the imx-drm and msm DRM drivers
> for those c
On Tue, 01 Jul 2014, Fabian Frederick wrote:
> use mm.h definition
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Fabian Frederick
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> -
Am 02.07.2014 05:55, schrieb Michel D?nzer:
> From: Michel D?nzer
>
> But move the programming back to the vertical blank interrupt handler.
> And signal the flip as being completed immediately after programming it
> to the hardware.
>
> This way we don't have to guess whether or not the hardware
rashes.
8. It's extremely annoying. I switched to Windows for the time being.
--
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/at
Am 02.07.2014 12:10, schrieb Michel D?nzer:
> From: Michel D?nzer
>
> As well as enabling the vblank interrupt. These shouldn't take any
> significant amount of time, but at least pinning the BO has actually been
> seen to fail in practice before, in which case we need to let userspace
> know abou
- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/257bd30a/attachment.html>
This small series adds support for DSI continuous clock as required by the
DSI specification and as needed for NVIDIA SHIELD's panel. Continuous clock
mode can be specified as the flags of a DSI device, and host drivers can check
this flag to adapt their behavior.
The flag is then added to the pan
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 devices to indicate
that they require continuous clock mode to operate properly.
Signed-off-by: A
Handle the MIPI_DSI_MODE_CLOCK_CONTINUOUS flag and only set TX-only
clock behavior when this flag is not present for the DSI device.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c
This panel can only operate in continuous clock behavior, so set the
appropriate flag to inform host drivers of this fact.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sim
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
---
arch/arm/boot/dts/tegra114-roth.dts | 23 ---
1 file changed, 20 insertions
On 07/01/2014 12:57 PM, Rob Clark wrote:
> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
> new file mode 100644
> index 000..6e33efe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt
> @@ -0,0 +1,51
Hi Dave,
Could you please pick those two patches up for v3.17 ?
On Thursday 06 February 2014 18:41:56 Laurent Pinchart wrote:
> The "Renesas Corporation" listed in the copyright notices doesn't exist.
> Replace it with "Renesas Electronics Corporation" and update the
> copyright years.
>
> Laure
On Wed, Jul 2, 2014 at 10:26 AM, Jordan Crouse
wrote:
>
> On 07/01/2014 12:57 PM, Rob Clark wrote:
>>
>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> new file mode 100644
>> index 000..6e33efe
>> --- /dev/null
>> +++
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 address.
I looked back over the two other times which this series has posted,
and noticed that two patches had been re
https://bugzilla.kernel.org/show_bug.cgi?id=64131
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/b75b68d0/attachment.html>
On Thu, Jul 03, 2014 at 12:09:25AM +0900, Inki Dae wrote:
> 2014-07-02 0:03 GMT+09:00 Jerome Glisse :
> > On Tue, Jul 01, 2014 at 05:55:25PM +0900, Inki Dae wrote:
> >>
> >> Hi Jerome,
> >>
> >>
> >> On 2014? 07? 01? 06:46, j.glisse at gmail.com wrote:
> >> > From: Jerome Glisse
> >> >
> >> > get_
On Thu, Jun 19, 2014 at 10:47:32AM +0200, Jean-Francois Moine wrote:
> The I2C address (reg) is required for the TDA998x driver to be loaded
> and initialized.
>
> Signed-off-by: Jean-Francois Moine
> ---
> - v3
> - change subject to drm/i2c
> - v2
> - don't force the I2C address to b
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/boot/dts/tegra114-roth.dts
> b/arch/arm/boot/dts/tegra
'frame_size_code' is not used in the function. Remove it.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0..feab
Hello,
On 2014-07-01 19:54, Tobias Jakobi wrote:
> Marek Szyprowski wrote:
>> On 2014-07-01 10:52, Tobias Jakobi wrote:
>>> I think you had a similar patch in the tizen tree, but according to
>>> Tomasz Figa, it was considered a hack. I don't quite see how this is
>>> different.
>>>
>>> Also, if I
Details reported in https://bugzilla.redhat.com/show_bug.cgi?id=1115241
Is this a DRI problem?
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
VT
On Thu, Jun 26, 2014 at 2:33 PM, Alexandre Courbot
wrote:
> This series adds support for probing platform devices on Nouveau, as well as
> the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since
> a few extra things need to be supported before that.
>
> This version is most
Hi all,
I was trying to bring up parallel LCD on our custom board (similar to
BeagleBoard-xM) and I did it finally - but I needed to tweak hardcoded value
of 'Invert pixel clock'. Maybe I'm doing something wrong, but anyway:
According to the display-timing.txt doc the 'pixelclk-act
'exynos_gem_obj' is not used in the function. Remove it.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 163a054..15db801 1006
On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > >
> > > >We do IGD pass-through
On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
> It's has been just a week. I will check and look into your patch
> series. I think Exynos drm should also be considered for the use of
> component match array.
Actually, this series has been around for much longer than just a
week. Your
On 07/02/2014 03:09 AM, Alexandre Courbot wrote:
> On Thu, Jun 26, 2014 at 2:33 PM, Alexandre Courbot
> wrote:
>> This series adds support for probing platform devices on Nouveau, as well as
>> the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards
>> since
>> a few extra thing
This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF inputs and does dynamic input
switch in the TDA998x I2C driver on start/stop audio streaming.
Signed-off-by: Jean-Francois Moine
---
This patch applies against linux-next.
---
.../devicet
On 07/02/2014 08:42 AM, Rob Clark wrote:
> On Wed, Jul 2, 2014 at 10:26 AM, Jordan Crouse
> wrote:
>>
>> On 07/01/2014 12:57 PM, Rob Clark wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
>>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>>> new file mode 10064
> Yes this could be argued that way, that anyway user than can use the gpu
> can already pin large amount of ram. But pining anonymous memory or file
> backed memory (ie non regular bo memory) is different as pages are still
> on the lru list and thus the vmscan code will still go over them which
>
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly t
On Wed, Jul 2, 2014 at 7:26 AM, Jordan Crouse wrote:
> On 07/01/2014 12:57 PM, Rob Clark wrote:
>>
>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> new file mode 100644
>> index 000..6e33efe
>> --- /dev/null
>> +++ b/Do
On Wed, 2 Jul 2014 18:56:28 +0200
Andrew Lunn wrote:
> How well will this work with Russell concept of a front end and two
> backends? Can you uses your CODEC twice, once with the I2S backend and
> a second time with the S/PDIF backend?
Hi Andrew,
The TDA998x CODEC has two functions:
- it sets
On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/
On Wed, Jul 02, 2014 at 07:51:54PM +0200, Jean-Francois Moine wrote:
> On Wed, 2 Jul 2014 18:56:28 +0200
> Andrew Lunn wrote:
>
> > How well will this work with Russell concept of a front end and two
> > backends? Can you uses your CODEC twice, once with the I2S backend and
> > a second time with
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #55 from kilobug at kilobug.org ---
I tried the patch on the "drm-fixes-3.16" branch, but I got the same result :
freeze after a while when playing a movie on mplayer -vo gl (that's the most
reliable method I found to get the freeze), s
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #56 from Alex Deucher ---
(In reply to kilobug from comment #55)
> I tried the patch on the "drm-fixes-3.16" branch, but I got the same result
> : freeze after a while when playing a movie on mplayer -vo gl (that's the
> most reliable
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #57 from perry3d at gmail.com ---
Created attachment 141931
--> https://bugzilla.kernel.org/attachment.cgi?id=141931&action=edit
Log file after i boot Windows 7
Hi again,
the bug is still not fixed for me. I still get a freeze when
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #58 from perry3d at gmail.com ---
Created attachment 141941
--> https://bugzilla.kernel.org/attachment.cgi?id=141941&action=edit
Directly booted into Arch Linux
--
You are receiving this mail because:
You are watching the assignee o
es/dri-devel/attachments/20140702/145ddb93/attachment.html>
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.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 3 ++-
inclu
On Wed, 02 Jul 2014, Vernon Tonnesen wrote:
> Details reported in https://bugzilla.redhat.com/show_bug.cgi?id=1115241
>
> Is this a DRI problem?
Smells like an i915 problem. Please file a bug on DRM/Intel at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI.
Thanks,
Jani.
--
Jani Nikula,
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140702/02dd2716/attachment.html>
From: Christian K?nig
Userspace shouldn't be able to access them.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/ra
> 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,
it should give us a good idea if it's indeed a
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 slightly for 3.16.
Reviewed-by: Alex Deucher
> ---
--
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/20140702/f79c30aa/attachment-0001.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/fb089ea3/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/20140702/57d3032d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #59 from kilobug at kilobug.org ---
I mean I manually (In reply to Alex Deucher from comment #56)
> (In reply to kilobug from comment #55)
> > I tried the patch on the "drm-fixes-3.16" branch, but I got the same result
> > : freeze afte
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #60 from Alex Deucher ---
(In reply to kilobug from comment #59)
> I mean I manually applied the patch on
> https://bugzilla.kernel.org/attachment.cgi?id=141741&action=diff to the
> "drm-fixes-3.16" branch, I'll try the drm-fixes-3.16-
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/218858ae/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/bc50cc0b/attachment.html>
On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote:
> On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes
> wrote:
>> People keep whining about this, but no one seems to send a patch. This
>> *ought* to be safe now that we've dealt with the hw races in Mario's
>> updated code, and fixed the bugs w
On Wed, Jul 2, 2014 at 1:12 PM, Olof Johansson wrote:
> On Wed, Jul 2, 2014 at 7:26 AM, Jordan Crouse
> wrote:
>> On 07/01/2014 12:57 PM, Rob Clark wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
>>> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>>> new file m
On Wed, 2 Jul 2014 13:35:19 -0700
St?phane Marchesin wrote:
> On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote:
> > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes
> > wrote:
> >> People keep whining about this, but no one seems to send a patch. This
> >> *ought* to be safe now that we've
https://bugzilla.kernel.org/show_bug.cgi?id=77001
Grzegorz Kowal changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 use drm/msm on upstream kernel.
>>
>> Signed-off-by: Rob Clark
>>
On 07/02/2014 03:01 PM, Rob Clark wrote:
> As far as I can tell from diving downstream android kgsl code, seems
> like some a2xx you might be able to read the value from hw. Beyond
> that I'm not entirely sure. (Remember, no docs.)
Ohhh! I get to tell a story!
The on chip registers have a long
Hi Dave,
Some additional radeon fixes for 3.16. It's a bit bigger than usual
since I missed last week. Fixes for some system hangs, displays issues,
and some fallout from the new pageflipping changes.
The following changes since commit 0fcb70c30131aac40f62ba13f89963d5c13b48a7:
Merge tag 'drm
A driver which doesn't have async flip support will queue up flips without any
way to replace them afterwards. This means we've got a scanout buffer pinned
as soon as we schedule a flip and so we need another buffer to keep from
stalling.
When vblank_mode=0, if there are only three buffers we do:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/76362ace/attachment.html>
Hi Linus,
holiday fixes dump and run, all radeon fixes for mostly power management
stuff, though a few other regrsesion fixes also,
and one permission changed sneaked past me, so I changed it back.
I'm off for a few days now, but I'll be online for a small while each day.
Dave.
The followin
This is needed to be able to send page flip completion events.
Also while I'm at it, fix the error paths on init.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/udl/udl_main.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu
This is a very crude page_flip implementation for UDL. There are ways
to make it better (make it asynchronous, make it do actual vsynced
flips...) but that's for another patch.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/udl/udl_modeset.c | 21 +
1 file changed, 21
At least one source has reported that vmwgfx_fb.c::vmw_fb_check_var()
is not even a code path that is traversed when the bug occurs (i.e.
inserted unique log message -> never seen in logs).
Also, everyone encountering the bug seems to be on a slightly older
version of VMWare Player. It does not se
full speed capacity for cards not sticking to reference board)
--
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/20140702/
ves/dri-devel/attachments/20140702/f70617e0/attachment.html>
plete and correct.
--
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/20140702/74f128fc/attachment.html>
vel/attachments/20140702/eeb2c872/attachment.html>
On Wed, Jul 02, 2014 at 06:38:41PM +0200, Jean-Francois Moine wrote:
> This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF inputs and does dynamic input
> switch in the TDA998x I2C driver on start/stop audio streaming.
Hi Jean-Francois
: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/6be10f4f/attachment-0001.sig>
ignature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140702/bc2ef7e8/attachment-0001.sig>
On 02 Jul 02:08 PM, Dave Airlie wrote:
> On 2 July 2014 12:31, Darren Etheridge wrote:
> > On 07/01/2014 06:39 PM, Guido Mart?nez wrote:
> >>
> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
> >>>
> >>> [snip]
> >>>
> >>> Otherwise I think this is a good and useful patch seri
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 use drm/msm on upstream kernel.
>
> Signed-off-by: Rob Clark
> ---
> Commence bikeshedding :-)
>
> Documentation/device
100 matches
Mail list logo
