On Fri, 2014-06-06 at 21:31 +1000, Benjamin Herrenschmidt wrote:
> The spec is pretty tricky to read but seems to indicate that the above
> offset should also work for PIO if needed, however, it seems like the
> X driver is pretty happy to use MMIO unconditionally for them.
>
> Any objection on m
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/7921b7bf/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/bb79c49a/attachment.html>
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: stable at v
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: stable at vger.kernel.org
---
drivers/gpu/drm/tilcdc/t
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
On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:
> IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO
> use the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42,
> can it be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
>
> On my AST2400 at lea
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140607/e81f1b10/attachment.html>
mieq is *NOT* the cause. It is a victim.
--
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/20140607/6a94a6bd/attachment-0001.html>
The acquire ctx will typically be declared on the stack, which means we
could have garbage values for any uninitialized field. In this case, it
was triggering WARN_ON()s because 'contended' had garbage value.
Go ahead and use memset() to be more future-proof.
Reported-by: Ville Syrj?l?
Signed-o
On Sat, Jun 07, 2014 at 08:29:13AM -0400, Rob Clark wrote:
> The acquire ctx will typically be declared on the stack, which means we
> could have garbage values for any uninitialized field. In this case, it
> was triggering WARN_ON()s because 'contended' had garbage value.
>
> Go ahead and use me
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/535cae18/attachment.html>
The acquire ctx will typically be declared on the stack, which means we
could have garbage values for any uninitialized field. In this case, it
was triggering WARN_ON()s because 'contended' had garbage value.
Go ahead and use memset() to be more future-proof.
v2: now with extra brown paper bag
|--- |NOTABUG
--
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/20140607/02e0e0df/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/35929d9d/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/5aa3acc4/attachment.html>
is 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/20140607/1995707f/attachment-0001.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/20140607/0a55006d/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/27847834/attachment.html>
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/8d6dbf48/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/20140607/5d9be8d4/attachment.html>
This fixes hangs on GK208 which happen instantaneously on trying to use a
geometry shader.
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org # v3.14+
---
ctxnvf0 also writes to these registers (although slightly diff values), so I
think this is right. So I guess trap 4 is whatever this 40
t; off" instead of "any_state -> on".
--
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/20140607/0cd89ede/attachment.html>
Signed-off-by: Ilia Mirkin
---
MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b
MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03
MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c
MMIO32 W 0x17e920 0x00090d08 PM
https://bugzilla.kernel.org/show_bug.cgi?id=77471
Bug ID: 77471
Summary: VESA VGA to radeondri handoff results in boot hang
Product: Drivers
Version: 2.5
Kernel Version: 3.15-rc8
Hardware: x86-64
OS: Linux
Tre
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #1 from joshua.r.marshall.1991 at gmail.com ---
My distro kernel version is at 3.14.5
--
You are receiving this mail because:
You are watching the assignee of the bug.
From: Ken Helias
All other add functions for lists have the new item as first argument and the
position where it is added as second argument. This was changed for no good
reason in this function and makes using it unnecessary confusing.
The name was changed to let old code generate a compile err
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140607/91241d7d/attachment.html>
35 matches
Mail list logo
