ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140825/085f4b80/attachment.html>
Unbinding imx-hdmi or imx-ldb driver triggers a kernel Oops in function
ipu_dp_put() as below.
$ echo 12.hdmi >
/sys/devices/soc0/soc/200.aips-bus/12.hdmi/driver/unbind
[ 66.411700] Console: switching to colour dummy device 80x30
[ 66.432543] drm_kms_helper: drm: unregistered
Unbinding imx-ldb driver on imx6q-sabresd board triggers a kernel Oops
as below.
$ echo 200.aips-bus\:ldb\@020e0008 > unbind
[ 423.031003] Console: switching to colour dummy device 80x30
[ 423.052505] drm_kms_helper: drm: unregistered panic notifier
[ 423.137082] Unable to handle kernel
In my testing of bind/unbind (and insmod/rmmod) on imx-drm drivers,
a couple of kernel Oops are seen. These two patches are trying to
fix them.
Changes since v1:
- Remove function ipu_plane_dpms() completely as suggested by Philipp
Shawn Guo (2):
imx-drm: imx-ldb: fix kernel Oops in
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/8abe07db/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83221
Bug ID: 83221
Summary: laptop hangs after loading nouveau fails,
pm_runtime_work thread dying
Product: Drivers
Version: 2.5
Kernel Version: 3.17-rc1
Hardware: x86-64
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/5389eabb/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/47a6bca3/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/8ca4c418/attachment-0001.html>
vel/attachments/20140825/1606590b/attachment.html>
> r100 init hangs in a different place. Original dmesg first, then my
> instrumented dmesg (seems to get further):
The instrumented dmesg had a couple of my local test changes and was
bad now that I had ROM. Reverted them exept my readb changes (instead
of direct dereferences of iomapped
https://bugzilla.kernel.org/show_bug.cgi?id=83201
--- Comment #1 from Ted Percival ---
Earlier in the log I see a machine check exception
[ 300.954634] mce: [Hardware Error]: Machine check events logged
Maybe this is just the result of overheating some hardware?
I didn't see the problem on
https://bugzilla.kernel.org/show_bug.cgi?id=83201
Bug ID: 83201
Summary: CPU soft lockups in nouveau under load
Product: Drivers
Version: 2.5
Kernel Version: 3.17.0-rc1-00231-g7be141d
Hardware: x86-64
OS: Linux
On Sat, Aug 23, 2014 at 06:09:56PM +0200, Julia Lawall wrote:
> From: Julia Lawall
>
> Use c99 initializers for structures.
>
> Drop 0 initializers in drivers/gpu/drm/sti/sti_vtac.c. A 0x0 initializer
> is left in vtac_mode_aux in drivers/gpu/drm/sti/sti_vtac.c to highlight the
> relation to
On Mon, Aug 18, 2014 at 03:35:16PM -0700, Derek wrote:
> Hi every one
> I'm currently working on VirtualMonitor in my leisure time. It allows you
> to use compute/tablet/smartphone as a second monitor for your primary
> computer. please refer to http://virtualmonitor.github.io for more
>
On Mon, Aug 18, 2014 at 02:02:14PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be 720 horizontal pixel and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel
On Sat, Aug 16, 2014 at 02:15:34PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix drm kernel-doc notation to squelch these warnings:
>
> Warning(..//include/drm/drm_modeset_lock.h:41): cannot understand function
> prototype: 'struct drm_modeset_acquire_ctx '
>
On Tue, Aug 19, 2014 at 08:12:06AM +, Jindal, Sonika wrote:
> Hi,
>
> Did anybody get a chance to review other patches in this series?
> I got r-b for 2 patches (patches with changes in drm and i915) from Damien.
It helps if you cc the relevant driver maintainers on patch submissions.
This is a port of cedb655a3a7764c3fd946077944383c9e0e68dd4
to older asics. Fixes a possible divide by 0 if the harvest
register is invalid.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/r600.c | 8
drivers/gpu/drm/radeon/rv770.c | 8
2
On Thu, Aug 21, 2014 at 03:16:08PM +0200, Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 03:06:00PM +0200, Boris BREZILLON wrote:
> > On Thu, 21 Aug 2014 11:52:03 +0200
> > Thierry Reding wrote:
> >
> > > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> > > > On Thu, 21 Aug
Hi Daniel,
On Mon, 25 Aug 2014 14:16:02 +0200 Daniel Vetter wrote:
> Very often when something goes wrong with a kms driver we hang while doing
> the initial modeset. Which is all done while holding the console_lock
> (because fbdev+vt locking is just insane). You can try to get a closer
> look
On Fri, Aug 22, 2014 at 08:23:24AM +0200, Bruno Pr?mont wrote:
> On Thu, 21 Aug 2014 23:39:31 -0500 Bjorn Helgaas wrote:
> > On Thu, Aug 21, 2014 at 4:34 PM, Bruno Pr?mont wrote:
> >
> > > A second step would then be to tune vgaarb's initial selection.
> > > Bjorn, is it possible to verify which
On Sun, 24 Aug 2014, Piotr Kr?l wrote:
> Hi all,
> according to you request I would like to report that my Lenovo IdeaPad
> y510p requires i915.invert_brightness=1 parameter to not dim screen
> right after booting. I'm using 3.17.0-rc1.
This is highly unlikely to be the case on your hardware.
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/b3a07140/attachment.html>
|--- |FIXED
--
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/20140825/6aac4e98/attachment-0001.html>
On Sun, Aug 24, 2014 at 9:14 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> v2: only necessary on RS[78]80
>
> Signed-off-by: Christian K?nig
Series applied to my 3.18 tree.
Thanks,
Alex
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 9 ++---
> 1 file changed, 6 insertions(+), 3
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140825/f7796608/attachment.html>
Hello Ajay,
On Mon, Aug 25, 2014 at 8:11 AM, Ajay kumar wrote:
>>
>> Do you plan to address Thierry's concerns and re-spin this patch?
>>
>> Same question for patches:
>>
>> "drm/bridge: Add i2c based driver for ptn3460 bridge"
>> "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge"
>
e.
>
> Just my random thoughts, probably good to kickstart the discussion with
> some quick patches and chat with people on #dri-devel on freenode irc.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/7fba0a62/attachment-0001.html>
On Fri, Aug 22, 2014 at 4:13 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This allows us to more fine grained specify where to place the buffer object.
>
> Signed-off-by: Christian K?nig
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/ast/ast_drv.h |
On Fri, Aug 22, 2014 at 8:30 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> llocating memory for UVD create and destroy messages can fail, which is
> rather annoying when this happens in the middle of a GPU reset. Try to
> avoid this condition by preallocating a page for those dummy
Hi Javier,
On Sat, Aug 23, 2014 at 5:03 AM, Javier Martinez Canillas
wrote:
> Hello Ajay,
>
> On Thu, Jul 31, 2014 at 12:58 PM, Thierry Reding
> wrote:
>> On Wed, Jul 30, 2014 at 09:33:28PM +0530, Ajay kumar wrote:
>>> On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding >> gmail.com> wrote:
>>
On Sun, Aug 24, 2014 at 8:54 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Otherwise we won't test if the fallback to PCIe GART really worked.
>
> Signed-off-by: Christian K?nig
Applied to my 3.18 tree.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 8
> 1 file
On 24.08.2014 06:11, Alec Ari wrote:
> Based against 3.17-rc1
>
> Makes POWER_SUPPLY HWMON and BACKLIGHT_CLASS_DEVICE optional
Please send a patch generated by git format-patch, preferably sent by
git sen-email.
> @@ -653,9 +655,11 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
>
ts.freedesktop.org
> <mailto:dri-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/6fdb6524/attachment-0001.html>
On 24.08.2014 21:54, Christian K?nig wrote:
> From: Christian K?nig
>
> Otherwise we won't test if the fallback to PCIe GART really worked.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer| http://www.amd.com
Libre
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #19 from Michel D?nzer ---
Does a 3.17 based drm-fixes kernel tree work better? There have been a couple
of stability fixes.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 08/25/2014 06:02 AM, Daniel Vetter wrote:
> On Mon, Aug 18, 2014 at 02:02:14PM -0700, clinton.a.taylor at intel.com wrote:
>> From: Clint Taylor
>>
>> Pixel replicated modes should be 720 horizontal pixel and pixel
>> replicated by the HW across the HDMI cable at 2X pixel clock. Current
>>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/6b032059/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/20140825/897bd168/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/476176b2/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/8b07ab9e/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/ca281a24/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/a2c63d2f/attachment.html>
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140825/3c18e574/attachment-0001.html>
if it's NOT useful :)
--
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/20140825/2ad6869d/attachment.html>
for r600_dri.so) should be a good start to
identify where the leaks are coming from.
--
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/20140
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140825/1285e822/attachment.html>
Already declared in our public header freedreno_drmif.h
Cc: Rob Clark
Cc: freedreno at lists.freedesktop.org
Signed-off-by: Emil Velikov
---
freedreno/freedreno_priv.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/freedreno/freedreno_priv.h b/freedreno/freedreno_priv.h
index
This patch works on my hardware. Xorg starts up fine with fbdev now.
Thanks for the fix!
--G?nther
Daniel Kurtz writes:
> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
> the fbdev.
>
> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
> drm/exynos/fbdev: don't set
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
---
No
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above change represents a regression as
code in efifb did forcefully override vga_default_device while the
merge did not (vgaarb happens prior to PCI fixup).
To
52 matches
Mail list logo
