On Fri, Jun 13, 2014 at 09:51:22PM +0200, Christoph Jaeger wrote:
> intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
> 'intel_connector' point to. Simply bail out before allocating memory.
>
> Picked up by Coverity - CID 1222750.
>
> Signed-off-by: Christoph Jaeger
Queued f
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/09cb5ed4/attachment.html>
intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
'intel_connector' point to. Simply bail out before allocating memory.
Picked up by Coverity - CID 1222750.
Signed-off-by: Christoph Jaeger
---
drivers/gpu/drm/i915/intel_dsi.c | 14 +++---
1 file changed, 7 insertions
profile mask: core profile
Is it a known issue?
--
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/20140613/cc263f01/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/f5c38ef7/attachment-0001.html>
From: Thierry Reding
Add the GK20A device node to Tegra124's device tree.
Signed-off-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra124.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
Signed-off-by: Alexandre Courbot
Acked-by: Stephen Warren
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/dev
Add a platform driver for Nouveau devices declared using the device tree
or platform data. This driver currently supports GK20A on Tegra
platforms and is only compiled for these platforms if Nouveau is
enabled.
Nouveau will probe the chip type itself using the BOOT0 register, so all
this driver re
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.
Thanks to the input received for v1, this version is more self-contained and
shares less
At Fri, 13 Jun 2014 18:07:06 +0200,
Daniel Vetter wrote:
>
> On Fri, Jun 13, 2014 at 05:56:02PM +0200, Takashi Iwai wrote:
> > When a machine is booted with nomodeset option, i915 driver skips the
> > whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
> > by request_symbol() wi
On Fri, Jun 13, 2014 at 05:56:02PM +0200, Takashi Iwai wrote:
> When a machine is booted with nomodeset option, i915 driver skips the
> whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
> by request_symbol() without knowing that the initialization was
> skipped, and eventually
This patch resolves page fault issue of Mixer when disabled.
The SFRs of VP and Mixer are updated by Vertical Sync of Timing
generator which is a part of HDMI so the sequence to disable TV
Subsystem should be as following:
VP -> Mixer -> HDMI
For this, this patch disables Mixer and VP (if
When a machine is booted with nomodeset option, i915 driver skips the
whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_
Hi Marek,
ah, yes! Piglit in combination with that patch can indeed crash the box.
Going to investigate now that I can reproduce it.
Thanks,
Christian.
Am 13.06.2014 15:19, schrieb Marek Ol??k:
> Hi,
>
> With my "force_gtt" patch, Cape Verde is unstable too, so all GCN
> chips are affected.
>
>
On Fri, Jun 13, 2014 at 11:45 AM, Christian K?nig
wrote:
> Hi Marek,
>
> ah, yes! Piglit in combination with that patch can indeed crash the box.
>
> Going to investigate now that I can reproduce it.
I wonder if it's a clockgating issue with the MC or BIF? You might
try adjusting the rdev->cg_fl
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/85def4ac/attachment.html>
iving 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/20140613/e9401804/attachment.html>
ted - the
latter just so I could revert the former.
I'll see if I am stable over the next couple of days like this.
--
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/20140613/a14fbdad/attachment.html>
TLB?
>
> Ok ignore that :-) I didn't spot the rs600
It applies to all asics from rs600 forward.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/df4abbac/attachment.html>
gt; int i, uint64_t addr)
>>>>> return -EINVAL;
>>>>> }
>>>>> addr = addr & 0xF000ULL;
>>>>> - addr |= R600_PTE_GART;
>>>>> + if (addr == rdev->dummy_page.addr)
>>>>> + addr |= R600_PTE_SYSTEM | R600_PTE_SNOOPED;
>>>>> + else
>>>>> + addr |= R600_PTE_GART;
>>>>> writeq(addr, ptr + (i * 8));
>>>>> return 0;
>>>>>}
>>>>> --
>>>>> 1.9.1
>>>>>
>>>>> ___
>>>>> dri-devel mailing list
>>>>> dri-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-force_gtt.patch
Type: text/x-patch
Size: 1537 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/d50242c6/attachment.bin>
enabled.
--
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/20140613/ac206326/attachment.html>
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/20140613/db7bb3c9/attachment.sig>
nfig | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Applied, thanks.
Thierry
-- 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/20140613/c9420170/attachment-0001.sig>
again
the game vsync is still not enabled.
--
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/20140613/2e68042a/attachment-0001.html>
On Friday 13 June 2014 14:06:11 Russell King wrote:
> DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> DRM_PANEL && DRM, whereas DRM_PANEL_SIMPLE relies upon the dependency
> on the menu.
>
> We do not need to use explicit dependencies if we make the menu depend
> on DRM_PANEL
e rs600
--
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/20140613/087a61b6/attachment.html>
Hello Alexandre,
On 13/06/2014 13:43, Alexandre Belloni wrote:
> On 09/06/2014 at 18:04:15 +0200, Boris Brezillon wrote :
>> The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
>> at91sam9x5 family or sama5d3 family) provide a PWM device.
>>
>> This driver add support for this
-devel/attachments/20140613/14bdde61/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/07abe769/attachment.html>
On Fri, Jun 13, 2014 at 07:54:45AM +0200, Andrzej Hajda wrote:
> Hi Russel,
>
> Thanks for both fixes. Just one nitpick.
>
> On 06/12/2014 06:09 PM, Russell King wrote:
> > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> > DRM_PANEL && DRM. This is nonsense for two reasons:
On 2014? 06? 02? 01:04, Tobias Jakobi wrote:
> When division of source and destination width yields the
> scaling factor for the x-coordinate, then it should be
> source/destination _height_ for y.
Signed-off-by: Inki Dae
Thanks,
Inki Dae
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exyno
Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
increase in the probability of Kconf reporting circular dependencies
(we're one "select" away from that right now), make this depend on
SPI instead. This is akin to having some driver select DRM.
Having some drivers depend on a
DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
DRM_PANEL && DRM, whereas DRM_PANEL_SIMPLE relies upon the dependency
on the menu.
We do not need to use explicit dependencies if we make the menu depend
on DRM_PANEL && DRM - this will implicitly make each entry in the menu
depend
On 2014? 06? 02? 01:04, Tobias Jakobi wrote:
> The right-bottom register isn't set correctly.
> Looks like a copy-and-paste error.
Signed-off-by: Inki Dae
Thanks,
Inki Dae
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On 2014? 06? 02? 01:04, Tobias Jakobi wrote:
> The hardware accepts scaling factors formatted in a
> fixed-point format. The current macro casts to integer
> first, then multiplies by the fp conversion factor.
>
> This does not make any sense. In particular, truly
> 'fractional' inputs, like 1.5,
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/ec63a5ee/attachment.html>
so there is no chance to
bisect given how busy I actually am.
--
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/20140613/13f14991/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/218f7eee/attachment.html>
On 09/06/2014 at 18:04:15 +0200, Boris Brezillon wrote :
> The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
> at91sam9x5 family or sama5d3 family) provide a PWM device.
>
> This driver add support for this PWM device.
>
> Signed-off-by: Boris BREZILLON
> ---
> .../devicet
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/6a2dc86d/attachment.html>
5.0-rc8 + PTE patches
--
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/20140613/6b4d0d6c/attachment.html>
Hi Dave,
Just a couple of further improvements for the deep color support.
The following changes since commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-06-11
16:28:10 +1000)
are availa
On Fri, Jun 13, 2014 at 10:34 AM, Pierre Moreau
wrote:
> The specified stride was not correct, resulting in erases overlapping and part
> of the zcull regions being not erased at all.
Hey Pierre,
Thanks, I've merged both patches.
>
> Signed-off-by: Pierre Moreau
> ---
> drivers/gpu/drm/nouvea
Hi Russel,
Thanks for both fixes. Just one nitpick.
On 06/12/2014 06:09 PM, Russell King wrote:
> DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> DRM_PANEL && DRM. This is nonsense for two reasons:
>
> (a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled
>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/567fe628/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140613/2f6a47be/attachment.html>
The blob does not seem to write at that place for my NVAC, though it does for
my NV96, agreeing with what is done in the if/else structure below. I guess
someone forgot to remove the line when the if/else was put in place.
Signed-off-by: Pierre Moreau
---
drivers/gpu/drm/nouveau/core/engine/grap
The specified stride was not correct, resulting in erases overlapping and part
of the zcull regions being not erased at all.
Signed-off-by: Pierre Moreau
---
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
Hi Denis,
Thank you for the patch.
On Tuesday 10 June 2014 12:25:47 Denis Carikli wrote:
> We need a way to pass signal polarity informations
> between DRM panels, and the display drivers.
>
> To do that, a pol_flags field was added to drm_display_mode.
>
> Signed-off-by: Denis Carikli
> ---
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/20140613/c300c9b6/attachment.html>
51 matches
Mail list logo
