https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #40 from creich ---
oh sry. didn't notice that! i used it without dpm. thanks for the hint :)
--
You are receiving this mail because:
You are watching the assignee of the bug.
ttm_tt_cache_flush's implementation was removed in 2009 by commit
c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since
then.
It has been surviving in the dark for too long now ; give it the mercy
blow.
Signed-off-by: Alexandre Courbot
Reviewed-by: Thierry Reding
Reviewed-by: D
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #5 from Marko Srebre ---
Created attachment 140061
--> https://bugzilla.kernel.org/attachment.cgi?id=140061&action=edit
dmesg output (with enable bapm path)
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #6 from Marko Srebre ---
Thanks Alex. The patch that enables bapm works. Boost state is now active.
Frequency gets boosted in single core workloads.
Are there any plans to make 'bapm' tunable via boot parameters or /sys?
--
You are
From: Michel D?nzer
Fixes a regression in 3.16-rc1 compared to 3.15.
The unbalanced calls would presumably result in the page flip interrupts
never getting disabled once they are enabled.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
1 file changed, 1 insert
From: Michel D?nzer
This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.
drm_vblank_get() is necessary to ensure the DRM vblank counter value is
up to date in drm_send_vblank_event().
Seems to fix weston hangs waiting for page flips to complete.
Signed-off-by: Michel D?nzer
---
driv
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/f698fc55/attachment-0001.sig>
Am 17.06.2014 12:12, schrieb Michel D?nzer:
> From: Michel D?nzer
>
> This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.
>
> drm_vblank_get() is necessary to ensure the DRM vblank counter value is
> up to date in drm_send_vblank_event().
>
> Seems to fix weston hangs waiting for page fl
On 04/10/2014 10:37 PM, Andy Lutomirski wrote:
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be enough for the file
On 09/06/2014 18:04, Boris BREZILLON wrote:
> The Atmel HLCDC (High LCD Controller) IP available on some Atmel SoCs (i.e.
> at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> controller device.
>
> This display controller support at least one primary plane and might
> provide s
'exynos_drm_pdev' was not getting unregistered if platform_driver_register()
failed. Fix the ordering to allow this. This also fixes the below warning by
moving the #endif macro. While at it also fix the ordering in the exit function
so that de-registration happens in opposite order of registration
On Tue, Jun 17, 2014 at 02:09:41PM +0300, Jani Nikula wrote:
>
> Hi Dave -
>
> First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
> fixes from Daniel [1] to avoid hangs and unclaimed register errors on
> module load/reload.
Aside: The vt/vgacon stuff also seems to fix some ra
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/20140617/5418cf20/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/4797f46b/attachment.html>
If init doesn't run then disp->outp might not be initialized, resulting in an
oops.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c
b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
index c41f656abe64..9c38c5e40500 100644
--- a/drivers/gpu/drm/n
U related anyway.
--
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/20140617/089859d1/attachment.html>
On Tue, Jun 17, 2014 at 11:01 PM, Maarten Lankhorst
wrote:
> If init doesn't run then disp->outp might not be initialized, resulting in an
> oops.
This can't actually happen (in the very least, it's not supposed
to)... What makes you think it can?
>
> Signed-off-by: Maarten Lankhorst
> ---
> di
ater commit. I could SysRq -
the log was normal.
--
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/20140617/987281e8/attachment-0001.html>
On Tue, Jun 17, 2014 at 7:41 AM, Christian K?nig
wrote:
> Am 17.06.2014 12:12, schrieb Michel D?nzer:
>
>> From: Michel D?nzer
>>
>> This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.
>>
>> drm_vblank_get() is necessary to ensure the DRM vblank counter value is
>> up to date in drm_sen
The tilcdc driver could be compiled as a module, but was severely broken
and could not be used as such. This patchset attempts to fix the issues
preventing a proper load/unload of the module.
Issues included dangling sysfs nodes, dangling devices, memory leaks and
a double kfree.
It now seems to
Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.
This commit moves the latter so it's done afterwards
Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.
This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:
[ cut here ]
Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.
This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:
tda998x 0-0070: found TDA19988
Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.
This is required for proper unload and re-load of this driver, otherwise
we will get a warning about a duplicate filename in sysfs.
Signed-off-by: Guido Mart?nez
Cc: #v3.9+
---
The driver did not unregister the allocated framebuffer, which caused
memory leaks (and memory manager WARNs) when unloading. Also, the
framebuffer device under /dev still existed after unloading.
Add a call to drm_fbdev_cma_fini when unloading the module to prevent
both issues.
Signed-off-by: Gu
Unregister resources in the correct order on tilcdc_drm_fini, which is
the reverse order they were registered during tilcdc_drm_init.
This also means unregistering the driver before releasing its resources.
Signed-off-by: Guido Mart?nez
Cc: #v3.9+
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 ++
display_timings_release calls kfree on the display_timings object passed
to it. Calling kfree after it is wrong. SLUB debug showed the following
warning:
=
BUG kmalloc-64 (Tainted: GW): Object already
The TI tilcdc driver is designed with a notion of submodules. Currently,
at unload time, these submodules are iterated and destroyed.
Now that the tilcdc remove order is fixed, this can be handled perfectly
by the kernel using the device infrastructure, since each submodule
is a kernel driver itse
Use module_init instead of late_initcall, as is the norm for modular
drivers.
module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
but it does not explain why. Tests show it's working properly with
module_init.
S
I am resending these patches after splitting them into two:
1) to update the IOMMU support
2) to activate the IOMMU
Stephane Viau (2):
drm/msm: update iommu support
drm/msm: activate iommu support
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 28 +++-
drivers/gpu/drm/msm/
Iommu support is slightly modified in order to make sure
that MDP iommu is properly cleaned up if a probe deferral is
requested. Before this change, IOMMU faults would occur if the
probe failed (-EPROBE_DEFER).
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 22 +++
This changes activates the iommu support for MDP5, through the
platform config structure.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp
Hey,
This patch causes a regression on my display-less nvd7.
Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass fixes
boot, and makes things work normally again.
broken dmesg:
[ 40.314470] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch -
Found [Buffer], A
nts/20140617/5d0f9312/attachment-0001.html>
On Sat, Jun 14, 2014 at 6:24 PM, Fabian Frederick wrote:
> use mm.h definition
>
> Cc: David Airlie
> Cc: Rob Clark
> Signed-off-by: Fabian Frederick
Thanks, I've got this queued up
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/462477e3/attachment.html>
ed a couple of bugs in -intel that make things work a lot
> better.
>
> I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
> to add 3 monitor support.
>
> It still generates a fair few i915 state checker backtraces, and some
> of them are fairly hard to
ecker for encoders/connectors with no actual hw backing
> them.
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sent using Postbo
d just tone
> down the state checker for encoders/connectors with no actual hw backing
> them.
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-
lot better,
>
> I've also fixed a couple of bugs in -intel that make things work a lot
> better.
>
> I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
> to add 3 monitor support.
>
> It still generates a fair few i915 state checker backtraces, and som
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/093f4705/attachment.html>
is bug.
First patch failed, gonna try out the second as soon as I start compiling a new
kernel.
--
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-dev
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/b9a2ef19/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/dee2be0b/attachment.html>
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> This binding looks quite anaemic vs.
>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>> would expect that this binding needs all th
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/0af7175f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #7 from Alex Deucher ---
We can probably enable it by default on KV/KB systems at some point. It had
some stability issues on trinity APUs so I disabled it across the board, so it
remains to be seen if there are any problems with newe
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/6358d646/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/082d9e3a/attachment.html>
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/54e4d46a/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/d3e07cd2/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/190997cd/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78111
--- Comment #8 from Alex Deucher ---
Does plugging/unplugging the AC adapter cause any problems with bapm enabled?
The reason it was disabled on TN/RL parts is because there were hangs on some
systems when switching to/from AC power.
--
You are
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/7596c872/attachment.html>
On Mon, Jun 02, 2014 at 08:19:26PM +0200, Bruno Pr?mont wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sys
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/7cbfa723/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/45edf783/attachment.html>
On 06/16/2014 10:02 PM, Stephen Warren wrote:
> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> +
>> +Child device nodes describe the memory settings for different
>> configurations and
>> +clock rates.
>
> How do the child nodes do that? The binding needs to specify the format
> of the child node.
On 06/17/2014 07:15 PM, Stephen Warren wrote:
> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>
>>> This binding looks quite anaemic vs.
>>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.
If connector->dpms is left untouched, it defaults
to DRM_MODE_DPMS_ON (0).
As a result, drm_helper_connector_dpms will exit when
it will be asked to set the state to DRM_MODE_DPMS_ON,
because it is already set.
That issue prevented displays from turning on at boot.
Signed-off-by: Denis Carikli
This patch is a monster, but that's to be expected with MST, I suppose.
:) It has some formatting issues (lines over 80 characters in length)
but that can be cleaned up later (as far as I'm concerned). Otherwise I
don't see anything glaring here, so...
Reviewed-by: Todd Previte
> Dave Airlie
ss concerned about passing O_PATH memfds
around than O_RDONLY memfds.
I have incomplete patches for this stuff. I need to fix them so they work
and get past Al Viro.
--Andy
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/30d2d605/attachment.html>
On 06/16/2014 02:29 PM, Denis Carikli wrote:
[...]
> Which result at the lcd regulator being physically powered on at boot.
> I didn't see that because powering it on at boot is what I want.
I fixed that in imx-drm's parallel-display with another patch I just
sent separately.
Denis.
Hi,
I've been asked to try and get a r600 based (E6460) graphics card
running on a machine powered by a Freescale p4080 (e500 core). I've run
into a bit of a problem.
I have the driver built into the kernel at this point. When I boot the
card is detected and it seems to be finding the fimware
64 matches
Mail list logo
