[Bug 96239] [radeonsi tessellation] Random "texture flickering" (Shadow of Mordor, Tomb Raider, Unigine Heaven 4.0)
https://bugs.freedesktop.org/show_bug.cgi?id=96239 --- Comment #4 from Bas Nieuwenhuizen --- Created attachment 124151 --> https://bugs.freedesktop.org/attachment.cgi?id=124151&action=edit ci-64-tess-blocks.patch Does the attached patch help? If not I would appreciate it if someone could find the first commit that fails (using e.g. bisect). Also, I noticed all reporters use hawaii/grenada pro chips. If anyone with a different chip also has this issue, please let me know. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/4d545930/attachment.html>
[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?
Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. Cheers, -ilia On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski wrote: > I have the signed firmware (I think) and I'm running a fresh 4.6 > kernel. I got an image to show up briefly, rendering the Fedora > sign-in screen at something like one frame per ten seconds. But then > I got all kinds of garbage, and I see: > > [ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link > training failed > > dmesg |grep nouveau says: > > [ 10.053162] fb: switching to nouveaufb from EFI VGA > [ 10.053349] nouveau :09:00.0: NVIDIA GM206 (126010a1) > [ 10.174033] nouveau :09:00.0: bios: version 84.06.0d.00.01 > [ 10.174854] nouveau :09:00.0: disp: dcb 15 type 8 unknown > [ 10.178375] nouveau :09:00.0: fb: 2048 MiB GDDR5 > [ 10.202108] nouveau :09:00.0: DRM: VRAM: 2048 MiB > [ 10.202109] nouveau :09:00.0: DRM: GART: 1048576 MiB > [ 10.202113] nouveau :09:00.0: DRM: TMDS table version 2.0 > [ 10.202114] nouveau :09:00.0: DRM: DCB version 4.1 > [ 10.202116] nouveau :09:00.0: DRM: DCB outp 00: 01000f02 00020030 > [ 10.202117] nouveau :09:00.0: DRM: DCB outp 01: 02000f00 > [ 10.202118] nouveau :09:00.0: DRM: DCB outp 02: 02811f76 04400020 > [ 10.202120] nouveau :09:00.0: DRM: DCB outp 03: 02011f72 00020020 > [ 10.202121] nouveau :09:00.0: DRM: DCB outp 04: 04822f86 04400010 > [ 10.202122] nouveau :09:00.0: DRM: DCB outp 05: 04022f82 00020010 > [ 10.202123] nouveau :09:00.0: DRM: DCB outp 06: 04833f96 04400020 > [ 10.202124] nouveau :09:00.0: DRM: DCB outp 07: 04033f92 00020020 > [ 10.202125] nouveau :09:00.0: DRM: DCB outp 08: 02044f62 00020010 > [ 10.202126] nouveau :09:00.0: DRM: DCB outp 15: 01df5ff8 > [ 10.202127] nouveau :09:00.0: DRM: DCB conn 00: 1030 > [ 10.202128] nouveau :09:00.0: DRM: DCB conn 01: 00020146 > [ 10.202129] nouveau :09:00.0: DRM: DCB conn 02: 01000246 > [ 10.202130] nouveau :09:00.0: DRM: DCB conn 03: 02000346 > [ 10.202131] nouveau :09:00.0: DRM: DCB conn 04: 00010461 > [ 10.202132] nouveau :09:00.0: DRM: DCB conn 05: 0570 > [ 10.202134] nouveau :09:00.0: DRM: Pointer to flat panel table invalid > [ 10.214683] nouveau :09:00.0: DRM: unknown connector type 70 > [ 10.214728] nouveau :09:00.0: DRM: failed to create encoder 1/8/0: -19 > [ 10.214730] nouveau :09:00.0: DRM: Unknown-1 has no encoders, removing > [ 10.369691] nouveau :09:00.0: DRM: MM: using COPY for buffer copies > [ 10.478561] nouveau :09:00.0: priv: GPC0: 419df4 (1e40820e) > [ 10.478578] nouveau :09:00.0: priv: GPC1: 419df4 (1e40820e) > [ 10.607100] nouveau :09:00.0: DRM: allocated 3840x2160 fb: > 0x6, bo 88044aad7400 > [ 10.607276] fbcon: nouveaufb (fb0) is primary device > [ 10.607576] nouveau :09:00.0: fb0: nouveaufb frame buffer device > [ 10.617064] [drm] Initialized nouveau 1.3.1 20120801 for > :09:00.0 on minor 0 > [ 719.282184] nouveau :09:00.0: disp: outp 04:0006:0f44: link > training failed > [ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link > training failed > > > > Thanks, > Andy > ___ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau
4.7-rc0: redshift stopped working on intel display
On Sat 2016-05-28 12:12:06, Pavel Machek wrote: > Hi! > > It looks like redshift stopped working. Even pretty crazy settings > have no visible effect: > > pavel at amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 > Using method `randr'. > pavel at amd:~$ redshift -x > Using method `randr'. > pavel at amd:~$ uname -a > Linux amd 4.6.0 #47 SMP Fri May 27 12:07:10 CEST 2016 x86_64 GNU/Linux > pavel at amd:~$ redshift -O 5500 -g 6.6:6.6:6.6 > Using method `randr'. > pavel at amd:~$ redshift -O 5500 -g 6.6:6.6:6.6 -b .3 > Using method `randr'. > pavel at amd:~$ > pavel at amd:~$ lspci | grep VGA > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > Integrated Graphics Controller (rev 03) > pavel at amd:~$ suspend-to-ram + resume cycle updates the display to match the settings. Not convenient, but... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
https://bugzilla.kernel.org/show_bug.cgi?id=88861 --- Comment #24 from Wilfried Klaebe --- Oops, fixed (and double-checked) that email issue. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 96239] [radeonsi tessellation] Random "texture flickering" (Shadow of Mordor, Tomb Raider, Unigine Heaven 4.0)
https://bugs.freedesktop.org/show_bug.cgi?id=96239 --- Comment #3 from Clésio Luiz --- This affect me too, in a R9 290, radeonsi driver, using padoka PPA with Kubuntu 16.04. When you disable tesselation in those games the problem goes away. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/797b91e0/attachment.html>
[Bug 95072] [wine] Rendering bug in GTA IV
https://bugs.freedesktop.org/show_bug.cgi?id=95072 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sven Arvidsson --- Seems to be working fine with current git master and llvm 3.8. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/9f0ea386/attachment.html>
[PATCH v2 2/2] drm/amdkfd: destroy dbgmgr in notifier release
amdkfd need to destroy the debug manager in case amdkfd's notifier
function is called before the unbind function, because in that case,
the unbind function will exit without destroying debug manager.
Signed-off-by: Oded Gabbay
CC: Stable
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a64bc61..7708d90 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -242,13 +242,19 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
pqm_uninit(&p->pqm);
/* Iterate over all process device data structure and check
-* if we should reset all wavefronts */
- list_for_each_entry(pdd, &p->per_device_data, per_device_list)
+* if we should delete debug managers and reset all wavefronts
+*/
+ list_for_each_entry(pdd, &p->per_device_data, per_device_list) {
+ if ((pdd->dev->dbgmgr) &&
+ (pdd->dev->dbgmgr->pasid == p->pasid))
+ kfd_dbgmgr_destroy(pdd->dev->dbgmgr);
+
if (pdd->reset_wavefronts) {
pr_warn("amdkfd: Resetting all wave fronts\n");
dbgdev_wave_reset_wavefronts(pdd->dev, p);
pdd->reset_wavefronts = false;
}
+ }
mutex_unlock(&p->mutex);
--
2.5.5
[PATCH v2 1/2] drm/amdkfd: unbind only existing processes
When unbinding a process from a device (initiated by amd_iommu_v2), the
driver needs to make sure that process still exists in the process table.
There is a possibility that amdkfd's own notifier handler -
kfd_process_notifier_release() - was called before the unbind function
and it already removed the process from the process table.
v2:
Because there can be only one process with the specified pasid, and
because *p can't be NULL inside the hash_for_each_rcu macro, it is more
reasonable to just put the whole code inside the if statement that
compares the pasid value. That way, when we exit hash_for_each_rcu, we
simply exit the function as well.
Signed-off-by: Oded Gabbay
CC: Stable
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 60 +++-
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index ac00579..a64bc61 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -404,42 +404,52 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev,
unsigned int pasid)
idx = srcu_read_lock(&kfd_processes_srcu);
+ /*
+* Look for the process that matches the pasid. If there is no such
+* process, we either released it in amdkfd's own notifier, or there
+* is a bug. Unfortunately, there is no way to tell...
+*/
hash_for_each_rcu(kfd_processes_table, i, p, kfd_processes)
- if (p->pasid == pasid)
- break;
+ if (p->pasid == pasid) {
- srcu_read_unlock(&kfd_processes_srcu, idx);
+ srcu_read_unlock(&kfd_processes_srcu, idx);
- BUG_ON(p->pasid != pasid);
+ pr_debug("Unbinding process %d from IOMMU\n", pasid);
- mutex_lock(&p->mutex);
+ mutex_lock(&p->mutex);
- if ((dev->dbgmgr) && (dev->dbgmgr->pasid == p->pasid))
- kfd_dbgmgr_destroy(dev->dbgmgr);
+ if ((dev->dbgmgr) && (dev->dbgmgr->pasid == p->pasid))
+ kfd_dbgmgr_destroy(dev->dbgmgr);
- pqm_uninit(&p->pqm);
+ pqm_uninit(&p->pqm);
- pdd = kfd_get_process_device_data(dev, p);
+ pdd = kfd_get_process_device_data(dev, p);
- if (!pdd) {
- mutex_unlock(&p->mutex);
- return;
- }
+ if (!pdd) {
+ mutex_unlock(&p->mutex);
+ return;
+ }
- if (pdd->reset_wavefronts) {
- dbgdev_wave_reset_wavefronts(pdd->dev, p);
- pdd->reset_wavefronts = false;
- }
+ if (pdd->reset_wavefronts) {
+ dbgdev_wave_reset_wavefronts(pdd->dev, p);
+ pdd->reset_wavefronts = false;
+ }
- /*
-* Just mark pdd as unbound, because we still need it to call
-* amd_iommu_unbind_pasid() in when the process exits.
-* We don't call amd_iommu_unbind_pasid() here
-* because the IOMMU called us.
-*/
- pdd->bound = false;
+ /*
+* Just mark pdd as unbound, because we still need it
+* to call amd_iommu_unbind_pasid() in when the
+* process exits.
+* We don't call amd_iommu_unbind_pasid() here
+* because the IOMMU called us.
+*/
+ pdd->bound = false;
- mutex_unlock(&p->mutex);
+ mutex_unlock(&p->mutex);
+
+ return;
+ }
+
+ srcu_read_unlock(&kfd_processes_srcu, idx);
}
struct kfd_process_device *kfd_get_first_process_device_data(struct
kfd_process *p)
--
2.5.5
[Bug 96239] [radeonsi tessellation] Random "texture flickering" (Shadow of Mordor, Tomb Raider, Unigine Heaven 4.0)
https://bugs.freedesktop.org/show_bug.cgi?id=96239 prazola changed: What|Removed |Added Summary|[radeonsi tessellation] |[radeonsi tessellation] |Random "texture flickering" |Random "texture flickering" |(Shadow of Mordor, Tomb |(Shadow of Mordor, Tomb |Raider) |Raider, Unigine Heaven 4.0) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/ed66ce51/attachment-0001.html>
[Bug 96239] [radeonsi tessellation] Random "texture flickering" (Shadow of Mordor, Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=96239 --- Comment #2 from prazola --- I confirm the bug. It affects tessellation on heaven benchmark 4.0. r9 390. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/934ef1b6/attachment.html>
[Bug 96239] [radeonsi tessellation] Random "texture flickering" (Shadow of Mordor, Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=96239 Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed: What|Removed |Added Attachment #124124|Screenshot |Shadow of Mordor screenshot description|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160528/63e43527/attachment.html>
is there a reason for include/uapi/drm to contain files not in Kbuild?
just noticed that, in include/uapi/drm/, there are three header files: * armada_drm.h * etnaviv_drm.h * omap_drm.h that are not referenced in the corresponding Kbuild file. is there any rationale for this? in general, is there *any* reason for header files under include/uapi/ to not be mentioned in their respective Kbuild files? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[Nouveau] [PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
Hi Peter,
On Fri, May 27, 2016 at 11:31:23PM +0200, Peter Wu wrote:
> On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote:
> > On 24 May 2016 at 23:53, Peter Wu wrote:
[snip]
> > > @@ -273,14 +296,14 @@ static bool nouveau_dsm_detect(void)
> > > vga_count++;
> > >
> > > nouveau_dsm_pci_probe(pdev, &has_mux, &has_optimus,
> > > - &has_optimus_flags);
> > > + &has_optimus_flags,
> > > &has_power_resources);
> > > }
> > >
> > > while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_3D << 8, pdev)) !=
> > > NULL) {
> > > vga_count++;
> > >
> > > nouveau_dsm_pci_probe(pdev, &has_mux, &has_optimus,
> > > - &has_optimus_flags);
> > > + &has_optimus_flags,
> > > &has_power_resources);
> > > }
> > >
> > This and earlier patch break things in a subtle way.
> >
> > Namely: upon the second (and any later) call into the
> > nouveau_dsm_pci_probe() function, the had_foo flags are reset. Thus
> > only the specifics of the _final_ device are being used (at a later
> > stage). IMHO one should change that to "_any_ device", which will
> > match the original code and the actual intent further down in the
> > file.
>
> The flags are only reset if any of the MUX or Optimus handles are found.
> If both are missing, the flags are not overridden. This is from patch 1:
>
> + /* Does not look like a Nvidia device. */
> + if (!supports_mux && !supports_opt)
> + return;
>
> The reason why later calls override early ones is because some Optimus
> laptops have the _DSM method on both the Intel GPU (00:02.0) and the
> Nvidia one (01:00.0).
Sounds like you may want to check for pdev->vendor == PCI_VENDOR_ID_NVIDIA
or export pci_get_dev_by_id() and use that to match for class and vendor.
Best regards,
Lukas
Should I expect nouveau on 4.6 to work on a GM206?
I have the signed firmware (I think) and I'm running a fresh 4.6 kernel. I got an image to show up briefly, rendering the Fedora sign-in screen at something like one frame per ten seconds. But then I got all kinds of garbage, and I see: [ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link training failed dmesg |grep nouveau says: [ 10.053162] fb: switching to nouveaufb from EFI VGA [ 10.053349] nouveau :09:00.0: NVIDIA GM206 (126010a1) [ 10.174033] nouveau :09:00.0: bios: version 84.06.0d.00.01 [ 10.174854] nouveau :09:00.0: disp: dcb 15 type 8 unknown [ 10.178375] nouveau :09:00.0: fb: 2048 MiB GDDR5 [ 10.202108] nouveau :09:00.0: DRM: VRAM: 2048 MiB [ 10.202109] nouveau :09:00.0: DRM: GART: 1048576 MiB [ 10.202113] nouveau :09:00.0: DRM: TMDS table version 2.0 [ 10.202114] nouveau :09:00.0: DRM: DCB version 4.1 [ 10.202116] nouveau :09:00.0: DRM: DCB outp 00: 01000f02 00020030 [ 10.202117] nouveau :09:00.0: DRM: DCB outp 01: 02000f00 [ 10.202118] nouveau :09:00.0: DRM: DCB outp 02: 02811f76 04400020 [ 10.202120] nouveau :09:00.0: DRM: DCB outp 03: 02011f72 00020020 [ 10.202121] nouveau :09:00.0: DRM: DCB outp 04: 04822f86 04400010 [ 10.202122] nouveau :09:00.0: DRM: DCB outp 05: 04022f82 00020010 [ 10.202123] nouveau :09:00.0: DRM: DCB outp 06: 04833f96 04400020 [ 10.202124] nouveau :09:00.0: DRM: DCB outp 07: 04033f92 00020020 [ 10.202125] nouveau :09:00.0: DRM: DCB outp 08: 02044f62 00020010 [ 10.202126] nouveau :09:00.0: DRM: DCB outp 15: 01df5ff8 [ 10.202127] nouveau :09:00.0: DRM: DCB conn 00: 1030 [ 10.202128] nouveau :09:00.0: DRM: DCB conn 01: 00020146 [ 10.202129] nouveau :09:00.0: DRM: DCB conn 02: 01000246 [ 10.202130] nouveau :09:00.0: DRM: DCB conn 03: 02000346 [ 10.202131] nouveau :09:00.0: DRM: DCB conn 04: 00010461 [ 10.202132] nouveau :09:00.0: DRM: DCB conn 05: 0570 [ 10.202134] nouveau :09:00.0: DRM: Pointer to flat panel table invalid [ 10.214683] nouveau :09:00.0: DRM: unknown connector type 70 [ 10.214728] nouveau :09:00.0: DRM: failed to create encoder 1/8/0: -19 [ 10.214730] nouveau :09:00.0: DRM: Unknown-1 has no encoders, removing [ 10.369691] nouveau :09:00.0: DRM: MM: using COPY for buffer copies [ 10.478561] nouveau :09:00.0: priv: GPC0: 419df4 (1e40820e) [ 10.478578] nouveau :09:00.0: priv: GPC1: 419df4 (1e40820e) [ 10.607100] nouveau :09:00.0: DRM: allocated 3840x2160 fb: 0x6, bo 88044aad7400 [ 10.607276] fbcon: nouveaufb (fb0) is primary device [ 10.607576] nouveau :09:00.0: fb0: nouveaufb frame buffer device [ 10.617064] [drm] Initialized nouveau 1.3.1 20120801 for :09:00.0 on minor 0 [ 719.282184] nouveau :09:00.0: disp: outp 04:0006:0f44: link training failed [ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link training failed Thanks, Andy
4.7-rc0: redshift stopped working on intel display
Hi! It looks like redshift stopped working. Even pretty crazy settings have no visible effect: pavel at amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 Using method `randr'. pavel at amd:~$ redshift -x Using method `randr'. pavel at amd:~$ uname -a Linux amd 4.6.0 #47 SMP Fri May 27 12:07:10 CEST 2016 x86_64 GNU/Linux pavel at amd:~$ redshift -O 5500 -g 6.6:6.6:6.6 Using method `randr'. pavel at amd:~$ redshift -O 5500 -g 6.6:6.6:6.6 -b .3 Using method `randr'. pavel at amd:~$ pavel at amd:~$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) pavel at amd:~$ Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
https://bugzilla.kernel.org/show_bug.cgi?id=88861 --- Comment #23 from Lukas Wunner --- I've e-mailed Bruno Prémont, author of 4eebd5a4e7269, and cc'ed platform-driver-x86: http://www.spinics.net/lists/platform-driver-x86/msg08889.html I've also cc'ed you but your e-mail address isn't working, please fix: : host mail.lebenslange-mailadresse.de[217.70.197.123] said: 550 Unrouteable address (in reply to RCPT TO command) -- You are receiving this mail because: You are the assignee for the bug.
[PATCH] fbcon: warn on invalid cursor blink intervals
On Fri, 20 May 2016, Scot Doyle wrote: > On Fri, 20 May 2016, Jeremy Kerr wrote: > > >Then looks there are two fix patches acked & tested: > > > > > > - the patch in this thread > > > - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor > > >blink timer." > > > https://lkml.org/lkml/2016/5/17/455 > > > > > >So which one will be pushed to linus? > > > > Not that it's my call, but we may want both; the first as a safety > > measure to prevent an invalid cur_blink_jiffies ever being set, and the > > second one to actually fix the initialisation of vc_cur_blink_ms (and > > address the warning introduced by the first). > > Tomi / Greg, > > I'd suggest > - applying "tty: vt: Fix soft lockup in fbcon cursor blink timer." to 4.7 and > stable[4.2] > - applying "fbcon: warn on invalid cursor blink intervals" to 4.7 > - ignoring "fbcon: use default if cursor blink interval is not valid" > > Note: the patches don't depend on each other I applied both recommended patches on top of 4.4.11 for testing, and they made things a lot better here. I suggest the second patch should be backported to stable too, might as well fix this thing for good *and keep the door closed*. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH] fbcon: warn on invalid cursor blink intervals
On Thu, 19 May 2016, Scot Doyle wrote: > Two systems are locking on boot [1] because ops->cur_blink_jiffies > is set to zero from vc->vc_cur_blink_ms. > > Ignore such invalid intervals and log a warning. > > [1] https://bugs.launchpad.net/bugs/1574814 > > Suggested-by: David Daney > Signed-off-by: Scot Doyle > Cc: [v4.2] FWIW: Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. And nothing caused it to issue warnings here, so far (with the other recommended patch applied first). > --- > drivers/video/console/fbcon.c | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index 6e92917..fad5b89 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -1095,7 +1095,13 @@ static void fbcon_init(struct vc_data *vc, int init) > con_copy_unimap(vc, svc); > > ops = info->fbcon_par; > - ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); > + > + if (vc->vc_cur_blink_ms >= 50) > + ops->cur_blink_jiffies = > + msecs_to_jiffies(vc->vc_cur_blink_ms); > + else > + WARN_ONCE(1, "blink interval < 50 ms"); > + > p->con_rotate = initial_rotation; > set_blitting_type(vc, info); > > @@ -1309,7 +1315,11 @@ static void fbcon_cursor(struct vc_data *vc, int mode) > int y; > int c = scr_readw((u16 *) vc->vc_pos); > > - ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); > + if (vc->vc_cur_blink_ms >= 50) > + ops->cur_blink_jiffies = > + msecs_to_jiffies(vc->vc_cur_blink_ms); > + else > + WARN_ONCE(1, "blink interval < 50 ms"); > > if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1) > return; -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.
On Tue, 17 May 2016, David Daney wrote: > From: David Daney > We are getting somewhat random soft lockups with this signature: > > [ 86.992215] [] el1_irq+0xa0/0x10c > [ 86.997082] [] cursor_timer_handler+0x30/0x54 > [ 87.002991] [] call_timer_fn+0x54/0x1a8 > [ 87.008378] [] run_timer_softirq+0x1c4/0x2bc > [ 87.014200] [] __do_softirq+0x114/0x344 > [ 87.019590] [] irq_exit+0x74/0x98 > [ 87.024458] [] __handle_domain_irq+0x98/0xfc > [ 87.030278] [] gic_handle_irq+0x94/0x190 > > This is caused by the vt visual_init() function calling into > fbcon_init() with a vc_cur_blink_ms value of zero. This is a > transient condition, as it is later set to a non-zero value. But, if > the timer happens to expire while the blink rate is zero, it goes into > an endless loop, and we get soft lockup. > > The fix is to initialize vc_cur_blink_ms before calling the con_init() > function. > > Signed-off-by: David Daney > Cc: stable at vger.kernel.org Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. > --- > drivers/tty/vt/vt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 3e3c757..eef5c36 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -750,6 +750,7 @@ static void visual_init(struct vc_data *vc, int num, int > init) > vc->vc_complement_mask = 0; > vc->vc_can_do_color = 0; > vc->vc_panic_force_write = false; > + vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS; > vc->vc_sw->con_init(vc, init); > if (!vc->vc_complement_mask) > vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800; -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH 4/4] rcar-du: add R8A7794 TCON support
Hi Sergei,
Thank you for the patch.
On Friday 29 Apr 2016 00:05:33 Sergei Shtylyov wrote:
> Now that we have the TCON encoder driver, we can start enabling TCON support
> for the R-Car SoCs. We have only tested the code on R8A7794 so far, so
> let it be the first supported SoC...
Please also update the DT bindings.
> Based on a large patch by Andrey Gusakov.
>
> Signed-off-by: Andrey Gusakov
> Signed-off-by: Sergei Shtylyov
>
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> Index: renesas/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> ===
> --- renesas.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ renesas/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -116,9 +116,7 @@ static const struct rcar_du_device_info
>
> | RCAR_DU_FEATURE_EXT_CTRL_REGS,
>
> .num_crtcs = 2,
> .routes = {
> - /* R8A7794 has two RGB outputs and one (currently unsupported)
> - * TCON output.
> - */
> + /* R8A7794 has two RGB outputs and one TCON output. */
> [RCAR_DU_OUTPUT_DPAD0] = {
> .possible_crtcs = BIT(0),
> .encoder_type = DRM_MODE_ENCODER_NONE,
> @@ -129,8 +127,14 @@ static const struct rcar_du_device_info
> .encoder_type = DRM_MODE_ENCODER_NONE,
> .port = 1,
> },
> + [RCAR_DU_OUTPUT_TCON] = {
> + .possible_crtcs = BIT(0),
According to the datasheet TCON can be connected to both DU0 and DU1.
> + .encoder_type = DRM_MODE_ENCODER_TCON,
> + .port = 2,
> + },
> },
> .num_lvds = 0,
> + .num_tcon = 1,
> };
>
> static const struct rcar_du_device_info rcar_du_r8a7795_info = {
--
Regards,
Laurent Pinchart
[PATCH 2/4] rcar-du: add TCON encoder driver
Hi Sergei,
Thank you for the patch.
On Friday 29 Apr 2016 00:03:29 Sergei Shtylyov wrote:
> Renesas R-Car SoCs include the timing controller (TCON) that can directly
> drive LCDs. It receives the H/VSYNC, etc. from the Display Unit (DU) and
> converts them to the set of signals that a LCD panel can understand (the
> RBG signals are effectively passed thru). TCON has a set of registers
> that we need to program based on the video mode timings, so we're adding
> a DU encoder driver doing that...
>
> Based on a large patch by Andrey Gusakov.
>
> Signed-off-by: Andrey Gusakov
> Signed-off-by: Sergei Shtylyov
>
> ---
> drivers/gpu/drm/rcar-du/Kconfig |6
> drivers/gpu/drm/rcar-du/Makefile |1
> drivers/gpu/drm/rcar-du/rcar_du_drv.h |4
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c |9 +
> drivers/gpu/drm/rcar-du/rcar_du_encoder.h |3
> drivers/gpu/drm/rcar-du/rcar_du_kms.c |4
> drivers/gpu/drm/rcar-du/rcar_du_tconenc.c | 184 ++
> drivers/gpu/drm/rcar-du/rcar_du_tconenc.h | 37 ++
> drivers/gpu/drm/rcar-du/rcar_tcon_regs.h | 70 +++
> 9 files changed, 318 insertions(+)
>
> Index: linux/drivers/gpu/drm/rcar-du/Kconfig
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/Kconfig
> +++ linux/drivers/gpu/drm/rcar-du/Kconfig
> @@ -24,6 +24,12 @@ config DRM_RCAR_LVDS
> help
> Enable support for the R-Car Display Unit embedded LVDS encoders.
>
> +config DRM_RCAR_TCON
> + bool "R-Car DU TCON Encoder Support"
> + depends on DRM_RCAR_DU
> + help
> + Enable support for the R-Car Display Unit embedded TCON encoders.
> +
> config DRM_RCAR_VSP
> bool "R-Car DU VSP Compositor Support"
> depends on DRM_RCAR_DU
> Index: linux/drivers/gpu/drm/rcar-du/Makefile
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/Makefile
> +++ linux/drivers/gpu/drm/rcar-du/Makefile
> @@ -10,6 +10,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
> rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI) += rcar_du_hdmicon.o \
> rcar_du_hdmienc.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_lvdsenc.o
> +rcar-du-drm-$(CONFIG_DRM_RCAR_TCON) += rcar_du_tconenc.o
>
> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -59,6 +59,7 @@ struct rcar_du_output_routing {
> * @num_crtcs: total number of CRTCs
> * @routes: array of CRTC to output routes, indexed by output
> (RCAR_DU_OUTPUT_*) * @num_lvds: number of internal LVDS encoders
> + * @num_tcon: number of internal TCON encoders
> */
> struct rcar_du_device_info {
> unsigned int gen;
> @@ -67,11 +68,13 @@ struct rcar_du_device_info {
> unsigned int num_crtcs;
> struct rcar_du_output_routing routes[RCAR_DU_OUTPUT_MAX];
> unsigned int num_lvds;
> + unsigned int num_tcon;
> };
>
> #define RCAR_DU_MAX_CRTCS4
> #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
> #define RCAR_DU_MAX_LVDS 2
> +#define RCAR_DU_MAX_TCON 1
> #define RCAR_DU_MAX_VSPS 4
>
> struct rcar_du_device {
> @@ -99,6 +102,7 @@ struct rcar_du_device {
> unsigned int vspd1_sink;
>
> struct rcar_du_lvdsenc *lvds[RCAR_DU_MAX_LVDS];
> + struct rcar_du_tconenc *tcon[RCAR_DU_MAX_TCON];
>
> struct {
> wait_queue_head_t wait;
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -24,6 +24,7 @@
> #include "rcar_du_kms.h"
> #include "rcar_du_lvdscon.h"
> #include "rcar_du_lvdsenc.h"
> +#include "rcar_du_tconenc.h"
> #include "rcar_du_vgacon.h"
>
> /*
> @@ -48,6 +49,8 @@ static void rcar_du_encoder_disable(stru
>
> if (renc->lvds)
> rcar_du_lvdsenc_enable(renc->lvds, encoder->crtc, false);
> + if (renc->tcon)
> + rcar_du_tconenc_enable(renc->tcon, encoder->crtc, false);
> }
>
> static void rcar_du_encoder_enable(struct drm_encoder *encoder)
> @@ -56,6 +59,8 @@ static void rcar_du_encoder_enable(struc
>
> if (renc->lvds)
> rcar_du_lvdsenc_enable(renc->lvds, encoder->crtc, true);
> + if (renc->tcon)
> + rcar_du_tconenc_enable(renc->tcon, encoder->crtc, true);
> }
>
> static int rcar_du_encoder_atomic_check(struct drm_encoder *encoder,
> @@ -142,6 +147,10 @@ int rcar_du_encoder_init(struct rcar_du_
> renc->lvds = rcdu->lvds[1];
>
