[PATCH v3 2/3] drm: add fallback default device detection

[Daniel Axtens]

The VGA arbiter selects a default VGA device that is enabled and
reachable via the legacy VGA resources (mem 0xa-0xb, io
0x3b0-0x3bb, io 0x3c0-0x3df, etc).

(As a special case for x86 and IA64, this can be overridden by
EFI.)

If there is no such device, e.g., because there's no enabled VGA
device, the host bridge doesn't support access to those legacy
resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
platform may select an arbitrary device by calling
pci_set_default_display(). powerpc does this, for example.

If there is also no platform hook, there will be no default
device nominated. This is not necessarily what we want.

Add handling for devices that aren't handled by the vga arbiter or
platform by adding a late initcall and a class enable hook. If there
is no default from vgaarb or the platform then the first VGA card
that is enabled, has a driver bound, and can decode memory or I/O
will be marked as default.

This means single-card setups on systems without access to legacy
areas and without arch hooks will work. Multi-card setups on these
systems will nominate an arbitrary device, rather than no devices.

Signed-off-by: Daniel Axtens 

---

v3:

Split out from re-organisation for simplicity.
Add better description and better documentaion.

Thanks to (in no particular order), Daniel Vetter, Lorenzo Pieralisi,
Ard Biesheuvel and Dave Airlie. Special thanks to Ben Herrenschmidt
and Bjorn Helgass, whose prose I have borrowed.

v1:

Tested on:
 - x86_64 laptop
 - arm64 D05 board with hibmc card
 - qemu powerpc with tcg and bochs std-vga

I know this adds another config option and that's a bit sad, but
we can't include it unconditionally as it depends on PCI.
Suggestions welcome.
---
 drivers/gpu/vga/default_display.c | 77 +++
 1 file changed, 77 insertions(+)

diff --git a/drivers/gpu/vga/default_display.c 
b/drivers/gpu/vga/default_display.c
index 99e4723360da..b8e4a5af38e8 100644
--- a/drivers/gpu/vga/default_display.c
+++ b/drivers/gpu/vga/default_display.c
@@ -42,6 +42,10 @@
  *
  *  2) Anything specified by an arch hook,
  * e.g. arch/powerpc/kernel/pci-common.c::fixup_vga()
+ *
+ *  3) If neither of those, then we still want to pick something. For
+ * now, pick the first PCI VGA device with a driver bound and with
+ * memory or I/O control on.
  */
 
 #include 
@@ -53,6 +57,12 @@
 
 static struct pci_dev *vga_default;
 
+/*
+ * only go active after the late initcall so as not to interfere with
+ * the arbiter
+ */
+static bool vga_default_active = false;
+
 /**
  * pci_default_display - return the default display device
  *
@@ -84,3 +94,70 @@ void pci_set_default_display(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
 }
+
+static bool vga_default_try_device(struct pci_dev *pdev)
+{
+   u16 cmd;
+
+   /* Only deal with VGA class devices */
+   if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
+   return false;
+
+   /* Only deal with devices with drivers bound */
+   if (!pdev->driver)
+   return false;
+
+   /* Require I/O or memory control */
+   pci_read_config_word(pdev, PCI_COMMAND, );
+   if (!(cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)))
+   return false;
+
+   dev_info(>dev, "vga_default: setting as default device\n");
+   pci_set_default_display(pdev);
+   return true;
+}
+
+static int __init vga_default_init(void)
+{
+   struct pci_dev *pdev;
+
+   vga_default_active = true;
+
+   if (pci_default_display())
+   return 0;
+
+   pdev = NULL;
+   while ((pdev =
+   pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+  PCI_ANY_ID, pdev)) != NULL) {
+   if (vga_default_try_device(pdev))
+   return 0;
+   }
+
+   return 0;
+}
+late_initcall(vga_default_init);
+
+/*
+ * A driver could be loaded much later than late_initcall, for example
+ * if it's in a module.
+ *
+ * We want to pick that up. However, we want to make sure this does
+ * not interfere with the arbiter - it should only activate if the
+ * arbiter has already had a chance to operate. To ensure this, we set
+ * vga_default_active in the late_initcall: as the vga arbiter is a
+ * subsys initcall, it is guaranteed to fire first.
+ */
+static void vga_default_enable_hook(struct pci_dev *pdev)
+{
+   if (!vga_default_active)
+  return;
+
+   if (pci_default_display())
+   return;
+
+   vga_default_try_device(pdev);
+}
+DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
+  PCI_CLASS_DISPLAY_VGA, 8,
+  vga_default_enable_hook)
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] drm: documentation for default display device

[Daniel Axtens]

We have refactored and extended this - document it.

Signed-off-by: Daniel Axtens 
---
 Documentation/gpu/default_display.rst | 93 +++
 Documentation/gpu/index.rst   |  1 +
 2 files changed, 94 insertions(+)
 create mode 100644 Documentation/gpu/default_display.rst

diff --git a/Documentation/gpu/default_display.rst 
b/Documentation/gpu/default_display.rst
new file mode 100644
index ..3c190611564e
--- /dev/null
+++ b/Documentation/gpu/default_display.rst
@@ -0,0 +1,93 @@
+===
+Default Display Devices
+===
+
+Overview
+
+
+.. kernel-doc:: drivers/gpu/vga/default_display.c
+   :doc: overview
+
+
+Why do we need this?
+
+
+The default device is used to set the ``boot_vga`` per-device sysfs
+file, which is used by user-space. Most notably, Xorg reads this file
+via libpciaccess in order to facilitate auto-configuration.
+
+
+History
+===
+
+When the VGA arbiter was introduced, it would pick a default device on
+boot. As the arbiter exists to arbitrate access to legacy resources,
+it would only pick a card that could be accessed through legacy areas.
+(See the :doc:`vgaarbiter` documentation for more.)
+
+The arbiter was later extended on x86 and IA64 to consider the EFI
+framebuffer.
+
+This is all well and good if you have legacy resources or
+EFI. However, some systems do not have either of those. For example,
+on POWER8: [0]_
+
+ - There is no IO space at all
+
+ - We configure the 32-bit MMIO window to be around 3..4G (to avoid
+   overlapping with DMA space below it).
+
+So effectively, there is no path to the legacy areas.
+
+This means the VGA arbiter will not pick a default device on these
+platforms. So, on powerpc, a class hook was added to mark a default
+device (``arch/powerpc/kernel/pci-common.c``), independent of the
+arbiter.
+
+When this issue arose on an arm64 system, it was decided that a generic
+approach would be better than more special cases. Therefore, the
+default device selection was factored out, and it now operates using
+the priority list described in the Overview.
+
+API
+===
+
+Public
+--
+
+.. kernel-doc:: drivers/gpu/vga/default_display.c
+   :export:
+
+Private
+---
+
+.. kernel-doc:: drivers/gpu/vga/default_display.c
+   :internal:
+
+Future Work
+===
+
+There is no support for non-PCI VGA devices being marked as default.
+The following comment, extracted from an earlier version of
+:c:func:`pci_default_display()` might help:
+
+  If your VGA default device is not PCI, you'll have to override this
+  and return NULL here. In this case, I assume it will not conflict
+  with any PCI card. If this is not true, I'll have to define two
+  archs hooks for enabling/disabling the VGA default device if that
+  is possible. 
+
+  This may be a problem with real _ISA_ VGA cards, in addition to a
+  PCI one. I don't know at this point how to deal with that card. Can
+  theirs IOs be disabled at all ? If not, then I suppose it's a matter
+  of having the proper arch hook telling us about it, so we basically
+  never allow anybody to succeed a ``vga_get()``...
+
+Currently there is also no way to support non-VGA-class PCI devices as
+default display devices.
+
+
+References
+==
+  
+.. [0] https://www.spinics.net/lists/linux-pci/msg64142.html
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 35d673bf9b56..8083d84f2334 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
tegra
tinydrm
vc4
+   default_display
vga-switcheroo
vgaarbiter
bridge/dw-hdmi
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

[Jeff Cook]

On Wed, Aug 30, 2017, at 10:57 AM, Adam Borowski wrote:
> On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote:
> > I will wait for people to test and for result of my own test before
> > reposting if need be, otherwise i will post as separate patch.
> >
> > > But from a _very_ quick read-through this looks fine. But it obviously
> > > needs testing.
> > > 
> > > People - *especially* the people who saw issues under KVM - can you
> > > try out Jérôme's patch-series? I aded some people to the cc, the full
> > > series is on lkml. Jérôme - do you have a git branch for people to
> > > test that they could easily pull and try out?
> > 
> > https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch
> > git://people.freedesktop.org/~glisse/linux
> 
> Tested your branch as of 10f07641, on a long list of guest VMs.
> No earth-shattering kaboom.

I've been using the mmu_notifier branch @ a3d944233bcf8c for the last 36
hours or so, also without incident.

Unlike most other reporters, I experienced a similar splat on 4.12:

Aug 03 15:02:47 kvm_master kernel: [ cut here ]
Aug 03 15:02:47 kvm_master kernel: WARNING: CPU: 13 PID: 1653 at
arch/x86/kvm/mmu.c:682 mmu_spte_clear_track_bits+0xfb/0x100 [kvm]
Aug 03 15:02:47 kvm_master kernel: Modules linked in: vhost_net vhost
tap xt_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4
xt_tcpudp tun ebtable_filter ebtables ip6table_filter ip6_tables
iptable_filter msr nls_iso8859_1 nls_cp437 intel_rapl ipt_
MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack sb_edac
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel input_leds pcbc aesni_intel led_class
aes_x86_6
4 mxm_wmi crypto_simd glue_helper uvcvideo cryptd videobuf2_vmalloc
videobuf2_memops igb videobuf2_v4l2 videobuf2_core snd_usb_audio
videodev media joydev ptp evdev mousedev intel_cstate pps_core mac_hid
intel_rapl_perf snd_hda_intel snd_virtuoso snd_usbmidi_lib snd_hda_codec
snd_oxygen_lib snd_hda_core
Aug 03 15:02:47 kvm_master kernel:  snd_mpu401_uart snd_rawmidi
snd_hwdep snd_seq_device snd_pcm snd_timer snd soundcore i2c_algo_bit
pcspkr i2c_i801 lpc_ich ioatdma shpchp dca wmi acpi_power_meter tpm_tis
tpm_tis_core tpm button bridge stp llc sch_fq_codel virtio_pci
virtio_blk virtio_balloon virtio_net virtio_ring virtio kvm_intel kvm sg
ip_tables x_tables hid_logitech_hidpp hid_logitech_dj hid_generic
hid_microsoft usbhid hid sr_mod cdrom sd_mod xhci_pci ahci libahci
xhci_hcd libata usbcore scsi_mod usb_common zfs(PO) zunicode(PO)
zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops drm vfio_pci irqbypass
vfio_virqfd vfio_iommu_type1 vfio vfat fat ext4 crc16 jbd2 fscrypto
mbcache dm_thin_pool dm_cache dm_persistent_data dm_bio_prison dm_bufio
dm_raid raid456 libcrc32c 
Aug 03 15:02:47 kvm_master kernel:  crc32c_generic crc32c_intel
async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq
dm_mod dax raid1 md_mod  
Aug 03 15:02:47 kvm_master kernel: CPU: 13 PID: 1653 Comm: kworker/13:2
Tainted: PB D W  O4.12.3-1-ARCH #1 
Aug 03 15:02:47 kvm_master kernel: Hardware name: Supermicro
SYS-7038A-I/X10DAI, BIOS 2.0a 11/09/2016  
Aug 03 15:02:47 kvm_master kernel: Workqueue: events mmput_async_fn  
Aug 03 15:02:47 kvm_master kernel: task: 9fa89751b900 task.stack:
c179880d8000 
Aug 03 15:02:47 kvm_master kernel: RIP:
0010:mmu_spte_clear_track_bits+0xfb/0x100 [kvm]  
Aug 03 15:02:47 kvm_master kernel: RSP: 0018:c179880dbc20 EFLAGS:
00010246 
Aug 03 15:02:47 kvm_master kernel: RAX:  RBX:
0009c07cce77 RCX: dead00ff   
Aug 03 15:02:47 kvm_master kernel: RDX:  RSI:
9fa82d6d6f08 RDI: f6e76701f300   
Aug 03 15:02:47 kvm_master kernel: RBP: c179880dbc38 R08:
0010 R09: 000d   
Aug 03 15:02:47 kvm_master kernel: R10: 9fa0a56b0008 R11:
9fa0a56b R12: 009c07cc   
Aug 03 15:02:47 kvm_master kernel: R13: 9fa88b99 R14:
9f9e19dbb1b8 R15:    
Aug 03 15:02:47 kvm_master kernel: FS:  ()
GS:9fac5f34() knlGS:
Aug 03 15:02:47 kvm_master kernel: CS:  0010 DS:  ES:  CR0:
80050033   
Aug 03 15:02:47 kvm_master kernel: CR2: d1b542d71000 CR3:
000570a09000 CR4: 003426e0   
Aug 03 15:02:47 kvm_master kernel: DR0:  

[PATCH v3 0/3] Split default display handling out from VGA arbiter

[Daniel Axtens]

This patch set:

 - splits the default display handling out from VGA arbiter, into its
   own file and behind its own Kconfig option (and gives the functions
   better names).

 - adds extra detection of default devices. To be nominated, the vga
   arbiter and platform hooks must not have nominated a default. A
   card will then only be nominated if it has a driver attached and
   has IO or memory decoding enabled.

 - adds relevant documentation.

The practical impact of this is improved X autoconfiguration on some
arm64 systems.

Changes in v3:

 - Add documentation - thanks Daniel Vetter for pointing it out.

 - Clarify explanations. Thanks to everyone for continuing to bear
   with my incomplete understanding of PCI and provide some clarity.

 - Split refactoring and adding functionality.

Changes in v2: https://www.spinics.net/lists/linux-pci/msg64007.html

Drop all the powerpc patches. [explanation snipped]

v1: https://www.spinics.net/lists/linux-pci/msg63581.html

Regards,
Daniel

Daniel Axtens (3):
  drm: split default display handler out of VGA arbiter
  drm: add fallback default device detection
  drm: documentation for default display device

 Documentation/gpu/default_display.rst |  93 +++
 Documentation/gpu/index.rst   |   1 +
 arch/ia64/pci/fixup.c |   6 +-
 arch/powerpc/kernel/pci-common.c  |   6 +-
 arch/x86/pci/fixup.c  |   6 +-
 arch/x86/video/fbdev.c|   4 +-
 drivers/gpu/vga/Kconfig   |  12 +++
 drivers/gpu/vga/Makefile  |   1 +
 drivers/gpu/vga/default_display.c | 163 ++
 drivers/gpu/vga/vga_switcheroo.c  |   8 +-
 drivers/gpu/vga/vgaarb.c  |  61 +++--
 drivers/pci/pci-sysfs.c   |   4 +-
 include/linux/default_display.h   |  44 +
 include/linux/vgaarb.h|  15 
 14 files changed, 344 insertions(+), 80 deletions(-)
 create mode 100644 Documentation/gpu/default_display.rst
 create mode 100644 drivers/gpu/vga/default_display.c
 create mode 100644 include/linux/default_display.h

-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

[taskboxtester]

taskboxtes...@gmail.com liked your message with Boxer for Android.


On Sep 1, 2017 10:48 AM, Jeff Cook  wrote:

On Wed, Aug 30, 2017, at 10:57 AM, Adam Borowski wrote:
> On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote:
> > I will wait for people to test and for result of my own test before
> > reposting if need be, otherwise i will post as separate patch.
> >
> > > But from a _very_ quick read-through this looks fine. But it obviously
> > > needs testing.
> > > 
> > > People - *especially* the people who saw issues under KVM - can you
> > > try out Jérôme's patch-series? I aded some people to the cc, the full
> > > series is on lkml. Jérôme - do you have a git branch for people to
> > > test that they could easily pull and try out?
> > 
> > https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch
> > git://people.freedesktop.org/~glisse/linux
> 
> Tested your branch as of 10f07641, on a long list of guest VMs.
> No earth-shattering kaboom.

I've been using the mmu_notifier branch @ a3d944233bcf8c for the last 36
hours or so, also without incident.

Unlike most other reporters, I experienced a similar splat on 4.12:

Aug 03 15:02:47 kvm_master kernel: [ cut here ]
Aug 03 15:02:47 kvm_master kernel: WARNING: CPU: 13 PID: 1653 at
arch/x86/kvm/mmu.c:682 mmu_spte_clear_track_bits+0xfb/0x100 [kvm]
Aug 03 15:02:47 kvm_master kernel: Modules linked in: vhost_net vhost
tap xt_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4
xt_tcpudp tun ebtable_filter ebtables ip6table_filter ip6_tables
iptable_filter msr nls_iso8859_1 nls_cp437 intel_rapl ipt_
MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack sb_edac
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel input_leds pcbc aesni_intel led_class
aes_x86_6
4 mxm_wmi crypto_simd glue_helper uvcvideo cryptd videobuf2_vmalloc
videobuf2_memops igb videobuf2_v4l2 videobuf2_core snd_usb_audio
videodev media joydev ptp evdev mousedev intel_cstate pps_core mac_hid
intel_rapl_perf snd_hda_intel snd_virtuoso snd_usbmidi_lib snd_hda_codec
snd_oxygen_lib snd_hda_core
Aug 03 15:02:47 kvm_master kernel:  snd_mpu401_uart snd_rawmidi
snd_hwdep snd_seq_device snd_pcm snd_timer snd soundcore i2c_algo_bit
pcspkr i2c_i801 lpc_ich ioatdma shpchp dca wmi acpi_power_meter tpm_tis
tpm_tis_core tpm button bridge stp llc sch_fq_codel virtio_pci
virtio_blk virtio_balloon virtio_net virtio_ring virtio kvm_intel kvm sg
ip_tables x_tables hid_logitech_hidpp hid_logitech_dj hid_generic
hid_microsoft usbhid hid sr_mod cdrom sd_mod xhci_pci ahci libahci
xhci_hcd libata usbcore scsi_mod usb_common zfs(PO) zunicode(PO)
zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops drm vfio_pci irqbypass
vfio_virqfd vfio_iommu_type1 vfio vfat fat ext4 crc16 jbd2 fscrypto
mbcache dm_thin_pool dm_cache dm_persistent_data dm_bio_prison dm_bufio
dm_raid raid456 libcrc32c 
Aug 03 15:02:47 kvm_master kernel:  crc32c_generic crc32c_intel
async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq
dm_mod dax raid1 md_mod  
Aug 03 15:02:47 kvm_master kernel: CPU: 13 PID: 1653 Comm: kworker/13:2
Tainted: PB D W  O4.12.3-1-ARCH #1 
Aug 03 15:02:47 kvm_master kernel: Hardware name: Supermicro
SYS-7038A-I/X10DAI, BIOS 2.0a 11/09/2016  
Aug 03 15:02:47 kvm_master kernel: Workqueue: events mmput_async_fn  
Aug 03 15:02:47 kvm_master kernel: task: 9fa89751b900 task.stack:
c179880d8000 
Aug 03 15:02:47 kvm_master kernel: RIP:
0010:mmu_spte_clear_track_bits+0xfb/0x100 [kvm]  
Aug 03 15:02:47 kvm_master kernel: RSP: 0018:c179880dbc20 EFLAGS:
00010246 
Aug 03 15:02:47 kvm_master kernel: RAX:  RBX:
0009c07cce77 RCX: dead00ff   
Aug 03 15:02:47 kvm_master kernel: RDX:  RSI:
9fa82d6d6f08 RDI: f6e76701f300   
Aug 03 15:02:47 kvm_master kernel: RBP: c179880dbc38 R08:
0010 R09: 000d   
Aug 03 15:02:47 kvm_master kernel: R10: 9fa0a56b0008 R11:
9fa0a56b R12: 009c07cc   
Aug 03 15:02:47 kvm_master kernel: R13: 9fa88b99 R14:
9f9e19dbb1b8 R15:    
Aug 03 15:02:47 kvm_master kernel: FS:  ()
GS:9fac5f34() knlGS:
Aug 03 15:02:47 kvm_master kernel: CS:  0010 DS:  ES:  CR0:
80050033   
Aug 03 15:02:47 kvm_master kernel: CR2: d1b542d71000 

[PATCH v3 1/3] drm: split default display handler out of VGA arbiter

[Daniel Axtens]

Split the small bit of code that does default VGA handling out from
the arbiter. Add a Kconfig option to allow the kernel to be built
with just the default handling, or the arbiter and default handling.

While doing this, rename the functions from vga_(set_)default_device
to pci_(set_)default_display. This makes it clear that these functions
do not rely on legacy VGA access: they're about the default PCI display.
(The device still needs to be a member of PCI_CLASS_DISPLAY_VGA.)

This should not introduce any functional change.

Signed-off-by: Daniel Axtens 

---

I know this adds another config option and that's a bit sad, but
we can't include it unconditionally as it depends on PCI.
Suggestions welcome.

v3: split from the part where we add functionality
rename functions
---
 arch/ia64/pci/fixup.c |  6 +--
 arch/powerpc/kernel/pci-common.c  |  6 +--
 arch/x86/pci/fixup.c  |  6 +--
 arch/x86/video/fbdev.c|  4 +-
 drivers/gpu/vga/Kconfig   | 12 ++
 drivers/gpu/vga/Makefile  |  1 +
 drivers/gpu/vga/default_display.c | 86 +++
 drivers/gpu/vga/vga_switcheroo.c  |  8 ++--
 drivers/gpu/vga/vgaarb.c  | 61 ++-
 drivers/pci/pci-sysfs.c   |  4 +-
 include/linux/default_display.h   | 44 
 include/linux/vgaarb.h| 15 ---
 12 files changed, 173 insertions(+), 80 deletions(-)
 create mode 100644 drivers/gpu/vga/default_display.c
 create mode 100644 include/linux/default_display.h

diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 41caa99add51..a5f35e767c84 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -5,7 +5,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -22,7 +22,7 @@
  * card with this copy. On laptops this copy has to be used since
  * the main ROM may be compressed or combined with another image.
  * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
+ * with IORESOURCE_ROM_SHADOW check if a pci_default_display is already set
  * by either arch code or vga-arbitration; if so only apply the fixup to this
  * already-determined primary video card.
  */
@@ -59,7 +59,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   if (!vga_default_device() || pdev == vga_default_device()) {
+   if (!pci_default_display() || pdev == pci_default_display()) {
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
res = >resource[PCI_ROM_RESOURCE];
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 341a7469cab8..9f82f13ac531 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -1747,8 +1747,8 @@ static void fixup_vga(struct pci_dev *pdev)
u16 cmd;
 
pci_read_config_word(pdev, PCI_COMMAND, );
-   if ((cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) || 
!vga_default_device())
-   vga_set_default_device(pdev);
+   if ((cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) || 
!pci_default_display())
+   pci_set_default_display(pdev);
 
 }
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 11e407489db0..7e32a2a80383 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -302,7 +302,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_MCH_PC1,pcie_r
  * card with this copy. On laptops this copy has to be used since
  * the main ROM may be compressed or combined with another image.
  * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
+ * with IORESOURCE_ROM_SHADOW check if a pci_default_display is already set
  * by either arch code or vga-arbitration; if so only apply the fixup to this
  * already-determined primary video card.
  */
@@ -334,7 +334,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   if (!vga_default_device() || pdev == vga_default_device()) {
+   if (!pci_default_display() || pdev == pci_default_display()) {
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
res = >resource[PCI_ROM_RESOURCE];
diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
index 9fd24846d094..114bd9ac95d0 100644
--- a/arch/x86/video/fbdev.c
+++ b/arch/x86/video/fbdev.c

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

[Daniel Axtens]

Hi Ard,

> If we are all in agreement that fixing X is not an option, I think
> this is a reasonable approach

This did come up in discussion at some earlier point in one of the many
spins we've done of this - I don't remember if you brought it up or
someone else did - but my concern was this: If it were just X we would
be fine, but if we go down that path I'm worried about also having to
fix Mir/Wayland/whatever-the-new-exciting-display-server-is-this-week,
ad nauseum.

> Acked-by: Ard Biesheuvel 

Thanks!

Regards,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

[Ard Biesheuvel]

On 1 September 2017 at 08:27, Daniel Axtens  wrote:
> This patch set:
>
>  - splits the default display handling out from VGA arbiter, into its
>own file and behind its own Kconfig option (and gives the functions
>better names).
>
>  - adds extra detection of default devices. To be nominated, the vga
>arbiter and platform hooks must not have nominated a default. A
>card will then only be nominated if it has a driver attached and
>has IO or memory decoding enabled.
>
>  - adds relevant documentation.
>
> The practical impact of this is improved X autoconfiguration on some
> arm64 systems.
>
> Changes in v3:
>
>  - Add documentation - thanks Daniel Vetter for pointing it out.
>
>  - Clarify explanations. Thanks to everyone for continuing to bear
>with my incomplete understanding of PCI and provide some clarity.
>
>  - Split refactoring and adding functionality.
>
> Changes in v2: https://www.spinics.net/lists/linux-pci/msg64007.html
>
> Drop all the powerpc patches. [explanation snipped]
>
> v1: https://www.spinics.net/lists/linux-pci/msg63581.html
>

If we are all in agreement that fixing X is not an option, I think
this is a reasonable approach

Acked-by: Ard Biesheuvel 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor

[Rhys Kidd]

v2:
 - add nv138 and drop nv13b chipsets (Ilia Mirkin)
 - refactor out status variable and instead mask tsensor (Ilia Mirkin)
 - switch SHADOWed state message away from nvkm_error() (Ilia Mirkin)
 - rename internal temperature variable (Karol Herbst)

Signed-off-by: Rhys Kidd 
---
 .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  6 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  3 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c  | 56 ++
 5 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index 1bfd93b85575..9841f076da2e 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -97,4 +97,5 @@ int gt215_therm_new(struct nvkm_device *, int, struct 
nvkm_therm **);
 int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 #endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index e096a5d9c292..28fd4fa98635 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2169,6 +2169,7 @@ nv130_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gm200_secboot_new,
.pci = gp100_pci_new,
.pmu = gp100_pmu_new,
@@ -2203,6 +2204,7 @@ nv132_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2237,6 +2239,7 @@ nv134_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2271,6 +2274,7 @@ nv136_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2305,6 +2309,7 @@ nv137_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2339,6 +2344,7 @@ nv138_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
.timer = gk20a_timer_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
index 2bafcc1d1818..7ba56b12badd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
@@ -12,3 +12,4 @@ nvkm-y += nvkm/subdev/therm/gt215.o
 nvkm-y += nvkm/subdev/therm/gf119.o
 nvkm-y += nvkm/subdev/therm/gm107.o
 nvkm-y += nvkm/subdev/therm/gm200.o
+nvkm-y += nvkm/subdev/therm/gp100.o
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 952a7cb0a59a..f27fc6d0d4c6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -341,7 +341,8 @@ nvkm_therm_init(struct nvkm_subdev *subdev)
 {
struct nvkm_therm *therm = nvkm_therm(subdev);
 
-   therm->func->init(therm);
+   if (therm->func->init)
+   therm->func->init(therm);
 
if (therm->suspend >= 0) {
/* restore the pwm value only when on manual or auto mode */
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
new file mode 100644
index ..adadbe5ff9a7
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2017 Rhys Kidd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is 

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

[Krzysztof Kozlowski]

On Fri, Sep 1, 2017 at 3:47 AM, Hoegeun Kwon  wrote:
> The gscaler has hardware rotation limits that need to be imported from
> dts. Parse them and add them to the property list.
>
> The rotation hardware limits are related to the cropped source size.
> When swap occurs, use rot_max size instead of crop_max size.
>
> Also the scaling limits are related to post size, use pos size to
> check the limits.
>
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
> +
>  include/uapi/drm/exynos_drm.h   |  2 ++
>  2 files changed, 42 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 0506b2b..dd9b057 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct device 
> *dev,
> bool swap;
> int i;
>
> +   config = >config[EXYNOS_DRM_OPS_DST];
> +
> +   /* check for degree */
> +   switch (config->degree) {
> +   case EXYNOS_DRM_DEGREE_90:
> +   case EXYNOS_DRM_DEGREE_270:
> +   swap = true;
> +   break;
> +   case EXYNOS_DRM_DEGREE_0:
> +   case EXYNOS_DRM_DEGREE_180:
> +   swap = false;
> +   break;
> +   default:
> +   DRM_ERROR("invalid degree.\n");
> +   goto err_property;
> +   }
> +
> for_each_ipp_ops(i) {
> if ((i == EXYNOS_DRM_OPS_SRC) &&
> (property->cmd == IPP_CMD_WB))
> @@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct device 
> *dev,
> goto err_property;
> }
>
> -   /* check for degree */
> -   switch (config->degree) {
> -   case EXYNOS_DRM_DEGREE_90:
> -   case EXYNOS_DRM_DEGREE_270:
> -   swap = true;
> -   break;
> -   case EXYNOS_DRM_DEGREE_0:
> -   case EXYNOS_DRM_DEGREE_180:
> -   swap = false;
> -   break;
> -   default:
> -   DRM_ERROR("invalid degree.\n");
> -   goto err_property;
> -   }
> -
> /* check for buffer bound */
> if ((pos->x + pos->w > sz->hsize) ||
> (pos->y + pos->h > sz->vsize)) {
> @@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct device 
> *dev,
> goto err_property;
> }
>
> +   /*
> +* The rotation hardware limits are related to the cropped
> +* source size. So use rot_max size to check the limits when
> +* swap happens. And also the scaling limits are related to 
> pos
> +* size, use pos size to check the limits.
> +*/
> /* check for crop */
> if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
> if (swap) {
> if ((pos->h < pp->crop_min.hsize) ||
> -   (sz->vsize > pp->crop_max.hsize) ||
> +   (pos->h > pp->rot_max.hsize) ||
> (pos->w < pp->crop_min.vsize) ||
> -   (sz->hsize > pp->crop_max.vsize)) {
> +   (pos->w > pp->rot_max.vsize)) {
> DRM_ERROR("out of crop size.\n");
> goto err_property;
> }
> } else {
> if ((pos->w < pp->crop_min.hsize) ||
> -   (sz->hsize > pp->crop_max.hsize) ||
> +   (pos->w > pp->crop_max.hsize) ||
> (pos->h < pp->crop_min.vsize) ||
> -   (sz->vsize > pp->crop_max.vsize)) {
> +   (pos->h > pp->crop_max.vsize)) {
> DRM_ERROR("out of crop size.\n");
> goto err_property;
> }
> @@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct device 
> *dev,
> if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
> if (swap) {
> if ((pos->h < pp->scale_min.hsize) ||
> -   (sz->vsize > pp->scale_max.hsize) ||
> +   (pos->h > pp->scale_max.hsize) ||
> (pos->w < pp->scale_min.vsize) ||
> -

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

--- Comment #5 from Rob MacKinnon  ---
Comments inline...

(In reply to Alex Deucher from comment #2)
> (In reply to Rob MacKinnon from comment #0)
> > * Actual Result:
> > - DPMS change level changes as expected.
> > - Dmesg:
> > [ 3302.814889] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
> > rv770_restrict_performance_levels_before_switch failed
> > [ 3316.661933] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
> > rv770_restrict_performance_levels_before_switch failed
> > 
> > * Expected result:
> > - DPMS change level changes as expected.
> > - No error messages in dmesg.
> 
> Are you actually experiencing any problems?  I think the error message may
> be harmless can could probably be removed.

The annoyance of the message is totally trivial, but I believe there is an
issue with the initial setting of the DPMS profile. Which I'll mention in the
next comment.

> > 
> > * Additional Info:
> > Also, not sure if this is related or not, when switching from "battery" to
> > "performance" there sometimes appears to be an initial clocking issue (which
> > I believe is related to #93753). Switching back and forth a few times seems
> > to clean it.  Unsure the cause.  Another note, upon further inspection of my
> 
> There is no real balanced state.  It's either battery or performance
> depending on whether the chip is on ac or dc power.  The only real states
> you can switch between are performance and battery.  I need to see the
> output of our dmesg with radeon.dpm=1 to see what states your vbios provides.

I believe you when you say that the `balanced` state is non-existent.  A check
after cold starting shows that `balanced` is the first profile being set:

# cat /sys/class/drm/card0/device/power_dpm_state
balanced

So I'm not sure where this profile is being set from.

> 
> > DPMS settings, I noticed the drastic differences between "balanced" and
> > "battery" `sclk`s. My understand (which could be faulty) is that `sclk`
> > drives the clocking for single displays, while `mclk` for multiple. My
> 
> sclk is the 3D engine clock.  mclk is the memory clock.  mclk switching is
> disabled when multiple displays are active since the switch has to happen
> during the display's vblank period otherwise you'd see display glitches. 
> With multiple displays, the vblank periods are not likely to align so mclk
> switching is disabled.

Thank you very much for clarifying the function of `sclk` vs `mclk`. That's
great info, I wish I'd been able to find it elsewhere. My google-fu was the
source of my original understanding (which as it turns out was completely
wrong).

Regardless, somewhere the `balanced` profile is getting pulled from with
greatly under valued 3D clocking value.  Is there a setting somewhere that I
can trace down where this invalid profile is being generated or referenced?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

--- Comment #4 from Rob MacKinnon  ---
Created attachment 133934
  --> https://bugs.freedesktop.org/attachment.cgi?id=133934=edit
dmesg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101769] 2X performance regression on Mesa 17.1 vs 17.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101769

--- Comment #2 from Matias N. Goldberg  ---
Bah, nevermind. Either my bug is not related or it gets fixed the same way.

Updating kernel from 4.11.6 to 4.12.10 seems to have solved all the weird
performance issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

--- Comment #3 from Rob MacKinnon  ---
Created attachment 133933
  --> https://bugs.freedesktop.org/attachment.cgi?id=133933=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102500

Dieter Nützel  changed:

   What|Removed |Added

 CC||deathsim...@vodafone.de

--- Comment #5 from Dieter Nützel  ---
(In reply to Dieter Nützel from comment #4)
> (In reply to Alex Deucher from comment #1)
> > can you bisect?
> 
> Hello all,
> 
> I get the same on 'amd-staging-drm-next' since 1. of Sep (kernel build time:
> 1. Sep 02:14 CEST) update, too. Will go to bisect in the evening.
> 
> [  262.462941] amdgpu :01:00.0: GPU fault detected: 146 0x0a023d14
> [  262.462946] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
> 0x00101540
> [  262.462949] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
> 0x0903D014
> [  262.462952] amdgpu :01:00.0: VM fault (0x14, vmid 4) at page 1054016,
> write from 'SDM1' (0x53
> 444d31) (61)

Yes,

git revert fd8bf087dffc

commit fd8bf087dffc0bce047c5aea2afcb8f821e48db1
Author: Christian König 
Date:   Tue Aug 29 16:14:32 2017 +0200

drm/amdgpu: bump version for support of local BOs

Signed-off-by: Christian König 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher 

Solve it on 'amd-staging-drm-next', too.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101769] 2X performance regression on Mesa 17.1 vs 17.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101769

--- Comment #1 from Matias N. Goldberg  ---
I was going to submit a new bug report, but I suspect this is the same issue.

I recently purchased an i7 7700 + Radeon RX 560 2GB to replace my older i5 4650
+ Radeon HD 7770.
But I noticed performance on Dolphin Emulator *went down*. Way down when using
OpenGL; whereas Vulkan has no performance issues and running on Windows gives
similar performance to Linux with Vulkan.

But what's more baffling is the performance with our Ogre 2.1 samples:
1. If I run our Postprocessing sample I can easily obtain 500 fps.
2. But if certain processes are running on the background, such as RenderDoc
with a capture (even if RenderDoc is minimized), the framerate will go down as
low as 55-69fps; with CPU usage around 3% and radeontop indicating a GPU usage
of 15%. This behavior is a little inconsistent, as closing RenderDoc will
increase performance back to 500 fps, but opening RenderDoc again will keep it
at 500 fps. RenderDoc is not the only process to induce this mysterious
behavior, but it is the one I've managed to identify correctly.

At first I suspected a clocking problem, but after setting CPU governor to
performance and echo high >
/sys/class/drm/card0/device/power_dpm_force_performance_level the problem
persisted.

The framerate drops aren't also consistent, another of our samples for example
reduces their performance from 200fps to 40fps.
Dolphin should be performing between 100-200 fps (by comparing with Vulkan and
Windows versions) but it manages between 21-49fps

I will try to see if older versions of Mesa as this ticket suggests will solve
the problem; although I'm not sure if Mesa 17.0.0 supports Polaris.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50655] [r600g][RV670 HD3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=50655

Bryan Quigley  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #79 from Bryan Quigley  ---
Per my comment on 2014-07-30 and no other updates since that year I'm going to
go ahead and mark this Fixed.   Thanks all!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

--- Comment #2 from Alex Deucher  ---
(In reply to Rob MacKinnon from comment #0)
> * Actual Result:
> - DPMS change level changes as expected.
> - Dmesg:
> [ 3302.814889] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
> rv770_restrict_performance_levels_before_switch failed
> [ 3316.661933] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
> rv770_restrict_performance_levels_before_switch failed
> 
> * Expected result:
> - DPMS change level changes as expected.
> - No error messages in dmesg.

Are you actually experiencing any problems?  I think the error message may be
harmless can could probably be removed.

> 
> * Additional Info:
> Also, not sure if this is related or not, when switching from "battery" to
> "performance" there sometimes appears to be an initial clocking issue (which
> I believe is related to #93753). Switching back and forth a few times seems
> to clean it.  Unsure the cause.  Another note, upon further inspection of my

There is no real balanced state.  It's either battery or performance depending
on whether the chip is on ac or dc power.  The only real states you can switch
between are performance and battery.  I need to see the output of our dmesg
with radeon.dpm=1 to see what states your vbios provides.

> DPMS settings, I noticed the drastic differences between "balanced" and
> "battery" `sclk`s. My understand (which could be faulty) is that `sclk`
> drives the clocking for single displays, while `mclk` for multiple. My

sclk is the 3D engine clock.  mclk is the memory clock.  mclk switching is
disabled when multiple displays are active since the switch has to happen
during the display's vblank period otherwise you'd see display glitches.  With
multiple displays, the vblank periods are not likely to align so mclk switching
is disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output with radeon.dpm=1 specified on
kernel command line in grub.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102511] RV770 error on change dpm balanced<->battery

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102511

Bug ID: 102511
   Summary: RV770 error on change dpm balanced<->battery
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: rob.mackin...@gmail.com

* Overview:
I decided today I would troubleshoot/source an error that has been plaguing my
dmesg:

[drm:btc_dpm_set_power_state [radeon]] *ERROR*
rv770_restrict_performance_levels_before_switch failed

Over all this bug may or may not be related to #91375. I dug into the DPM
setting and levels and was happy to find that switching from "performance" to
"battery" (and vice versa) did not reproduce this bug. What did reproduce the
bug was switching from "balanced" and "battery" (and vice versa).

Kernel version: 4.11.12
Linux Firmware version: 20170519
X.org server version: 1.19.3
Mesa version: 17.2.0_rc5
libdrm version: 2.4.82
Gnome version: 3.24

* Steps to Reproduce:
echo battery > /sys/class/drm/card0/device/power_dpm_state
echo balanced > /sys/class/drm/card0/device/power_dpm_state

* Actual Result:
- DPMS change level changes as expected.
- Dmesg:
[ 3302.814889] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
rv770_restrict_performance_levels_before_switch failed
[ 3316.661933] [drm:btc_dpm_set_power_state [radeon]] *ERROR*
rv770_restrict_performance_levels_before_switch failed

* Expected result:
- DPMS change level changes as expected.
- No error messages in dmesg.

* Additional Info:
Also, not sure if this is related or not, when switching from "battery" to
"performance" there sometimes appears to be an initial clocking issue (which I
believe is related to #93753). Switching back and forth a few times seems to
clean it.  Unsure the cause.  Another note, upon further inspection of my DPMS
settings, I noticed the drastic differences between "balanced" and "battery"
`sclk`s. My understand (which could be faulty) is that `sclk` drives the
clocking for single displays, while `mclk` for multiple. My laptop rig has 2 DP
displays (3 if I could get it to drive the LVDS display with the 2 DPs, but
that is another issue for another bug another day)

# echo battery > /sys/class/drm/card0/device/power_dpm_state
# cat /sys/kernel/debug/dri/0/radeon_pm_info 
uvdvclk: 0 dclk: 0
power level 2sclk: 3 mclk: 3 vddc: 900 vddci: 0

# echo balanced > /sys/class/drm/card0/device/power_dpm_state
# cat /sys/kernel/debug/dri/0/radeon_pm_info 
uvdvclk: 0 dclk: 0
power level 0sclk: 25000 mclk: 9 vddc: 1100 vddci: 0


# echo performance > /sys/class/drm/card0/device/power_dpm_state
# cat /sys/kernel/debug/dri/0/radeon_pm_info 
uvdvclk: 0 dclk: 0
power level 2sclk: 75000 mclk: 9 vddc: 1100 vddci: 0

*Video Card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Seymour [Radeon HD 6400M/7400M Series] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Radeon HD 6470M
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 1/1] amdgpu: Do not write beyond allocated memory when parsing ids

[Jan Vesely]

Fixes crash when/usr/share/libdrm/amdgpu.ids contains ASIC_ID_TABLE_NUM_ENTRIES 
+ 1 entries.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102432
Signed-off-by: Jan Vesely 
---
Compile tested only.

 amdgpu/amdgpu_asic_id.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
index 3a88896b..e8218974 100644
--- a/amdgpu/amdgpu_asic_id.c
+++ b/amdgpu/amdgpu_asic_id.c
@@ -186,19 +186,20 @@ int amdgpu_parse_asic_ids(struct amdgpu_asic_id 
**p_asic_id_table)
table_size++;
}
 
-   /* end of table */
-   id = asic_id_table + table_size;
-   memset(id, 0, sizeof(struct amdgpu_asic_id));
-
if (table_size != table_max_size) {
id = realloc(asic_id_table, (table_size + 1) *
 sizeof(struct amdgpu_asic_id));
-   if (!id)
+   if (!id) {
r = -ENOMEM;
-   else
-   asic_id_table = id;
+   goto free;
+   }
+   asic_id_table = id;
 }
 
+   /* end of table */
+   id = asic_id_table + table_size;
+   memset(id, 0, sizeof(struct amdgpu_asic_id));
+
 free:
free(line);
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vtables: Fix typo

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:51:41PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 01, 2017 at 04:40:41PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The callback is named .atomic_check, not .atomc_check.
> > 
> > Signed-off-by: Thierry Reding 
> 
> For the series
> Reviewed-by: Ville Syrjälä 

Applied to drm-misc-next, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/scdc-helper: Remove gratuitous blank lines

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:00:52PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 01, 2017 at 04:44:28PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > It's unusual to separate kerneldoc comments from the functions that they
> > describe by a blank line. Remove them.
> > 
> > Signed-off-by: Thierry Reding 
> 
> Series lgtm
> Reviewed-by: Ville Syrjälä 

Applied to drm-misc-next, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tve200: Replace custom connector with panel bridge

[Eric Anholt]

Linus Walleij  writes:

> This replaces the custom connector in the TVE200 with the
> panel bridge helper. As long as we're just using panels
> and no other bridges, this works just fine.

Yeah, we definitely need a way to get the bus_flags/bus_formats from the
next link in the bridge chain in general, rather than needing to reach
into the panel's connector (or being just out of luck in a 2-bridge
chain).  That seems like it'll be straightforward to do later, and this
is a good start.

I don't think you need the new #includes in tve200_drm.h, but other than
maybe that change:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device

[Noralf Trønnes]

Den 01.09.2017 09.28, skrev Laurent Pinchart:

Hi Noralf,

On Thursday, 31 August 2017 20:16:42 EEST Noralf Trønnes wrote:

Den 31.08.2017 12.18, skrev Laurent Pinchart:

On Monday, 28 August 2017 20:17:46 EEST Noralf Trønnes wrote:

Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---

   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 44 +++---
   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  2 +-
   drivers/gpu/drm/tinydrm/mi0283qt.c  |  8 +++---
   drivers/gpu/drm/tinydrm/mipi-dbi.c  | 12 
   drivers/gpu/drm/tinydrm/repaper.c   | 10 +++
   drivers/gpu/drm/tinydrm/st7586.c| 16 +--
   include/drm/tinydrm/tinydrm.h   |  9 +-
   7 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c index 551709e..f11f4cd
100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c

[snip]


@@ -142,23 +142,16 @@ static int tinydrm_init(struct device *parent,
struct
tinydrm_device *tdev, const struct drm_framebuffer_funcs *fb_funcs,

struct drm_driver *driver)
   
   {


-   struct drm_device *drm;
+   struct drm_device *drm = >drm;
+   int ret;

mutex_init(>dirty_lock);
tdev->fb_funcs = fb_funcs;

-   /*
-* We don't embed drm_device, because that prevent us from using
-* devm_kzalloc() to allocate tinydrm_device in the driver since
-* drm_dev_unref() frees the structure. The devm_ functions provide
-* for easy error handling.

Don't you then need a custom drm_driver.release handler to free the parent
structure ?

I rely on the fact that drm_device is the first member in the driver
structure and thus it will be freed in drm_dev_release(). A later patch
adds a drm_driver.release function though.

That's a bit hackish. As a later patch changes this I'd be OK with this one,
but you should mention that you rely on the structure layout in the commit
message.


I've seen it around, so I figured it was a common pattern.

Looking at it now, I see that it adds obscurity:
- Where is that driver struct freed?
- In tinydrm_release().
- How can it do that when it doesn't have a pointer to it?
- It does this indirectly since tinydrm_device is the first member.
- Ooh...

I remember now that I hit the same kind of obscurity in the vbox driver
where it assigns a private structure to fb_info.par and I know that
drm_fb_helper expects this to be struct drm_fb_helper. So how could
this work? After some digging I realised that it worked because
drm_fb_helper was the first member of the private struct.
It made the code difficult to read.

So yeah, better stay away from things like this when possible.

In patch 6 I did document this freeing behaviour in the struct
tinydrm_device docs, but that probably wouldn't have helped me much if
I was new to tinydrm. It would have taken me some time to pick up that
piece of information.

I think I'll add drm_driver.release functions to this patch and
explicitly free the driver structure, since it logically belongs here.

An upside of having the drm_driver.release callback in the driver is
the educational/awareness part, it acts as a reminder that the driver
structure can live on even after driver.remove has finished.

This argument in itself is probably strong enough to warrant one
release function per driver structure, since this lifetime issue is so
easy to get wrong.

I've also realised that the driver struct is leaked if devm_tinydrm_init()
fails, so I need to fix that as well.

Noralf.


-*/
-   drm = drm_dev_alloc(driver, parent);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
-   tdev->drm = drm;
-   drm->dev_private = tdev;
+   ret = drm_dev_init(drm, driver, parent);
+   if (ret)
+   return ret;
+

drm_mode_config_init(drm);
drm->mode_config.funcs = _mode_config_funcs;

[snip]


diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c index 7e5bb7d..77d40c9 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c

[snip]


@@ -169,7 +169,7 @@ static int mi0283qt_probe(struct spi_device *spi)

u32 rotation = 0;
int ret;

-   mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+   mipi = kzalloc(sizeof(*mipi), GFP_KERNEL);

Where's the related kfree() ?


if (!mipi)

return -ENOMEM;

[snip]


diff --git a/drivers/gpu/drm/tinydrm/repaper.c
b/drivers/gpu/drm/tinydrm/repaper.c index 30dc97b..b8fc8eb 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ 

[Bug 102432] [regression] Steam fails to start with libdrm 2.4.83

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102432

--- Comment #4 from Jan Vesely  ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Jan Vesely from comment #2)
> > The parsing mechanism is flimsy and adding an entry to
> > /usr/share/libdrm/amdgpu.ids crashes libdrm
> 
> Can you share more details about how adding en entry to
> /usr/share/libdrm/amdgpu.ids causes a crash?

using libdrm-2.4.82-1.fc26.x86_64 (there have been no other changes in
amdgpu_asic_id.c in later releases)

sudo vim /usr/share/libdrm/amdgpu.ids
add a line like the one in the above mentioned commit

glxinfo -> crash
clinfo -> crash
glxgears -> crash

looking at the code adding one entry means that table_size == table_max_size +
1. therefore all initially callocated (line 132) memory is used.
memset(line 191) then writes beyond the allocated memory and corrupts libc
internal structures. the following realloc(line 194) then crashes.
see below for both valgrind trace showing the invalid write, and gdb trace
showing the crash.

moving the memset(line 191) after the last realloc block should be enough to
fix the problem.
I have verified that adding 2 entries to /usr/share/libdrm/amdgpu.ids is a
workaround, realloc on line 159 triggers and prevents illegal write from
memset(line 191).


clinfo backtrace from gdb (the machine is accessed remotely, but the crashes
happen even if used locally):
Program received signal SIGABRT, Aborted.
0x7761769b in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x7761769b in raise () from /lib64/libc.so.6
#1  0x776194a0 in abort () from /lib64/libc.so.6
#2  0x7765d8e1 in __libc_message () from /lib64/libc.so.6
#3  0x7766bd19 in _int_realloc () from /lib64/libc.so.6
#4  0x7766e7eb in realloc () from /lib64/libc.so.6
#5  0x7fffedcd120c in amdgpu_parse_asic_ids
(p_asic_id_table=p_asic_id_table@entry=0x557c9ff8) at amdgpu_asic_id.c:194
#6  0x7fffedcd386c in amdgpu_device_initialize (fd=fd@entry=4,
major_version=major_version@entry=0x7fffd5c4,
minor_version=minor_version@entry=0x7fffd5c8, 
device_handle=device_handle@entry=0x7fffd5e0) at amdgpu_device.c:276
#7  0x7fffee1b3adf in amdgpu_winsys_create (fd=fd@entry=4,
screen_create=0x7fffee2054d0 ) at amdgpu_winsys.c:562
#8  0x7fffee101d8f in create_screen (fd=4) at pipe_radeonsi.c:14
#9  0x77296348 in clover::device::device(clover::platform&,
pipe_loader_device*) () from /lib64/libMesaOpenCL.so.1
#10 0x772bb68b in clover::intrusive_ref
clover::create(clover::platform&, pipe_loader_device*&) ()
   from /lib64/libMesaOpenCL.so.1
#11 0x772bb2d9 in clover::platform::platform() () from
/lib64/libMesaOpenCL.so.1
#12 0x77265248 in __static_initialization_and_destruction_0 () from
/lib64/libMesaOpenCL.so.1
#13 0x77265278 in _GLOBAL__sub_I_platform.cpp () from
/lib64/libMesaOpenCL.so.1
#14 0x77de6d73 in _dl_init () from /lib64/ld-linux-x86-64.so.2
#15 0x77debcca in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#16 0x77732a2f in _dl_catch_error () from /lib64/libc.so.6
#17 0x77deb1d9 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#18 0x779b2f26 in dlopen_doit () from /lib64/libdl.so.2
#19 0x77732a2f in _dl_catch_error () from /lib64/libc.so.6
#20 0x779b36a5 in _dlerror_run () from /lib64/libdl.so.2
#21 0x779b2fb1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#22 0x77bbb982 in _load_icd (lib_path=0x557734d0
"libMesaOpenCL.so.1", num_icds=0) at ocl_icd_loader.c:184
#23 _open_driver (file_path=, dir_path=,
num_icds=0) at ocl_icd_loader.c:237
#24 _open_drivers (dir_path=, dir=) at
ocl_icd_loader.c:250
#25 __initClIcd () at ocl_icd_loader.c:646
#26 _initClIcd_real () at ocl_icd_loader.c:702
#27 0x77bbd994 in _initClIcd () at ocl_icd_loader.c:724
#28 clGetPlatformIDs (num_entries=0, platforms=0x0,
num_platforms=0x5576a798 ) at ocl_icd_loader.c:846
#29 0x96c2 in main (argc=1, argv=0x7fffe108) at
src/clinfo.c:2723

running in valgrind prevents the crash but it complains about invalid write in
that function:
==3701== Command: clinfo
==3701== 
==3701== Invalid write of size 8
==3701==at 0xF13A1DE: UnknownInlinedFun (string3.h:90)
==3701==by 0xF13A1DE: amdgpu_parse_asic_ids (amdgpu_asic_id.c:191)
==3701==by 0xF13C86B: amdgpu_device_initialize (amdgpu_device.c:276)
==3701==by 0xEBF6ADE: amdgpu_winsys_create (amdgpu_winsys.c:562)
==3701==by 0xEB44D8E: create_screen (pipe_radeonsi.c:14)
==3701==by 0x5AAD347: clover::device::device(clover::platform&,
pipe_loader_device*) (in /usr/lib64/libMesaOpenCL.so.1.0.0)
==3701==by 0x5AD268A: clover::intrusive_ref
clover::create(clover::platform&, pipe_loader_device*&) (in
/usr/lib64/libMesaOpenCL.so.1.0.0)
==3701==by 0x5AD22D8: 

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Eric Anholt]

Boris Brezillon  writes:

> Hi Eric,
>
> On Thu, 31 Aug 2017 10:03:23 -0700
> Eric Anholt  wrote:
>
>> Boris Brezillon  writes:
>> > +VID_DATATYPE(MIPI_DSI_PACKED_PIXEL_STREAM_16);
>> > +  break;
>> > +
>> > +  default:
>> > +  dev_err(dsi->base.dev, "Unsupported DSI format\n");
>> > +  return;
>> > +  }  
>> 
>> > +static irqreturn_t cdns_dsi_interrupt(int irq, void *data)
>> > +{
>> > +  struct cdns_dsi *dsi = data;
>> > +  irqreturn_t ret = IRQ_NONE;
>> > +  u32 flag, ctl;
>> > +
>> > +  flag = readl(dsi->regs + DIRECT_CMD_STS_FLAG);
>> > +  if (flag) {
>> > +  ctl = readl(dsi->regs + DIRECT_CMD_STS_CTL);
>> > +  ctl &= ~flag;
>> > +  writel(ctl, dsi->regs + DIRECT_CMD_STS_CTL);  
>> 
>> Are you meant to just write flag to DIRECT_CMD_STS_CLEAR, maybe?
>
> Actually, I want to keep the status flag untouched, I'm just masking the
> interrupt to not be interrupted until the waiter has cleared the
> status flags.
>
> I'm doing that because the user may want to wait for several different
> events (error, done, timeout, ...), and I'm not doing the check in the
> interrupt handler. Instead, I'm just waking up the waiter and let him
> check the status flag himself.

Oh, OK.  That sounds good.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7 v2] drm/pl111: Add optional variant display en/disable callbacks

[Eric Anholt]

Linus Walleij  writes:

> The silcon and components around the PL111 may require some

"silicon"

Other than that, while I'm still a little concerned about exposing too
many DRM formats on these boards, I think this is all worth landing at
this point.  Series is:

Reviewed-by: Eric Anholt 

Thanks!


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Fix trace include path (v2)

[Tom St Denis]

On 01/09/17 01:48 PM, Thierry Reding wrote:

On Fri, Sep 01, 2017 at 12:14:23PM -0400, Tom St Denis wrote:

Signed-off-by: Tom St Denis 

(v2): Drop Makefile change too.
---
  drivers/gpu/drm/ttm/Makefile| 2 +-
  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Thierry Reding 



Alex when you pull this into your fdo tree can you add these (and 
Christians R-b)?  I already pushed it to our internal staging :-)


Cheers,
Tom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Fix trace include path (v2)

[Thierry Reding]

On Fri, Sep 01, 2017 at 12:14:23PM -0400, Tom St Denis wrote:
> Signed-off-by: Tom St Denis 
> 
> (v2): Drop Makefile change too.
> ---
>  drivers/gpu/drm/ttm/Makefile| 2 +-
>  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm: Make __drm_object_property_get_value() static

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:53:28PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Make __drm_object_property_get_value() static to fix the following
> sparse warning:
> drm_mode_object.c:250:5: warning: symbol '__drm_object_property_get_value' 
> was not declared. Should it be static?
> 
> Cc: Daniel Vetter 
> Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_mode_object.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm: Drop drm_get_link_status_name()

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:53:27PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> drm_get_link_status_name() isn't used so kill it.
> 
> Fixes the following sparse warning:
> drm_connector.c:618:1: warning: symbol 'drm_get_link_status_name' was not 
> declared. Should it be static?
> 
> Cc: Manasi Navare 
> Fixes: 40ee6fbef75f ("drm: Add a new connector atomic property for link 
> status")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_connector.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm: Add missing __user annotation to drm_syncobj_array_find()

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:53:26PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> 'user_handles' needs a __user annotation for fix the following sparse
> warning:
> drm_syncobj.c:813:37: warning: incorrect type in argument 2 (different 
> address spaces)
> drm_syncobj.c:813:37:expected void const [noderef] *from
> drm_syncobj.c:813:37:got void *user_handles
> drm_syncobj.c:875:38: warning: incorrect type in argument 2 (different 
> address spaces)
> drm_syncobj.c:875:38:expected void *user_handles
> drm_syncobj.c:875:38:got void [noderef] *
> drm_syncobj.c:908:38: warning: incorrect type in argument 2 (different 
> address spaces)
> drm_syncobj.c:908:38:expected void *user_handles
> drm_syncobj.c:908:38:got void [noderef] *
> drm_syncobj.c:941:38: warning: incorrect type in argument 2 (different 
> address spaces)
> drm_syncobj.c:941:38:expected void *user_handles
> drm_syncobj.c:941:38:got void [noderef] *
> 
> Cc: Jason Ekstrand 
> Fixes: 3e6fb72d6cef ("drm/syncobj: Add a syncobj_array_find helper")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm: Make syncobj import/export functions static

[Thierry Reding]

On Fri, Sep 01, 2017 at 07:53:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Fix the following sparse warnings by making functions static:
> drm_syncobj.c:420:5: warning: symbol 'drm_syncobj_import_sync_file_fence' was 
> not declared. Should it be static?
> drm_syncobj.c:441:5: warning: symbol 'drm_syncobj_export_sync_file' was not 
> declared. Should it be static?
> 
> Cc: Dave Airlie 
> Fixes: 3ee45a3b533a ("drm/syncobj: add sync_file interaction. (v1.2)")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/amd/amdgpu: Fix TRACE include path

[Tom St Denis]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index b1f97417241d..cef1a26deb2d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -417,5 +417,5 @@ TRACE_EVENT(amdgpu_ttm_bo_move,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/amd/amdgpu/
 #include 
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/ttm: Fix trace include path

[Tom St Denis]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
index 23279b9b8e64..715ce68b7b33 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
 #include 
 
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Fix trace include path (v2)

[Christian König]

Am 01.09.2017 um 18:15 schrieb Deucher, Alexander:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Tom St Denis
Sent: Friday, September 01, 2017 12:14 PM
To: amd-...@lists.freedesktop.org
Cc: StDenis, Tom; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: Fix trace include path (v2)

Signed-off-by: Tom St Denis 

(v2): Drop Makefile change too.

Reviewed-by: Alex Deucher 


Reviewed-by: Christian König 




---
  drivers/gpu/drm/ttm/Makefile| 2 +-
  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index fd3da00c0bf2..f0549eab73e6 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -1,7 +1,7 @@
  #
  # Makefile for the drm device driver.  This driver provides support for the

-ccflags-y := -Iinclude/drm -I$(src)/.
+ccflags-y := -Iinclude/drm
  ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h
b/drivers/gpu/drm/ttm/ttm_trace.h
index 23279b9b8e64..715ce68b7b33 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,

  /* This part must be outside protection */
  #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
  #include 

--
2.12.0

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm: Add missing __user annotation to drm_syncobj_array_find()

[ville . syrjala]

From: Ville Syrjälä 

'user_handles' needs a __user annotation for fix the following sparse
warning:
drm_syncobj.c:813:37: warning: incorrect type in argument 2 (different address 
spaces)
drm_syncobj.c:813:37:expected void const [noderef] *from
drm_syncobj.c:813:37:got void *user_handles
drm_syncobj.c:875:38: warning: incorrect type in argument 2 (different address 
spaces)
drm_syncobj.c:875:38:expected void *user_handles
drm_syncobj.c:875:38:got void [noderef] *
drm_syncobj.c:908:38: warning: incorrect type in argument 2 (different address 
spaces)
drm_syncobj.c:908:38:expected void *user_handles
drm_syncobj.c:908:38:got void [noderef] *
drm_syncobj.c:941:38: warning: incorrect type in argument 2 (different address 
spaces)
drm_syncobj.c:941:38:expected void *user_handles
drm_syncobj.c:941:38:got void [noderef] *

Cc: Jason Ekstrand 
Fixes: 3e6fb72d6cef ("drm/syncobj: Add a syncobj_array_find helper")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_syncobj.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 26d60615b4d4..fa03a1a51453 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -799,7 +799,7 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
 }
 
 static int drm_syncobj_array_find(struct drm_file *file_private,
- void *user_handles, uint32_t count_handles,
+ void __user *user_handles, uint32_t 
count_handles,
  struct drm_syncobj ***syncobjs_out)
 {
uint32_t i, *handles;
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm: Make __drm_object_property_get_value() static

[ville . syrjala]

From: Ville Syrjälä 

Make __drm_object_property_get_value() static to fix the following
sparse warning:
drm_mode_object.c:250:5: warning: symbol '__drm_object_property_get_value' was 
not declared. Should it be static?

Cc: Daniel Vetter 
Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_mode_object.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index 1055533792f3..7a1ea91d3343 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -247,8 +247,9 @@ int drm_object_property_set_value(struct drm_mode_object 
*obj,
 }
 EXPORT_SYMBOL(drm_object_property_set_value);
 
-int __drm_object_property_get_value(struct drm_mode_object *obj,
- struct drm_property *property, uint64_t *val)
+static int __drm_object_property_get_value(struct drm_mode_object *obj,
+  struct drm_property *property,
+  uint64_t *val)
 {
int i;
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm: Drop drm_get_link_status_name()

[ville . syrjala]

From: Ville Syrjälä 

drm_get_link_status_name() isn't used so kill it.

Fixes the following sparse warning:
drm_connector.c:618:1: warning: symbol 'drm_get_link_status_name' was not 
declared. Should it be static?

Cc: Manasi Navare 
Fixes: 40ee6fbef75f ("drm: Add a new connector atomic property for link status")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ba9f36cef68c..bb2e60f5feb6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -615,7 +615,6 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
{ DRM_MODE_LINK_STATUS_GOOD, "Good" },
{ DRM_MODE_LINK_STATUS_BAD, "Bad" },
 };
-DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: Make syncobj import/export functions static

[ville . syrjala]

From: Ville Syrjälä 

Fix the following sparse warnings by making functions static:
drm_syncobj.c:420:5: warning: symbol 'drm_syncobj_import_sync_file_fence' was 
not declared. Should it be static?
drm_syncobj.c:441:5: warning: symbol 'drm_syncobj_export_sync_file' was not 
declared. Should it be static?

Cc: Dave Airlie 
Fixes: 3ee45a3b533a ("drm/syncobj: add sync_file interaction. (v1.2)")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_syncobj.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0422b8c2c2e7..26d60615b4d4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -417,8 +417,8 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
*file_private,
return 0;
 }
 
-int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
-  int fd, int handle)
+static int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+ int fd, int handle)
 {
struct dma_fence *fence = sync_file_get_fence(fd);
struct drm_syncobj *syncobj;
@@ -438,8 +438,8 @@ int drm_syncobj_import_sync_file_fence(struct drm_file 
*file_private,
return 0;
 }
 
-int drm_syncobj_export_sync_file(struct drm_file *file_private,
-int handle, int *p_fd)
+static int drm_syncobj_export_sync_file(struct drm_file *file_private,
+   int handle, int *p_fd)
 {
int ret;
struct dma_fence *fence;
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vtables: Fix typo

[Ville Syrjälä]

On Fri, Sep 01, 2017 at 04:40:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The callback is named .atomic_check, not .atomc_check.
> 
> Signed-off-by: Thierry Reding 

For the series
Reviewed-by: Ville Syrjälä 

> ---
>  include/drm/drm_modeset_helper_vtables.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index c55cf3ff6847..16646c44b7df 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -314,7 +314,7 @@ struct drm_crtc_helper_funcs {
>* implementation in drm_atomic_helper_check().
>*
>* When using drm_atomic_helper_check_planes() this hook is called
> -  * after the _plane_helper_funcs.atomc_check hook for planes, which
> +  * after the _plane_helper_funcs.atomic_check hook for planes, which
>* allows drivers to assign shared resources requested by planes in this
>* callback here. For more complicated dependencies the driver can call
>* the provided check helpers multiple times until the computed state
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm: Use correct path to trace include

[Alex Deucher]

On Fri, Sep 1, 2017 at 11:02 AM, Christian König
 wrote:
> Am 01.09.2017 um 16:49 schrieb Thierry Reding:
>>
>> From: Thierry Reding 
>>
>> The header comment in include/trace/define_trace.h specifies that the
>> TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
>> rather than the trace file including it. Most instances get that wrong
>> and work around it by adding the $(src) directory to the include path.
>>
>> While this works, it is preferable to refer to the correct path to the
>> trace file in the first place and avoid any workaround.
>>
>> Signed-off-by: Thierry Reding 
>
>
> Actually I've recently wondered how to correctly do this since we send out a
> TTM patch for 4.13 which most likely gets this wrong as well.
>
> Thanks for pointing this out, patch #2 and #5 are Reviewed-by: Christian
> König 

Applied patches 2 and 5 to my tree.

Thanks!

Alex

>
> The rest is Acked-by: Christian König .
>
> Tom please check our TTM patch and if necessary provide a fix as well.
>
> Thanks,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/Makefile| 2 --
>>   drivers/gpu/drm/drm_trace.h | 2 +-
>>   2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index a8acc197dec3..f82d0faad690 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -44,8 +44,6 @@ drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) +=
>> drm_dp_aux_dev.o
>>   obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>>   obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
>>   -CFLAGS_drm_trace_points.o := -I$(src)
>> -
>>   obj-$(CONFIG_DRM) += drm.o
>>   obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>>   obj-$(CONFIG_DRM_ARM) += arm/
>> diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
>> index 14c5a777682e..16c64d067e67 100644
>> --- a/drivers/gpu/drm/drm_trace.h
>> +++ b/drivers/gpu/drm/drm_trace.h
>> @@ -61,5 +61,5 @@ TRACE_EVENT(drm_vblank_event_delivered,
>> /* This part must be outside protection */
>>   #undef TRACE_INCLUDE_PATH
>> -#define TRACE_INCLUDE_PATH .
>> +#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm
>>   #include 
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/syncobj: Mark up the fence as an RCU protected pointer

[Ville Syrjälä]

On Fri, Sep 01, 2017 at 03:57:06PM +0100, Chris Wilson wrote:
> We take advantage of that syncobj->fence is an RCU-protected pointer, and
> so sparse complains that it is lacking annotation.
> 
> Signed-off-by: Chris Wilson 
> ---
>  include/drm/drm_syncobj.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index c00fee539822..455660673259 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -49,7 +49,7 @@ struct drm_syncobj {
>* This field should not be used directly.  Use drm_syncobj_fence_get
>* and drm_syncobj_replace_fence instead.
>*/
> - struct dma_fence *fence;
> + struct dma_fence __rcu *fence;

drm_syncobj.c uses that pointer directly quite a bit which seems to
generate more sparse warnings.

Would something like this be needed (just typing stuff blindly here)?

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0422b8c2c2e7..1786787ecc30 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -106,7 +106,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct 
drm_syncobj *syncobj,
 * callback when a fence has already been set.
 */
if (syncobj->fence) {
-   *fence = dma_fence_get(syncobj->fence);
+   *fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
+
lockdep_is_held(>lock)));
ret = 1;
} else {
*fence = NULL;
@@ -168,8 +169,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
 
spin_lock(>lock);
 
-   old_fence = syncobj->fence;
-   syncobj->fence = fence;
+   old_fence = rcu_dereference_protected(syncobj->fence,
+ lockdep_is_held(>lock));
+   rcu_assign_pointer(syncobj->fence, fence);
 
if (fence != old_fence) {
list_for_each_entry_safe(cur, tmp, >cb_list, node) {
@@ -613,7 +615,8 @@ static void syncobj_wait_syncobj_func(struct drm_syncobj 
*syncobj,
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
 
/* This happens inside the syncobj lock */
-   wait->fence = dma_fence_get(syncobj->fence);
+   wait->fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
+ 
lockdep_is_held(>lock)));
wake_up_process(wait->task);
 }
 
-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99195

johnrory.odw...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #14 from johnrory.odw...@gmail.com ---
Michel, it's always been in the back of my mind that this was a hardware issue
because I couldn't get back to a stable system, no-one with similar hardware
has reported this exact issue and finally I just re-installed Windows 7 and I
am having all the same problems. This bug report can be closed

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/ttm: Fix trace include path (v2)

[Deucher, Alexander]

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Friday, September 01, 2017 12:14 PM
> To: amd-...@lists.freedesktop.org
> Cc: StDenis, Tom; dri-devel@lists.freedesktop.org
> Subject: [PATCH] drm/ttm: Fix trace include path (v2)
> 
> Signed-off-by: Tom St Denis 
> 
> (v2): Drop Makefile change too.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/Makefile| 2 +-
>  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
> index fd3da00c0bf2..f0549eab73e6 100644
> --- a/drivers/gpu/drm/ttm/Makefile
> +++ b/drivers/gpu/drm/ttm/Makefile
> @@ -1,7 +1,7 @@
>  #
>  # Makefile for the drm device driver.  This driver provides support for the
> 
> -ccflags-y := -Iinclude/drm -I$(src)/.
> +ccflags-y := -Iinclude/drm
>  ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
>   ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
>   ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
> diff --git a/drivers/gpu/drm/ttm/ttm_trace.h
> b/drivers/gpu/drm/ttm/ttm_trace.h
> index 23279b9b8e64..715ce68b7b33 100644
> --- a/drivers/gpu/drm/ttm/ttm_trace.h
> +++ b/drivers/gpu/drm/ttm/ttm_trace.h
> @@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,
> 
>  /* This part must be outside protection */
>  #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH .
> +#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
>  #include 
> 
> --
> 2.12.0
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: Fix trace include path (v2)

[Tom St Denis]

Signed-off-by: Tom St Denis 

(v2): Drop Makefile change too.
---
 drivers/gpu/drm/ttm/Makefile| 2 +-
 drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index fd3da00c0bf2..f0549eab73e6 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for the drm device driver.  This driver provides support for the
 
-ccflags-y := -Iinclude/drm -I$(src)/.
+ccflags-y := -Iinclude/drm
 ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
index 23279b9b8e64..715ce68b7b33 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
 #include 
 
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ttm: Fix trace include path

[Tom St Denis]

On 01/09/17 12:12 PM, Deucher, Alexander wrote:

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Tom St Denis
Sent: Friday, September 01, 2017 12:11 PM
To: amd-...@lists.freedesktop.org
Cc: StDenis, Tom; dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/ttm: Fix trace include path

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_trace.h
b/drivers/gpu/drm/ttm/ttm_trace.h
index 23279b9b8e64..715ce68b7b33 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,

  /* This part must be outside protection */
  #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
  #include 


I think you can drop the Makefile change as well.


Yup.

Tom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/ttm: Fix trace include path

[Deucher, Alexander]

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Friday, September 01, 2017 12:11 PM
> To: amd-...@lists.freedesktop.org
> Cc: StDenis, Tom; dri-devel@lists.freedesktop.org
> Subject: [PATCH 2/2] drm/ttm: Fix trace include path
> 
> Signed-off-by: Tom St Denis 
> ---
>  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_trace.h
> b/drivers/gpu/drm/ttm/ttm_trace.h
> index 23279b9b8e64..715ce68b7b33 100644
> --- a/drivers/gpu/drm/ttm/ttm_trace.h
> +++ b/drivers/gpu/drm/ttm/ttm_trace.h
> @@ -82,6 +82,6 @@ TRACE_EVENT(ttm_dma_unmap,
> 
>  /* This part must be outside protection */
>  #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH .
> +#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/ttm/
>  #include 

I think you can drop the Makefile change as well.

Alex

> 
> --
> 2.12.0
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm: Use correct path to trace include

[Tom St Denis]

On 01/09/17 11:02 AM, Christian König wrote:

Am 01.09.2017 um 16:49 schrieb Thierry Reding:

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 


Actually I've recently wondered how to correctly do this since we send 
out a TTM patch for 4.13 which most likely gets this wrong as well.


Thanks for pointing this out, patch #2 and #5 are Reviewed-by: Christian 
König 


The rest is Acked-by: Christian König .

Tom please check our TTM patch and if necessary provide a fix as well.


Hi Christian,

I'm sure we have it wrong and since I copied the TTM trace from the 
AMDGPU one I think that's wrong too.


I'll submit the necessary patch(es) shortly.

Cheers,
Tom



Thanks,
Christian.


---
  drivers/gpu/drm/Makefile    | 2 --
  drivers/gpu/drm/drm_trace.h | 2 +-
  2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a8acc197dec3..f82d0faad690 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -44,8 +44,6 @@ drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += 
drm_dp_aux_dev.o

  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
-CFLAGS_drm_trace_points.o := -I$(src)
-
  obj-$(CONFIG_DRM)    += drm.o
  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
  obj-$(CONFIG_DRM_ARM)    += arm/
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 14c5a777682e..16c64d067e67 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -61,5 +61,5 @@ TRACE_EVENT(drm_vblank_event_delivered,
  /* This part must be outside protection */
  #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm
  #include 





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/scdc-helper: Remove gratuitous blank lines

[Ville Syrjälä]

On Fri, Sep 01, 2017 at 04:44:28PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> It's unusual to separate kerneldoc comments from the functions that they
> describe by a blank line. Remove them.
> 
> Signed-off-by: Thierry Reding 

Series lgtm
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_scdc_helper.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> index 935653eb3616..d66c436a829e 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -134,7 +134,6 @@ EXPORT_SYMBOL(drm_scdc_write);
>   * Returns:
>   * True if the scrambling is enabled, false otherwise.
>   */
> -
>  bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
>  {
>   u8 status;
> @@ -162,7 +161,6 @@ EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
>   * Returns:
>   * True if scrambling is set/reset successfully, false otherwise.
>   */
> -
>  bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
>  {
>   u8 config;
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102507] WARNING: CPU: 1 PID: 336 at drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70 [drm]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102507

--- Comment #4 from Dieter Nützel  ---
This one is related, too:

https://lists.freedesktop.org/archives/amd-gfx/2017-August/012558.html

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102507] WARNING: CPU: 1 PID: 336 at drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70 [drm]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102507

--- Comment #3 from Dieter Nützel  ---
(In reply to Vedran Miletić from comment #2)
> Found it:
> https://lists.freedesktop.org/archives/amd-gfx/2017-August/012283.html
> 
> Guess I should subscribe to one more list. :-)

Maybe or I _should_ make better bug reports in the beginning...;-)

Greetings,
Dieter

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

[Marek Olšák]

On Thu, Jul 6, 2017 at 3:17 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds kernel semaphore support to the command submission
> interface in what should be a backwards compatible manner,
> it adds a new command submission API.
>
> Signed-off-by: Dave Airlie 
> ---
>  amdgpu/amdgpu.h|  29 -
>  amdgpu/amdgpu_cs.c | 118 
> +
>  2 files changed, 138 insertions(+), 9 deletions(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 1901fa8..649b66e 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -369,6 +369,16 @@ struct amdgpu_cs_request {
> struct amdgpu_cs_fence_info fence_info;
>  };
>
> +struct amdgpu_cs_request_syncobj {
> +   /*
> +*
> +*/

Did you mean to fill in the comment here?

Also, is this interface relevant with the raw CS API?

Marek

> +   uint32_t number_in_syncobj;
> +   uint32_t number_out_syncobj;
> +   uint32_t *in_syncobj;
> +   uint32_t *out_syncobj;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102500

--- Comment #4 from Dieter Nützel  ---
(In reply to Alex Deucher from comment #1)
> can you bisect?

Hello all,

I get the same on 'amd-staging-drm-next' since 1. of Sep (kernel build time: 1.
Sep 02:14 CEST) update, too. Will go to bisect in the evening.

[  262.462941] amdgpu :01:00.0: GPU fault detected: 146 0x0a023d14
[  262.462946] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00101540
[  262.462949] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0903D014
[  262.462952] amdgpu :01:00.0: VM fault (0x14, vmid 4) at page 1054016,
write from 'SDM1' (0x53
444d31) (61)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102507] WARNING: CPU: 1 PID: 336 at drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70 [drm]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102507

Vedran Miletić  changed:

   What|Removed |Added

URL||https://lists.freedesktop.o
   ||rg/archives/amd-gfx/2017-Au
   ||gust/012283.html

--- Comment #2 from Vedran Miletić  ---
Found it:
https://lists.freedesktop.org/archives/amd-gfx/2017-August/012283.html

Guess I should subscribe to one more list. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102507] WARNING: CPU: 1 PID: 336 at drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70 [drm]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102507

--- Comment #1 from Dieter Nützel  ---
I've reported this 2 times to amd-gfx-devel (Alex, Harry et al.) in the last
several days. Was '[amd-staging-drm-next] kernel crash with amdgpu on RX580 in
'drm_object_property_get_value'.

Should be 'drm_object_property_[get|set]_value'.

Yes, it is _NO_ crash only warning (my bad) and it is _WORKED_ on.

Here comes what Alex mailed me about:

>> Was:
>> [amd-staging-drm-next] kernel crash with amdgpu on RX580 in
>> 'drm_object_property_get_value'
>>
>> I get this in _all_ current 'amd-staging-drm-next' versions. ;-(
>>
> It's not a crash, just a warning.  It's due to a recent change in the
> drm core, but we haven't gotten around to sorting it out yet.
> Alex

Greetings,
Dieter

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm: Use correct path to trace include

[Christian König]

Am 01.09.2017 um 16:49 schrieb Thierry Reding:

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 


Actually I've recently wondered how to correctly do this since we send 
out a TTM patch for 4.13 which most likely gets this wrong as well.


Thanks for pointing this out, patch #2 and #5 are Reviewed-by: Christian 
König 


The rest is Acked-by: Christian König .

Tom please check our TTM patch and if necessary provide a fix as well.

Thanks,
Christian.


---
  drivers/gpu/drm/Makefile| 2 --
  drivers/gpu/drm/drm_trace.h | 2 +-
  2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a8acc197dec3..f82d0faad690 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -44,8 +44,6 @@ drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += 
drm_dp_aux_dev.o
  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
  
-CFLAGS_drm_trace_points.o := -I$(src)

-
  obj-$(CONFIG_DRM) += drm.o
  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
  obj-$(CONFIG_DRM_ARM) += arm/
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 14c5a777682e..16c64d067e67 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -61,5 +61,5 @@ TRACE_EVENT(drm_vblank_event_delivered,
  
  /* This part must be outside protection */

  #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm
  #include 



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] dma-buf/fence: Sparse wants __rcu on the object itself

[Chris Wilson]

In order to silent sparse in dma_fence_get_rcu_safe(), we need to mark
the incoming fence object as being RCU protected and not the pointer to
the object.

Signed-off-by: Chris Wilson 
---
 include/linux/dma-fence.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 171895072435..bad861f8f914 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -242,7 +242,7 @@ static inline struct dma_fence *dma_fence_get_rcu(struct 
dma_fence *fence)
  * The caller is required to hold the RCU read lock.
  */
 static inline struct dma_fence *
-dma_fence_get_rcu_safe(struct dma_fence * __rcu *fencep)
+dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep)
 {
do {
struct dma_fence *fence;
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/syncobj: Mark up the fence as an RCU protected pointer

[Chris Wilson]

We take advantage of that syncobj->fence is an RCU-protected pointer, and
so sparse complains that it is lacking annotation.

Signed-off-by: Chris Wilson 
---
 include/drm/drm_syncobj.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index c00fee539822..455660673259 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -49,7 +49,7 @@ struct drm_syncobj {
 * This field should not be used directly.  Use drm_syncobj_fence_get
 * and drm_syncobj_replace_fence instead.
 */
-   struct dma_fence *fence;
+   struct dma_fence __rcu *fence;
/**
 * @cb_list:
 * List of callbacks to call when the fence gets replaced
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/6] drm/amdgpu: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/amd/amdgpu/Makefile   | 2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 658bac0cdc5e..25a95c95df14 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -133,5 +133,3 @@ include $(FULL_AMD_PATH)/powerplay/Makefile
 amdgpu-y += $(AMD_POWERPLAY_FILES)
 
 obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
-
-CFLAGS_amdgpu_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 1c88bd5e29ad..0ee2c97ae79e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -473,5 +473,5 @@ TRACE_EVENT(amdgpu_ttm_bo_move,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/amd/amdgpu
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/vc4: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/vc4/Makefile| 2 --
 drivers/gpu/drm/vc4/vc4_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index 25bd5d30415d..719a771f3d5c 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -24,5 +24,3 @@ vc4-y := \
 vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
 
 obj-$(CONFIG_DRM_VC4)  += vc4.o
-
-CFLAGS_vc4_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/vc4/vc4_trace.h b/drivers/gpu/drm/vc4/vc4_trace.h
index ad7b1ea720c2..deafb32923e1 100644
--- a/drivers/gpu/drm/vc4/vc4_trace.h
+++ b/drivers/gpu/drm/vc4/vc4_trace.h
@@ -59,5 +59,5 @@ TRACE_EVENT(vc4_wait_for_seqno_end,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/vc4
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] drm/armada: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/armada/Makefile   | 2 --
 drivers/gpu/drm/armada/armada_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
index 64c0b4546fb2..a18f156c8b66 100644
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -4,5 +4,3 @@ armada-y+= armada_510.o
 armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
 
 obj-$(CONFIG_DRM_ARMADA) := armada.o
-
-CFLAGS_armada_trace.o := -I$(src)
diff --git a/drivers/gpu/drm/armada/armada_trace.h 
b/drivers/gpu/drm/armada/armada_trace.h
index dc0cba70fd1a..be245a24610f 100644
--- a/drivers/gpu/drm/armada/armada_trace.h
+++ b/drivers/gpu/drm/armada/armada_trace.h
@@ -62,5 +62,5 @@ TRACE_EVENT(armada_ovl_plane_work,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/armada
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm/radeon: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/radeon/Makefile   | 2 --
 drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 4acbb944bcd2..be16c6390216 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -109,5 +109,3 @@ radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
 radeon-$(CONFIG_ACPI) += radeon_acpi.o
 
 obj-$(CONFIG_DRM_RADEON)+= radeon.o
-
-CFLAGS_radeon_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index fdce4062901f..815eaa8c394b 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -204,5 +204,5 @@ DEFINE_EVENT(radeon_semaphore_request, 
radeon_semaphore_wait,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/radeon
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/6] drm/i915: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/i915/Makefile | 2 --
 drivers/gpu/drm/i915/i915_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 892f52b53060..1cb8059a3a16 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,5 +150,3 @@ endif
 i915-y += intel_lpe_audio.o
 
 obj-$(CONFIG_DRM_I915) += i915.o
-
-CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index b24a83d43559..8794c198f877 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -1031,5 +1031,5 @@ TRACE_EVENT(switch_mm,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/i915
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] drm: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding 

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/Makefile| 2 --
 drivers/gpu/drm/drm_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a8acc197dec3..f82d0faad690 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -44,8 +44,6 @@ drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += 
drm_dp_aux_dev.o
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
 
-CFLAGS_drm_trace_points.o := -I$(src)
-
 obj-$(CONFIG_DRM)  += drm.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_ARM)  += arm/
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 14c5a777682e..16c64d067e67 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -61,5 +61,5 @@ TRACE_EVENT(drm_vblank_event_delivered,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm
 #include 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/scdc-helper: Use consistent spelling for TMDS

[Thierry Reding]

From: Thierry Reding 

The file uses inconsistent capitalization for TMDS. Since it is an
abbreviation, all uppercase is correct.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_scdc_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 5e6f0709df49..657ea5ab6c3f 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, 
bool enable)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read tmds config: %d\n", ret);
+   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
return false;
}
 
@@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter 
*adapter, bool set)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read tmds config: %d\n", ret);
+   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
return false;
}
 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/scdc-helper: Use consistent error reporting

[Thierry Reding]

From: Thierry Reding 

The error messages generated by the SCDC helpers are somewhat
inconsistent with other DRM errors and even with other errors in the
same file. Fix them all up to use a common format.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_scdc_helper.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index d66c436a829e..5e6f0709df49 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -141,7 +141,7 @@ bool drm_scdc_get_scrambling_status(struct i2c_adapter 
*adapter)
 
ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
if (ret < 0) {
-   DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+   DRM_ERROR("Failed to read scrambling status: %d\n", ret);
return false;
}
 
@@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, 
bool enable)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read tmds config, err=%d\n", ret);
+   DRM_ERROR("Failed to read tmds config: %d\n", ret);
return false;
}
 
@@ -179,7 +179,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, 
bool enable)
 
ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
if (ret < 0) {
-   DRM_ERROR("Failed to enable scrambling, error %d\n", ret);
+   DRM_ERROR("Failed to enable scrambling: %d\n", ret);
return false;
}
 
@@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter 
*adapter, bool set)
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_ERROR("Failed to read tmds config, err=%d\n", ret);
+   DRM_ERROR("Failed to read tmds config: %d\n", ret);
return false;
}
 
@@ -234,7 +234,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter 
*adapter, bool set)
 
ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
if (ret < 0) {
-   DRM_ERROR("Failed to set TMDS clock ratio, error %d\n", ret);
+   DRM_ERROR("Failed to set TMDS clock ratio: %d\n", ret);
return false;
}
 
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/scdc-helper: Remove gratuitous blank lines

[Thierry Reding]

From: Thierry Reding 

It's unusual to separate kerneldoc comments from the functions that they
describe by a blank line. Remove them.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_scdc_helper.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 935653eb3616..d66c436a829e 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -134,7 +134,6 @@ EXPORT_SYMBOL(drm_scdc_write);
  * Returns:
  * True if the scrambling is enabled, false otherwise.
  */
-
 bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
 {
u8 status;
@@ -162,7 +161,6 @@ EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
  * Returns:
  * True if scrambling is set/reset successfully, false otherwise.
  */
-
 bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
 {
u8 config;
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/vtables: Fix typo

[Thierry Reding]

From: Thierry Reding 

The callback is named .atomic_check, not .atomc_check.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_modeset_helper_vtables.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index c55cf3ff6847..16646c44b7df 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -314,7 +314,7 @@ struct drm_crtc_helper_funcs {
 * implementation in drm_atomic_helper_check().
 *
 * When using drm_atomic_helper_check_planes() this hook is called
-* after the _plane_helper_funcs.atomc_check hook for planes, which
+* after the _plane_helper_funcs.atomic_check hook for planes, which
 * allows drivers to assign shared resources requested by planes in this
 * callback here. For more complicated dependencies the driver can call
 * the provided check helpers multiple times until the computed state
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/atomic: Fix typo in kerneldoc

[Thierry Reding]

From: Thierry Reding 

The for_each_crtc_in_state() is used to iterate over CRTCs rather than
connectors.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_atomic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 8a5808eb5628..f73b663c1f76 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -643,7 +643,7 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
for_each_if (connector)
 
 /**
- * for_each_crtc_in_state - iterate over all connectors in an atomic update
+ * for_each_crtc_in_state - iterate over all CRTCs in an atomic update
  * @__state:  drm_atomic_state pointer
  * @crtc:  drm_crtc iteration cursor
  * @crtc_state:  drm_crtc_state iteration cursor
-- 
2.13.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/bridge/synopsys: dsi: explicitly request exclusive reset control

[Andrzej Hajda]

On 01.08.2017 15:23, Philippe CORNU wrote:
> Based on patch "Convert drivers to explicit reset API" from Philipp Zabel
>
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
>
> No functional changes.
>
> Cc: Philipp Zabel 
> Signed-off-by: Philippe CORNU 
> Acked-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 781340d..4e1f91e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -885,15 +885,11 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
> *bridge)
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
>*/
> - apb_rst = devm_reset_control_get(dev, "apb");
> + apb_rst = devm_reset_control_get_optional_exclusive(dev, "apb");
>   if (IS_ERR(apb_rst)) {
>   ret = PTR_ERR(apb_rst);
> - if (ret == -ENOENT) {
> - apb_rst = NULL;
> - } else {
> - dev_err(dev, "Unable to get reset control: %d\n", ret);
> - return ERR_PTR(ret);
> - }
> + dev_err(dev, "Unable to get reset control: %d\n", ret);

I think in case of deferred probing it shouldn't be dev_err, but this is
rather suggestion.

> + return ERR_PTR(ret);
  
return apb_rst;

With this fixed:
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

>   }
>  
>   if (apb_rst) {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vblank: Fix delta_ns to an absolute value

[Ville Syrjälä]

On Fri, Sep 01, 2017 at 04:07:16PM +0900, Hoegeun Kwon wrote:
> If scanout started, we should reduce etime by delta_ns. But delta_ns
> is negative if scanout has not started. If delta_ns is negative,
> subtraction of delta_ns from etime increases etime. This is wrong, the
> etime should not be increased, so you have to make delta_ns an
> absolute value.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
> 
> Hello all,
> 
> I think that the etime should not be increased.
> In cases where delta_ns is negative, if you get time again after an
> interrupt call, there is a problem that the time obtained from the
> interrupt becomes the future time instead of the past time.
> 
> Please let me know if this patch is wrong.

It is wrong. The timestamp corresponds to the first active pixel of the
frame/field. So while between vblank start and active start we expect
to get a timestamp that is in the future.

> 
> Best regards,
> Hoegeun
> 
>  drivers/gpu/drm/drm_vblank.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 70f2b95..a3e0176 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -684,7 +684,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
> drm_device *dev,
>   /* Subtract time delta from raw timestamp to get final
>* vblank_time timestamp for end of vblank.
>*/
> - etime = ktime_sub_ns(etime, delta_ns);
> + etime = ktime_sub_ns(etime, abs(delta_ns));
>   *vblank_time = ktime_to_timeval(etime);
>  
>   DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
> rep]\n",
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm/bridge/synopsys: dsi: Register list clean up

[Andrzej Hajda]

On 01.08.2017 15:23, Philippe CORNU wrote:
> This patch cleans up the Synopsys mipi dsi register list:
> - rename registers according to the Synopsys documentation
>   (1.30 & 1.31)
> - fix typos
> - re-order registers for a better coherency
>
> Signed-off-by: Philippe CORNU 
> Reviewed-by: Laurent Pinchart 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm/bridge/synopsys: dsi: Constify funcs structures

[Andrzej Hajda]

On 01.08.2017 15:23, Philippe CORNU wrote:
> Constify dw_mipi_dsi_bridge_funcs as these functions are not supposed
> to change at runtime.
>
> Signed-off-by: Philippe CORNU 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 36f5ccb..63c7a01 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -811,7 +811,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
> *bridge)
>   return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge);
>  }
>  
> -static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
> +static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
>   .mode_set = dw_mipi_dsi_bridge_mode_set,
>   .enable   = dw_mipi_dsi_bridge_enable,
>   .post_disable = dw_mipi_dsi_bridge_post_disable,

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 5/7] drm/omap: Do dss_device (display) ordering in omap_drv.c

[Laurent Pinchart]

Hi Peter,

Thank  you for the patch.

On Tuesday, 29 August 2017 10:32:16 EEST Peter Ujfalusi wrote:
> Sort the dssdev array based on DT aliases.
> 
> With this change we can remove the panel ordering from dss/display.c and
> have all sorting related to dssdevs in one place.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 32dc0e88220f..0e100a359d26
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -18,6 +18,8 @@
>   */
> 
>  #include 
> +#include 
> +#include 

Please keep this list alphabetically sorted.

>  #include 
>  #include 
> @@ -162,6 +164,22 @@ static void omap_disconnect_dssdevs(struct drm_device
> *ddev) priv->num_dssdevs = 0;
>  }
> 
> +static int omap_compare_dssdevs(const void *a, const void *b)
> +{
> + const struct omap_dss_device *dssdev1 = *(struct omap_dss_device **)a;
> + const struct omap_dss_device *dssdev2 = *(struct omap_dss_device **)b;
> + int  id1, id2;
> +
> + id1 = of_alias_get_id(dssdev1->dev->of_node, "display");
> + id2 = of_alias_get_id(dssdev2->dev->of_node, "display");

Getting the alias id is a bit costly, how about caching them ?

> + if (id1 > id2)
> + return 1;
> + else if (id1 < id2)
> + return -1;
> + return 0;
> +}
> +
>  static void omap_collect_dssdevs(struct drm_device *ddev)
>  {
>   struct omap_drm_private *priv = ddev->dev_private;
> @@ -176,6 +194,10 @@ static void omap_collect_dssdevs(struct drm_device
> *ddev) break;
>   }
>   }
> +
> + /* Sort the list by DT aliases */
> + sort(priv->dssdevs, priv->num_dssdevs, sizeof(priv->dssdevs[0]),
> +  omap_compare_dssdevs, NULL);
>  }
> 
>  static int omap_connect_dssdevs(struct drm_device *ddev)


-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Laurent Pinchart]

Hi Peter,

On Tuesday, 29 August 2017 10:32:11 EEST Peter Ujfalusi wrote:
> Hi
> 
> The series adds support for changing the order of the displays defined by DT
> display aliases.
> 
> The motivation to do such a thing is that for example the fb emulation is
> treating the first display/crtc as the 'main' display and will create the
> fb emulation based on the first display's properties.
> There are many custom applications using DRM directly and they assume that
> the first connector is the 'main' display.
> Afaik weston provides no means either to change the 'main/preferred'
> display.
> 
> It should be the work of user space application (except the fb emulation) to
> somehow deal with the 'main' display selection for their needs, but
> unfortunately they are not capable of diong so for some reason.
> 
> We have boards with LCD panel and HDMI for example and in DT the LCD is set
> as display0, but in certain useage scenarios it is desired to have the HDMI
> as the 'main' display instead of the LCD.

One could argue that the DT should then be updated. The device tree is a 
description of the whole system, not just the board. If a board is integrated 
in a system that makes HDMI the primary display, it would make sense for DT to 
reflect that.

> With the kernel cmd line parameter it is possible to change the pre defined
> order without recompiling the kernel/DT.
> 
> If the board have two active displays:
> 0 - LCD
> 1 - HDMI
> then:
> omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
> omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
> omapdrm.displays=0 - only the LCD is enabled
> omapdrm.displays=1 - only the HDMI is enabled
> omapdrm.displays=-1 - disable all displays
> 
> The first 6 patch of the series is doing some generic clean up and prepares
> the code so the display ordering is going to be easy to add.

This will conflict with the work I'm doing on merging the omapdrm and omapdss 
driver, so I'm a bit reluctant to merge this first :-/ In particular, with the 
two drivers merged, couldn't we implement this module parameter without moving 
the display sorting from omapdss to omapdrm ?

> ---
> Peter Ujfalusi (7):
>   drm/omap: Use devm_kzalloc() to allocate omap_drm_private
>   drm/omap: Allocate drm_device earlier and unref it as last step
>   drm/omap: Manage the usable omap_dss_device list within
> omap_drm_private
>   drm/omap: Separate the dssdevs array setup from the connect function
>   drm/omap: Do dss_device (display) ordering in omap_drv.c
>   drm/omap: dss: Remove display ordering from dss/display.c
>   drm/omap: Add kernel parameter to specify the desired display order
> 
>  drivers/gpu/drm/omapdrm/dss/display.c |  15 +--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   3 -
>  drivers/gpu/drm/omapdrm/omap_drv.c| 244 +--
>  drivers/gpu/drm/omapdrm/omap_drv.h|   3 +
>  4 files changed, 183 insertions(+), 82 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/7] drm/omap: Manage the usable omap_dss_device list within omap_drm_private

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Tuesday, 29 August 2017 10:32:14 EEST Peter Ujfalusi wrote:
> Instead of reaching back to DSS to iterate through the dss_devices every
> time, use an internal array where we store the available and usable
> dss_devices.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 95 +--
>  drivers/gpu/drm/omapdrm/omap_drv.h |  3 ++
>  2 files changed, 62 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index bd7fe317a365..b089604e871c
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -146,18 +146,27 @@ static int get_connector_type(struct omap_dss_device
> *dssdev) }
>  }
> 
> -static void omap_disconnect_dssdevs(void)
> +static void omap_disconnect_dssdevs(struct drm_device *ddev)
>  {
> - struct omap_dss_device *dssdev = NULL;
> + struct omap_drm_private *priv = ddev->dev_private;
> + int i;
> +
> + for (i = 0; i < priv->num_dssdevs; i++) {

is is never negative, you can make it an unsigned int. This comment applies 
through the whole patch.

> + struct omap_dss_device *dssdev = priv->dssdevs[i];
> 
> - for_each_dss_dev(dssdev)
>   dssdev->driver->disconnect(dssdev);
> + priv->dssdevs[i] = NULL;
> + omap_dss_put_device(dssdev);
> + }
> +
> + priv->num_dssdevs = 0;
>  }
> 
> -static int omap_connect_dssdevs(void)
> +static int omap_connect_dssdevs(struct drm_device *ddev)
>  {
> - int r;
> + struct omap_drm_private *priv = ddev->dev_private;
>   struct omap_dss_device *dssdev = NULL;
> + int r;
> 
>   if (!omapdss_stack_is_ready())
>   return -EPROBE_DEFER;
> @@ -170,6 +179,14 @@ static int omap_connect_dssdevs(void)
>   } else if (r) {
>   dev_warn(dssdev->dev, "could not connect display: %s\n",
>   dssdev->name);
> + } else {
> + omap_dss_get_device(dssdev);
> + priv->dssdevs[priv->num_dssdevs++] = dssdev;
> + if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
> + /* To balance the 'for_each_dss_dev' loop */
> + omap_dss_put_device(dssdev);
> + break;
> + }
>   }
>   }
> 
> @@ -180,7 +197,7 @@ static int omap_connect_dssdevs(void)
>* if we are deferring probe, we disconnect the devices we previously
>* connected
>*/
> - omap_disconnect_dssdevs();
> + omap_disconnect_dssdevs(ddev);
> 
>   return r;
>  }
> @@ -205,7 +222,7 @@ static int omap_modeset_init(struct drm_device *dev)
>   int num_ovls = priv->dispc_ops->get_num_ovls();
>   int num_mgrs = priv->dispc_ops->get_num_mgrs();
>   int num_crtcs, crtc_idx, plane_idx;
> - int ret;
> + int ret, i;
>   u32 plane_crtc_mask;
> 
>   drm_mode_config_init(dev);
> @@ -222,11 +239,7 @@ static int omap_modeset_init(struct drm_device *dev)
>* configuration does not match the expectations or exceeds
>* the available resources, the configuration is rejected.
>*/
> - num_crtcs = 0;
> - for_each_dss_dev(dssdev)
> - if (omapdss_device_is_connected(dssdev))
> - num_crtcs++;
> -
> + num_crtcs = priv->num_dssdevs;
>   if (num_crtcs > num_mgrs || num_crtcs > num_ovls ||
>   num_crtcs > ARRAY_SIZE(priv->crtcs) ||
>   num_crtcs > ARRAY_SIZE(priv->planes) ||
> @@ -244,15 +257,13 @@ static int omap_modeset_init(struct drm_device *dev)
> 
>   crtc_idx = 0;
>   plane_idx = 0;
> - for_each_dss_dev(dssdev) {
> + for (i = 0; i < priv->num_dssdevs; i++) {
> + struct omap_dss_device *dssdev = priv->dssdevs[i];
>   struct drm_connector *connector;
>   struct drm_encoder *encoder;
>   struct drm_plane *plane;
>   struct drm_crtc *crtc;
> 
> - if (!omapdss_device_is_connected(dssdev))
> - continue;
> -

I believe this hunk is correct as dss devices are only disconnected by calls 
to the oma_dss_driver .disconnect() operation, which is only called from 
omap_disconnect_dssdevs(), but you should at the very least explain why in the 
commit message.

>   encoder = omap_encoder_init(dev, dssdev);
>   if (!encoder)
>   return -ENOMEM;
> @@ -326,11 +337,14 @@ static int omap_modeset_init(struct drm_device *dev)
>  /*
>   * Enable the HPD in external components if supported
>   */
> -static void omap_modeset_enable_external_hpd(void)
> +static void omap_modeset_enable_external_hpd(struct drm_device *ddev)
>  {
> - struct omap_dss_device *dssdev = NULL;
> + struct omap_drm_private *priv = 

Re: [RFC 2/7] drm/omap: Allocate drm_device earlier and unref it as last step

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Tuesday, 29 August 2017 10:32:13 EEST Peter Ujfalusi wrote:
> If we allocate the drm_device earlier we can just return the error code
> without the need to use goto.
> Do the unref of the drm_device as a last step when cleaning up. This will
> make the drm_device available longer for us and makes sure that we only
> free up the memory when all other cleanups have been already done.
> 
> Signed-off-by: Peter Ujfalusi 

Pending a new version due to patch 1/7 not being correct,

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 29 +
>  1 file changed, 13 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 903510d8054e..bd7fe317a365
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -552,6 +552,14 @@ static int pdev_probe(struct platform_device *pdev)
>   if (!priv)
>   return -ENOMEM;
> 
> + /* Allocate and initialize the DRM device. */
> + ddev = drm_dev_alloc(_drm_driver, >dev);
> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
> +
> + ddev->dev_private = priv;
> + platform_set_drvdata(pdev, ddev);
> +
>   omap_crtc_pre_init();
> 
>   ret = omap_connect_dssdevs();
> @@ -568,22 +576,12 @@ static int pdev_probe(struct platform_device *pdev)
>   spin_lock_init(>list_lock);
>   INIT_LIST_HEAD(>obj_list);
> 
> - /* Allocate and initialize the DRM device. */
> - ddev = drm_dev_alloc(_drm_driver, >dev);
> - if (IS_ERR(ddev)) {
> - ret = PTR_ERR(ddev);
> - goto err_destroy_wq;
> - }
> -
> - ddev->dev_private = priv;
> - platform_set_drvdata(pdev, ddev);
> -
>   omap_gem_init(ddev);
> 
>   ret = omap_modeset_init(ddev);
>   if (ret) {
>   dev_err(>dev, "omap_modeset_init failed: ret=%d\n", ret);
> - goto err_free_drm_dev;
> + goto err_gem_deinit;
>   }
> 
>   /* Initialize vblank handling, start with all CRTCs disabled. */
> @@ -619,14 +617,13 @@ static int pdev_probe(struct platform_device *pdev)
>  err_cleanup_modeset:
>   drm_mode_config_cleanup(ddev);
>   omap_drm_irq_uninstall(ddev);
> -err_free_drm_dev:
> +err_gem_deinit:
>   omap_gem_deinit(ddev);
> - drm_dev_unref(ddev);
> -err_destroy_wq:
>   destroy_workqueue(priv->wq);
>   omap_disconnect_dssdevs();
>  err_crtc_uninit:
>   omap_crtc_pre_uninit();
> + drm_dev_unref(ddev);
>   return ret;
>  }
> 
> @@ -652,13 +649,13 @@ static int pdev_remove(struct platform_device *pdev)
>   omap_drm_irq_uninstall(ddev);
>   omap_gem_deinit(ddev);
> 
> - drm_dev_unref(ddev);
> -
>   destroy_workqueue(priv->wq);
> 
>   omap_disconnect_dssdevs();
>   omap_crtc_pre_uninit();
> 
> + drm_dev_unref(ddev);
> +
>   return 0;
>  }


-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/7] drm/omap: Use devm_kzalloc() to allocate omap_drm_private

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Tuesday, 29 August 2017 10:32:12 EEST Peter Ujfalusi wrote:
> It makes the cleanup paths a bit cleaner.

But it also goes against a proper implementation of object lifetime management 
:-( In DRM driver private structures are accessible from file operations, and 
must thus be reference-counted and only freed when the last userspace user 
goes away. This may be after the devm_* resources are released right after the 
.remove() operation is called. Using devm_kzalloc() would thus make it 
impossible to properly reference-count our data structures.

> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 9b3c36b48356..903510d8054e
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -548,19 +548,17 @@ static int pdev_probe(struct platform_device *pdev)
>   return ret;
>   }
> 
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
>   omap_crtc_pre_init();
> 
>   ret = omap_connect_dssdevs();
>   if (ret)
>   goto err_crtc_uninit;
> 
> - /* Allocate and initialize the driver private structure. */
> - priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - if (!priv) {
> - ret = -ENOMEM;
> - goto err_disconnect_dssdevs;
> - }
> -
> + /* Initialize the driver private structure. */
>   priv->dispc_ops = dispc_get_ops();
> 
>   soc = soc_device_match(omapdrm_soc_devices);
> @@ -574,7 +572,7 @@ static int pdev_probe(struct platform_device *pdev)
>   ddev = drm_dev_alloc(_drm_driver, >dev);
>   if (IS_ERR(ddev)) {
>   ret = PTR_ERR(ddev);
> - goto err_free_priv;
> + goto err_destroy_wq;
>   }
> 
>   ddev->dev_private = priv;
> @@ -624,10 +622,8 @@ static int pdev_probe(struct platform_device *pdev)
>  err_free_drm_dev:
>   omap_gem_deinit(ddev);
>   drm_dev_unref(ddev);
> -err_free_priv:
> +err_destroy_wq:
>   destroy_workqueue(priv->wq);
> - kfree(priv);
> -err_disconnect_dssdevs:
>   omap_disconnect_dssdevs();
>  err_crtc_uninit:
>   omap_crtc_pre_uninit();
> @@ -659,7 +655,6 @@ static int pdev_remove(struct platform_device *pdev)
>   drm_dev_unref(ddev);
> 
>   destroy_workqueue(priv->wq);
> - kfree(priv);
> 
>   omap_disconnect_dssdevs();
>   omap_crtc_pre_uninit();


-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM Format Modifiers in v4l2

[Rob Clark]

On Fri, Sep 1, 2017 at 3:13 AM, Laurent Pinchart
 wrote:
> Hi Nicolas,
>
> On Thursday, 31 August 2017 19:12:58 EEST Nicolas Dufresne wrote:
>> Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit :
>> >> e.g. if I have two devices which support MODIFIER_FOO, I could attempt
>> >> to share a buffer between them which uses MODIFIER_FOO without
>> >> necessarily knowing exactly what it is/does.
>> >
>> > Userspace could certainly set modifiers blindly, but the point of
>> > modifiers is to generate side effects benefitial to the use case at hand
>> > (for instance by optimizing the memory access pattern). To use them
>> > meaningfully userspace would need to have at least an idea of the side
>> > effects they generate.
>>
>> Generic userspace will basically pick some random combination.
>
> In that case userspace could set no modifier at all by default (except in the
> case where unmodified formats are not supported by the hardware, but I don't
> expect that to be the most common case).
>
>> To allow generically picking the optimal configuration we could indeed rely
>> on the application knowledge, but we could also enhance the spec so that
>> the order in the enumeration becomes meaningful.
>
> I'm not sure how far we should go. I could imagine a system where the API
> would report capabilities for modifiers (e.g. this modifier lowers the
> bandwidth, this one enhances the quality, ...), but going in that direction,
> where do we stop ? In practice I expect userspace to know some information
> about the hardware, so I'd rather avoid over-engineering the API.
>

I think in the (hopefully not too) long term, something like
https://github.com/cubanismo/allocator/ is the way forward.  That
doesn't quite solve how v4l2 kernel part sorts out w/ corresponding
userspace .so what is preferable, but at least that is
compartmentalized to v4l2.. on the gl/vk side of things there will ofc
be a hardware specific userspace part that knows what it prefers.  For
v4l2, it probably makes sense to sort out what the userspace level API
is and work backwards from there, rather than risk trying to design a
kernel uapi that might turn out to be the wrong thing.

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] drm/bridge/synopsys: dsi: Various cleanups

[Philippe CORNU]

Hi Archit,
Gentle reminder :-)

Do not hesitate to send me any comments so I can update these patches.

Note that the "Constify funcs structures" patch is now obsolete as a 
similar ones from Bhumika Goyal has been posted then integrated recently.

Many thanks for your support,
Philippe :-)


On 08/01/2017 03:30 PM, Philippe CORNU wrote:
> Hi Archit,
> 
> The 2 first patches have been reviewed by Laurent. The 3rd one has been 
> "acked" by Philipp.
> 
> Do not hesitate to send me any comments so I can take them into account 
> before my holidays (end of next week)...
> 
> Many thanks for your support,
> 
> Philippe :-)
> 
> 
> On 08/01/2017 03:23 PM, Philippe CORNU wrote:
>> Version 3:
>> - Add devm_reset_control_get_optional_exclusive (Philipp Zabel).
>>
>> Version 2:
>> - Put back Synopsys mipi dsi unused registers.
>> - Add devm_reset_control_get_exclusive to follow explicit reset API.
>> - Add a missing commit message & reviewed-by.
>>
>> Version 1:
>> - Initial commit
>>
>> The purpose of this set of patches is to clean up the mipi dsi dw
>> Synopsys drm bridge.
>>
>> Philippe CORNU (3):
>>drm/bridge/synopsys: dsi: Constify funcs structures
>>drm/bridge/synopsys: dsi: Register list clean up
>>drm/bridge/synopsys: dsi: explicitly request exclusive reset control
>>
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 104 
>> +++---
>>   1 file changed, 60 insertions(+), 44 deletions(-)
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 17/22] drm/stm: Use drm_gem_fb_create()

[Philippe CORNU]

Hi Noralf,
Many thanks for your patchset (and sorry for this late reply due to 
summer holidays :-),

On 08/13/2017 03:32 PM, Noralf Trønnes wrote:
> drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now,
> so use the function directly.
> 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Signed-off-by: Noralf Trønnes 

Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 

Philippe :-)

> ---
>   drivers/gpu/drm/stm/drv.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index b333b37..c857663 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -17,6 +17,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include "ltdc.h"
>   
> @@ -31,7 +32,7 @@ static void drv_output_poll_changed(struct drm_device *ddev)
>   }
>   
>   static const struct drm_mode_config_funcs drv_mode_config_funcs = {
> - .fb_create = drm_fb_cma_create,
> + .fb_create = drm_gem_fb_create,
>   .output_poll_changed = drv_output_poll_changed,
>   .atomic_check = drm_atomic_helper_check,
>   .atomic_commit = drm_atomic_helper_commit,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/6 v3] ASoC: AMD: Add machine driver for cz rt5650

[Agrawal, Akshu]

On 8/31/2017 5:08 PM, Mark Brown wrote:
> On Fri, Aug 18, 2017 at 02:10:30PM -0400, Alex Deucher wrote:
> 
>> +++ b/sound/soc/amd/Kconfig
>> @@ -2,3 +2,10 @@ config SND_SOC_AMD_ACP
>>  tristate "AMD Audio Coprocessor support"
>>  help
>>   This option enables ACP DMA support on AMD platform.
>> +config SND_SOC_AMD_CZ_RT5645_MACH
>> +tristate "AMD CZ support for RT5645"
> 
> Missing blank line between the stanzas.

Done. Will push the change in next revision.

> 
>> +select SND_SOC_RT5645
>> +select SND_SOC_AMD_ACP
>> +depends on I2C_DESIGNWARE_PLATFORM
> 
> No system dependencies of any kind?  Looking at this I'd expect at least
> CONFIG_ACPI || COMPILE_TEST.  It's also unclear to me how the DesignWare
> device is going to be instantiated here or if that should be a direct
> depenency at all here.
>

Added I2C for system dependency and removed 
I2C_DESIGNWARE_PLATFORM as dependency

>> +ret = snd_soc_register_card(card);
> 
> devm_snd_soc_register_card() and then you don't need the remove
> function.
>

Done.

>> +static const struct acpi_device_id cz_audio_acpi_match[] = {
>> +{ "AMDI1002", 0 },
>> +{},
>> +};
>> +
> 
> Missing MODULE_DEVICE_TABLE().
>

Done.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102242] [CI] assert(level < 128) failed for igt@pm_rpm@sysfs-read

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102242

Jari Tahvanainen  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT

--- Comment #6 from Jari Tahvanainen  ---
Tested-by/SKL: I see the same improvement (FAIL -> SUCCESS) with igt+series
(https://patchwork.freedesktop.org/series/29141/) used on latest drm-tip kernel
drm-tip: "2017y-08m-30d-08h-12m-34s UTC integration manifest".
Looping ./pm_rpm --r sysfs-read thousand times resulted all
Subtest sysfs-read: SUCCESS (0,1..s).

Moving to IGT component since fixing is done there...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102500

--- Comment #3 from Arek Ruśniak  ---
Created attachment 133923
  --> https://bugs.freedesktop.org/attachment.cgi?id=133923=edit
dmesg for first bad commit

autostart throu gdm to gnome3-session failed so I booted into multi-user (no vm
faults yet) and then started fluxbox from tty

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102500

--- Comment #2 from Arek Ruśniak  ---
Ok, sometimes gnome session refuse to work or even crashes on it (leds blinking
on my kb)  

1753d85bc82849deeb68cb5d7883207f0acbddc4 is the first bad commit
commit 1753d85bc82849deeb68cb5d7883207f0acbddc4
Author: Christian König 
Date:   Tue Aug 29 16:14:32 2017 +0200

drm/amdgpu: bump version for support of local BOs

Signed-off-by: Christian König 
Reviewed-by: Felix Kuehling 

:04 04 fb4af6a5aa54bac7afddeb83db09105ce7dab3e5
b30f9c48abef6ddd2bd3a34dd447c0543ca1b29e M  drivers

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] RFC: drm: bridge: Add API to fetch connector

[Linus Walleij]

We need to be able to get the connector out of a dumb VGA
for the PL111 driver. This is because we are using the
connector in the driver when initializing the display
pipe.

Signed-off-by: Linus Walleij 
---
This is a bit ugly but not uglier than how we are reaching
into the connector of the panels in several drivers. I don't
know any better idea, advice welcome.
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 7 +++
 include/drm/dumb_vga_dac.h| 9 +
 2 files changed, 16 insertions(+)
 create mode 100644 include/drm/dumb_vga_dac.h

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 6c2fdcb4fde1..c0d46ab7fde0 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct vga_dac_variant - characteristics of the DAC
@@ -51,6 +52,12 @@ drm_connector_to_dumb_vga(struct drm_connector *connector)
return container_of(connector, struct dumb_vga, connector);
 }
 
+struct drm_connector *drm_dumb_vga_get_connector(struct drm_bridge *bridge)
+{
+   return _bridge_to_dumb_vga(bridge)->connector;
+}
+EXPORT_SYMBOL_GPL(drm_dumb_vga_get_connector);
+
 static int dumb_vga_get_modes(struct drm_connector *connector)
 {
struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
diff --git a/include/drm/dumb_vga_dac.h b/include/drm/dumb_vga_dac.h
new file mode 100644
index ..b7117222054d
--- /dev/null
+++ b/include/drm/dumb_vga_dac.h
@@ -0,0 +1,9 @@
+#ifndef _DUMB_VGA_DAC_H_
+#define _DUMB_VGA_DAC_H_
+
+struct drm_connector;
+struct drm_bridge;
+
+struct drm_connector *drm_dumb_vga_get_connector(struct drm_bridge *bridge);
+
+#endif
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Linus Walleij]

If we cannot find a panel, assume that the output from the
PL111 is connected directly to a "dumb" VGA connector,
so look up the connector from that bridge.

Signed-off-by: Linus Walleij 
---
This is how the new API is used in the PL111.
---
 drivers/gpu/drm/pl111/Kconfig | 1 +
 drivers/gpu/drm/pl111/pl111_drv.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index e5e2abd66491..82cb3e60ddc8 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,6 +8,7 @@ config DRM_PL111
select DRM_GEM_CMA_HELPER
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
+   select DRM_DUMB_VGA_DAC
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
  Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index f5bc6f160e60..6db423bbd84e 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pl111_drm.h"
 #include "pl111_versatile.h"
@@ -128,6 +129,8 @@ static int pl111_modeset_init(struct drm_device *dev)
if (panel) {
priv->panel = panel;
priv->connector = panel->connector;
+   } else {
+   priv->connector = drm_dumb_vga_get_connector(bridge);
}
priv->bridge = bridge;
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: bridge: Add bindings for TI THS8134

[Linus Walleij]

This adds device tree bindings for the Texas Instruments
THS8134A and THS8134B VGA DACs by extending and renaming the
existing bindings for THS8135.

These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.

Cc: devicet...@vger.kernel.org
Cc: Bartosz Golaszewski 
Signed-off-by: Linus Walleij 
---
 .../display/bridge/{ti,ths8135.txt => ti,ths813x.txt}| 12 
 1 file changed, 8 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt => 
ti,ths813x.txt} (73%)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
similarity index 73%
rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
index 6ec1a880ac18..608435f04796 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
@@ -1,11 +1,15 @@
-THS8135 Video DAC
--
+THS8134 and THS8135 Video DAC
+-
 
-This is the binding for Texas Instruments THS8135 Video DAC bridge.
+This is the binding for Texas Instruments THS8134A, THS8134B and THS8135
+Video DAC bridge.
 
 Required properties:
 
-- compatible: Must be "ti,ths8135"
+- compatible: Must be one of
+  "ti,ths8134a"
+  "ti,ths8134b"
+  "ti,ths8135"
 
 Required nodes:
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: bridge: Add THS8134A/B support to dumb VGA DAC

[Linus Walleij]

This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.

The THS8134A, THS8134B and as it turns out also THS8135 need to
have data clocked out at the negative edge of the clock pulse,
since they clock it into the DAC at the positive edge (so by
then it needs to be stable) so we need some extra logic to flag
this on the connector to the driver.

The semantics of the flag DRM_BUS_FLAG_PIXDATA_NEGEDGE in
 clearly indicates that this flag tells
when to *drive* the data, not when the receiver *reads* it,
so the TI variants needs to be handled like this.

Introduce a variant struct and contain the information there,
and add a bit of helpful comments about how this works so
people will get it right when adding new DACs or connectiong
new display drivers to DACs.

The fact that THS8135 might be working on some systems today
is probably due to the fact that the display driver cannot
configure when the data is clocked out and the electronics
have simply been designed around it so it works anyways.

The phenomenon is very real on the ARM reference designs using
PL111 where the hardware can control which edge to push out
the data.

Cc: Laurent Pinchart 
Cc: Bartosz Golaszewski 
Cc: Maxime Ripard 
Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 62 +--
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 831a606c4706..6c2fdcb4fde1 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -19,9 +20,20 @@
 #include 
 #include 
 
+/**
+ * struct vga_dac_variant - characteristics of the DAC
+ * @posedge_clk: this DAC latches data into the DAC on the positive
+ * edge of the clock pulse, which means that display controllers
+ * need to clock it out on the negative edge
+ */
+struct vga_dac_variant {
+   bool posedge_clk;
+};
+
 struct dumb_vga {
struct drm_bridge   bridge;
struct drm_connectorconnector;
+   struct vga_dac_variant const *variant;
 
struct i2c_adapter  *ddc;
struct regulator*vdd;
@@ -67,6 +79,18 @@ static int dumb_vga_get_modes(struct drm_connector 
*connector)
/* And prefer a mode pretty much anyone can handle */
drm_set_preferred_mode(connector, 1024, 768);
 
+   if (vga->variant->posedge_clk)
+   /*
+* If the DAC latches the data into its registers on the
+* positive edge of the clock, the display driver needs to
+* drive the data out on the negative edge so it is
+* stable at the positive edge, so as to avoid flicker.
+*
+* Tell the driver that we want data on the negative edge
+*/
+   connector->display_info.bus_flags |=
+   DRM_BUS_FLAG_PIXDATA_NEGEDGE;
+
return ret;
 }
 
@@ -183,6 +207,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
if (!vga)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+   vga->variant = of_device_get_match_data(>dev);
 
vga->vdd = devm_regulator_get_optional(>dev, "vdd");
if (IS_ERR(vga->vdd)) {
@@ -226,10 +251,41 @@ static int dumb_vga_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct vga_dac_variant default_dac_variant = {
+   /*
+* These DACs read data on the negative edge. For example in the
+* ADV7123 datasheet (revision D, page 8) there is a timing diagram
+* making this clear.
+*/
+   .posedge_clk = false,
+};
+
+static const struct vga_dac_variant ti_ths_dac_variant = {
+   /* The TI DACs read the data on the positive edge of the CLK */
+   .posedge_clk = true,
+};
+
 static const struct of_device_id dumb_vga_match[] = {
-   { .compatible = "dumb-vga-dac" },
-   { .compatible = "adi,adv7123" },
-   { .compatible = "ti,ths8135" },
+   {
+   .compatible = "dumb-vga-dac",
+   .data = _dac_variant,
+   },
+   {
+   .compatible = "adi,adv7123",
+   .data = _dac_variant,
+   },
+   {
+   .compatible = "ti,ths8134a",
+   .data = _ths_dac_variant,
+   },
+   {
+   .compatible = "ti,ths8134b",
+   .data = _ths_dac_variant,
+   },
+   {
+   .compatible = "ti,ths8135",
+   .data = _ths_dac_variant,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dumb_vga_match);
-- 
2.13.5

___
dri-devel mailing list

[PATCH 7/7 v2] drm/pl111: Add handling of Versatile platforms

[Linus Walleij]

The ARM reference designs in the Versatile family: Integrator,
Versatile and RealView can make use of the new DRM driver as well.
We just need to create a bit of platform-specific code for them
that we isolate to its own file.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Rebase on the other patches.
- Drop pad note from DOC section.
---
 drivers/gpu/drm/pl111/Makefile  |   1 +
 drivers/gpu/drm/pl111/pl111_display.c   |   7 -
 drivers/gpu/drm/pl111/pl111_drv.c   |   8 +-
 drivers/gpu/drm/pl111/pl111_versatile.c | 270 
 drivers/gpu/drm/pl111/pl111_versatile.h |   9 ++
 5 files changed, 285 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h

diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index c5f8f9684848..fce1453a93e1 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -1,4 +1,5 @@
 pl111_drm-y += pl111_display.o \
+   pl111_versatile.o \
pl111_drv.o
 
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 5ca2c307856c..a3cf2ac8d4c1 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -449,13 +449,6 @@ int pl111_display_init(struct drm_device *drm)
}
of_node_put(endpoint);
 
-   if (tft_r0b0g0[0] != 0 ||
-   tft_r0b0g0[1] != 8 ||
-   tft_r0b0g0[2] != 16) {
-   dev_err(dev, "arm,pl11x,tft-r0g0b0-pads != [0,8,16] not yet 
supported\n");
-   return -EINVAL;
-   }
-
ret = pl111_init_clock_divider(drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index c4a654867ed1..f5bc6f160e60 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -41,9 +41,6 @@
  * - Fix race between setting plane base address and getting IRQ for
  *   vsync firing the pageflip completion.
  *
- * - Expose the correct set of formats we can support based on the
- *   "arm,pl11x,tft-r0g0b0-pads" DT property.
- *
  * - Use the "max-memory-bandwidth" DT property to filter the
  *   supported formats.
  *
@@ -72,6 +69,7 @@
 #include 
 
 #include "pl111_drm.h"
+#include "pl111_versatile.h"
 
 #define DRIVER_DESC  "DRM module for PL111"
 
@@ -264,6 +262,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
return ret;
}
 
+   ret = pl111_versatile_init(dev, priv);
+   if (ret)
+   goto dev_unref;
+
ret = pl111_modeset_init(drm);
if (ret != 0)
goto dev_unref;
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
b/drivers/gpu/drm/pl111/pl111_versatile.c
new file mode 100644
index ..97d4af6925a3
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -0,0 +1,270 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pl111_versatile.h"
+#include "pl111_drm.h"
+
+static struct regmap *versatile_syscon_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+   INTEGRATOR_CLCD_CM,
+   VERSATILE_CLCD,
+   REALVIEW_CLCD_EB,
+   REALVIEW_CLCD_PB1176,
+   REALVIEW_CLCD_PB11MP,
+   REALVIEW_CLCD_PBA8,
+   REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+   {
+   .compatible = "arm,core-module-integrator",
+   .data = (void *)INTEGRATOR_CLCD_CM,
+   },
+   {
+   .compatible = "arm,versatile-sysreg",
+   .data = (void *)VERSATILE_CLCD,
+   },
+   {
+   .compatible = "arm,realview-eb-syscon",
+   .data = (void *)REALVIEW_CLCD_EB,
+   },
+   {
+   .compatible = "arm,realview-pb1176-syscon",
+   .data = (void *)REALVIEW_CLCD_PB1176,
+   },
+   {
+   .compatible = "arm,realview-pb11mp-syscon",
+   .data = (void *)REALVIEW_CLCD_PB11MP,
+   },
+   {
+   .compatible = "arm,realview-pba8-syscon",
+   .data = (void *)REALVIEW_CLCD_PBA8,
+   },
+   {
+   .compatible = "arm,realview-pbx-syscon",
+   .data = (void *)REALVIEW_CLCD_PBX,
+   },
+   {},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET 0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN  BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP  BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN  BIT(10)
+/* Bits 11,12,13 controls the LCD type */
+#define INTEGRATOR_CLCD_LCDMUX_MASK(BIT(11)|BIT(12)|BIT(13))
+#define 

[PATCH 1/7 v2] drm/pl111: Cleanup local header file

[Linus Walleij]

The header file contains prototypes for two nonexisting
functions. Get rid of them.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Collect Eric's ACK.
---
 drivers/gpu/drm/pl111/pl111_drm.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 5c685bfc8fdc..a97f303f6833 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -58,10 +58,6 @@ int pl111_enable_vblank(struct drm_device *drm, unsigned int 
crtc);
 void pl111_disable_vblank(struct drm_device *drm, unsigned int crtc);
 irqreturn_t pl111_irq(int irq, void *data);
 int pl111_connector_init(struct drm_device *dev);
-int pl111_encoder_init(struct drm_device *dev);
-int pl111_dumb_create(struct drm_file *file_priv,
- struct drm_device *dev,
- struct drm_mode_create_dumb *args);
 int pl111_debugfs_init(struct drm_minor *minor);
 
 #endif /* _PL111_DRM_H_ */
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7 v2] drm/pl111: Insert delay before powering up PL11x

[Linus Walleij]

The old codebase has a delay between enabling and powering up the
PL11x.

According to the manual for PL110, ARM DDI 0161E page 1-5 and
the PL111 manual ARM DDI 0293C page 1-6, the power sequence should
be such that once Vdd is stable (which we assume it is at boot)
LCDEN is enabled first and then CLPOWER should be enabled
"after the signals have stabilized" and this is said to
be display-dependent. The old codebase uses 20ms.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Fall back to the delay of 20 ms from the old framebuffer
  driver to stabilize Vee in shortage of other alternatives.
---
 drivers/gpu/drm/pl111/pl111_display.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 51e3530c876c..3ed451ca2744 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -154,8 +154,8 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
 
writel(0, priv->regs + CLCD_TIM3);
 
-   /* Enable and Power Up */
-   cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDPWR | CNTL_LCDVCOMP(1);
+   /* Hard-code TFT panel */
+   cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDVCOMP(1);
 
/* Note that the the hardware's format reader takes 'r' from
 * the low bit, while DRM formats list channels from high bit
@@ -198,6 +198,17 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
break;
}
 
+   /* Power sequence: first enable and chill */
+   writel(cntl, priv->regs + priv->ctrl);
+
+   /*
+* We expect this delay to stabilize the contrast
+* voltage Vee as stipulated by the manual
+*/
+   msleep(20);
+
+   /* Power Up */
+   cntl |= CNTL_LCDPWR;
writel(cntl, priv->regs + priv->ctrl);
 
drm_crtc_vblank_on(crtc);
@@ -208,10 +219,24 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
struct drm_crtc *crtc = >crtc;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
+   u32 cntl;
 
drm_crtc_vblank_off(crtc);
 
-   /* Disable and Power Down */
+   /* Power Down */
+   cntl = readl(priv->regs + priv->ctrl);
+   if (cntl & CNTL_LCDPWR) {
+   cntl &= ~CNTL_LCDPWR;
+   writel(cntl, priv->regs + priv->ctrl);
+   }
+
+   /*
+* We expect this delay to stabilize the contrast voltage Vee as
+* stipulated by the manual
+*/
+   msleep(20);
+
+   /* Disable */
writel(0, priv->regs + priv->ctrl);
 
clk_disable_unprepare(priv->clk);
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7 v2] drm/pl111: Add optional variant display en/disable callbacks

[Linus Walleij]

The silcon and components around the PL111 may require some
variants to perform special set-up of the display. Add two
callbacks to manage this.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Rebase on other display driver changes.
---
 drivers/gpu/drm/pl111/pl111_display.c | 6 ++
 drivers/gpu/drm/pl111/pl111_drm.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 3ed451ca2744..5ca2c307856c 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -207,6 +207,9 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
 */
msleep(20);
 
+   if (priv->variant_display_enable)
+   priv->variant_display_enable(drm, fb->format->format);
+
/* Power Up */
cntl |= CNTL_LCDPWR;
writel(cntl, priv->regs + priv->ctrl);
@@ -236,6 +239,9 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
 */
msleep(20);
 
+   if (priv->variant_display_disable)
+   priv->variant_display_disable(drm);
+
/* Disable */
writel(0, priv->regs + priv->ctrl);
 
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index eeaabe735058..c28b5d042412 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CLCD_IRQ_NEXTBASE_UPDATE BIT(2)
 
@@ -67,6 +68,8 @@ struct pl111_drm_dev_private {
 */
spinlock_t tim2_lock;
const struct pl111_variant_data *variant;
+   void (*variant_display_enable) (struct drm_device *drm, u32 format);
+   void (*variant_display_disable) (struct drm_device *drm);
 };
 
 int pl111_display_init(struct drm_device *dev);
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7 v2] First set of PL111 enhancements

[Linus Walleij]

This is the v2 patch set fixing the review comments (hopefully).

Mainly I had to drop the cleverness of wrapping power enablement
inside the panel prepare/enable pair and fall back to a 20ms
delay as in the framebuffer driver. I hope everyone survives
this.

Linus Walleij (7):
  drm/pl111: Cleanup local header file
  drm/pl111: Add all registers to debugfs
  drm/pl111: Replace custom connector with panel bridge
  drm/pl111: Enable PL110 variant
  drm/pl111: Insert delay before powering up PL11x
  drm/pl111: Add optional variant display en/disable callbacks
  drm/pl111: Add handling of Versatile platforms

 drivers/gpu/drm/pl111/Kconfig   |   3 +-
 drivers/gpu/drm/pl111/Makefile  |   4 +-
 drivers/gpu/drm/pl111/pl111_connector.c | 127 ---
 drivers/gpu/drm/pl111/pl111_debugfs.c   |   6 +
 drivers/gpu/drm/pl111/pl111_display.c   |  81 +-
 drivers/gpu/drm/pl111/pl111_drm.h   |  38 +++--
 drivers/gpu/drm/pl111/pl111_drv.c   | 156 +++---
 drivers/gpu/drm/pl111/pl111_versatile.c | 270 
 drivers/gpu/drm/pl111/pl111_versatile.h |   9 ++
 9 files changed, 489 insertions(+), 205 deletions(-)
 delete mode 100644 drivers/gpu/drm/pl111/pl111_connector.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h

-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7 v2] drm/pl111: Replace custom connector with panel bridge

[Linus Walleij]

This replaces the custom connector in the PL111 with the
panel bridge helper.

This works nicely for all standard panels, but since there
are several PL11x-based systems that will need to use the dumb
VGA connector bridge we use drm_of_find_panel_or_bridge()
and make some headroom for dealing with bridges that are
not panels as well, and drop a TODO in the code.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Remove the panel [un]prepare() and [en|dis]able() calls
  from the display driver, since this is now handled
  by the bridge.
---
 drivers/gpu/drm/pl111/Kconfig   |   3 +-
 drivers/gpu/drm/pl111/Makefile  |   3 +-
 drivers/gpu/drm/pl111/pl111_connector.c | 127 
 drivers/gpu/drm/pl111/pl111_display.c   |  16 ++--
 drivers/gpu/drm/pl111/pl111_drm.h   |  18 ++---
 drivers/gpu/drm/pl111/pl111_drv.c   |  62 +++-
 6 files changed, 60 insertions(+), 169 deletions(-)
 delete mode 100644 drivers/gpu/drm/pl111/pl111_connector.c

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index bbfba87cd1a8..e5e2abd66491 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -6,7 +6,8 @@ config DRM_PL111
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-   select DRM_PANEL
+   select DRM_BRIDGE
+   select DRM_PANEL_BRIDGE
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
  Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index 59483d610ef5..c5f8f9684848 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -1,5 +1,4 @@
-pl111_drm-y += pl111_connector.o \
-   pl111_display.o \
+pl111_drm-y += pl111_display.o \
pl111_drv.o
 
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
diff --git a/drivers/gpu/drm/pl111/pl111_connector.c 
b/drivers/gpu/drm/pl111/pl111_connector.c
deleted file mode 100644
index 3f213d7e7692..
--- a/drivers/gpu/drm/pl111/pl111_connector.c
+++ /dev/null
@@ -1,127 +0,0 @@
-/*
- * (C) COPYRIGHT 2012-2013 ARM Limited. All rights reserved.
- *
- * Parts of this file were based on sources as follows:
- *
- * Copyright (c) 2006-2008 Intel Corporation
- * Copyright (c) 2007 Dave Airlie 
- * Copyright (C) 2011 Texas Instruments
- *
- * This program is free software and is provided to you under the terms of the
- * GNU General Public License version 2 as published by the Free Software
- * Foundation, and any use by you of this program is subject to the terms of
- * such GNU licence.
- *
- */
-
-/**
- * pl111_drm_connector.c
- * Implementation of the connector functions for PL111 DRM
- */
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "pl111_drm.h"
-
-static void pl111_connector_destroy(struct drm_connector *connector)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   if (pl111_connector->panel)
-   drm_panel_detach(pl111_connector->panel);
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static enum drm_connector_status pl111_connector_detect(struct drm_connector
-   *connector, bool force)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   return (pl111_connector->panel ?
-   connector_status_connected :
-   connector_status_disconnected);
-}
-
-static int pl111_connector_helper_get_modes(struct drm_connector *connector)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   if (!pl111_connector->panel)
-   return 0;
-
-   return drm_panel_get_modes(pl111_connector->panel);
-}
-
-const struct drm_connector_funcs connector_funcs = {
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = pl111_connector_destroy,
-   .detect = pl111_connector_detect,
-   .dpms = drm_atomic_helper_connector_dpms,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-const struct drm_connector_helper_funcs connector_helper_funcs = {
-   .get_modes = pl111_connector_helper_get_modes,
-};
-
-/* Walks the OF graph to find the panel node and then asks DRM to look
- * up the panel.
- */
-static struct drm_panel *pl111_get_panel(struct device *dev)
-{
-   struct device_node *endpoint, *panel_node;
-   struct device_node *np = dev->of_node;
-   struct drm_panel *panel;
-
-   endpoint = of_graph_get_next_endpoint(np, 

[PATCH 2/7 v2] drm/pl111: Add all registers to debugfs

[Linus Walleij]

This adds all the main control registers to the debugfs
register file. This was helpful for my debugging so it will
likely help others as well.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Collect Eric's ACK.
---
 drivers/gpu/drm/pl111/pl111_debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_debugfs.c 
b/drivers/gpu/drm/pl111/pl111_debugfs.c
index 0d9dee199b2c..7ddc7e3b9e7d 100644
--- a/drivers/gpu/drm/pl111/pl111_debugfs.c
+++ b/drivers/gpu/drm/pl111/pl111_debugfs.c
@@ -22,8 +22,14 @@ static const struct {
REGDEF(CLCD_TIM2),
REGDEF(CLCD_TIM3),
REGDEF(CLCD_UBAS),
+   REGDEF(CLCD_LBAS),
REGDEF(CLCD_PL111_CNTL),
REGDEF(CLCD_PL111_IENB),
+   REGDEF(CLCD_PL111_RIS),
+   REGDEF(CLCD_PL111_MIS),
+   REGDEF(CLCD_PL111_ICR),
+   REGDEF(CLCD_PL111_UCUR),
+   REGDEF(CLCD_PL111_LCUR),
 };
 
 int pl111_debugfs_regs(struct seq_file *m, void *unused)
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7 v2] drm/pl111: Enable PL110 variant

[Linus Walleij]

We detect and enable the use of the PL110 variant, an earlier
incarnation of PL111. The only real difference is that the
control and interrupt enable registers have swapped place.
The Versatile AB and Versatile PB have a variant inbetween
PL110 and PL111, it is PL110 but they have already swapped the
two registers so those two need a bit of special handling.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Fix static const on the variant struct holders. (Had to
  insert a (void*) cast for this because amba_id is not
  consting this field)
- Collect Eric A's Reviewed-by
---
 drivers/gpu/drm/pl111/pl111_display.c | 27 +++
 drivers/gpu/drm/pl111/pl111_drm.h | 17 +++
 drivers/gpu/drm/pl111/pl111_drv.c | 86 +--
 3 files changed, 106 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 59cdb8f49bb1..51e3530c876c 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -198,7 +198,7 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
break;
}
 
-   writel(cntl, priv->regs + CLCD_PL111_CNTL);
+   writel(cntl, priv->regs + priv->ctrl);
 
drm_crtc_vblank_on(crtc);
 }
@@ -212,7 +212,7 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
drm_crtc_vblank_off(crtc);
 
/* Disable and Power Down */
-   writel(0, priv->regs + CLCD_PL111_CNTL);
+   writel(0, priv->regs + priv->ctrl);
 
clk_disable_unprepare(priv->clk);
 }
@@ -250,7 +250,7 @@ int pl111_enable_vblank(struct drm_device *drm, unsigned 
int crtc)
 {
struct pl111_drm_dev_private *priv = drm->dev_private;
 
-   writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + CLCD_PL111_IENB);
+   writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + priv->ienb);
 
return 0;
 }
@@ -259,7 +259,7 @@ void pl111_disable_vblank(struct drm_device *drm, unsigned 
int crtc)
 {
struct pl111_drm_dev_private *priv = drm->dev_private;
 
-   writel(0, priv->regs + CLCD_PL111_IENB);
+   writel(0, priv->regs + priv->ienb);
 }
 
 static int pl111_display_prepare_fb(struct drm_simple_display_pipe *pipe,
@@ -403,22 +403,6 @@ int pl111_display_init(struct drm_device *drm)
struct device_node *endpoint;
u32 tft_r0b0g0[3];
int ret;
-   static const u32 formats[] = {
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XBGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_BGR565,
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_ABGR1555,
-   DRM_FORMAT_XBGR1555,
-   DRM_FORMAT_ARGB1555,
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XBGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_XRGB,
-   };
 
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (!endpoint)
@@ -447,7 +431,8 @@ int pl111_display_init(struct drm_device *drm)
 
ret = drm_simple_display_pipe_init(drm, >pipe,
   _display_funcs,
-  formats, ARRAY_SIZE(formats),
+  priv->variant->formats,
+  priv->variant->nformats,
   priv->connector);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 8804af0f8997..eeaabe735058 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -31,6 +31,20 @@
 
 struct drm_minor;
 
+/**
+ * struct pl111_variant_data - encodes IP differences
+ * @name: the name of this variant
+ * @is_pl110: this is the early PL110 variant
+ * @formats: array of supported pixel formats on this variant
+ * @nformats: the length of the array of supported pixel formats
+ */
+struct pl111_variant_data {
+   const char *name;
+   bool is_pl110;
+   const u32 *formats;
+   unsigned int nformats;
+};
+
 struct pl111_drm_dev_private {
struct drm_device *drm;
 
@@ -42,6 +56,8 @@ struct pl111_drm_dev_private {
struct drm_fbdev_cma *fbdev;
 
void *regs;
+   u32 ienb;
+   u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
struct clk *clk;
/* pl111's internal clock divider. */
@@ -50,6 +66,7 @@ struct pl111_drm_dev_private {
 * subsystem and pl111_display_enable().
 */
spinlock_t tim2_lock;
+   const struct pl111_variant_data *variant;
 };
 
 int pl111_display_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 

Re: [PATCH 7/7] drm/pl111: Add handling of Versatile platforms

[Linus Walleij]

On Thu, Aug 31, 2017 at 7:58 PM, Eric Anholt  wrote:
> Linus Walleij  writes:
>
>> The ARM reference designs in the Versatile family: Integrator,
>> Versatile and RealView can make use of the new DRM driver as well.
>> We just need to create a bit of platform-specific code for them
>> that we isolate to its own file.
>>
>> Signed-off-by: Linus Walleij 
>> ---
>>  drivers/gpu/drm/pl111/Makefile  |   1 +
>>  drivers/gpu/drm/pl111/pl111_display.c   |   7 -
>>  drivers/gpu/drm/pl111/pl111_drv.c   |   5 +
>>  drivers/gpu/drm/pl111/pl111_versatile.c | 270 
>> 
>>  drivers/gpu/drm/pl111/pl111_versatile.h |   9 ++
>>  5 files changed, 285 insertions(+), 7 deletions(-)
>>  create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
>>  create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h
>>
>> diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
>> index c5f8f9684848..fce1453a93e1 100644
>> --- a/drivers/gpu/drm/pl111/Makefile
>> +++ b/drivers/gpu/drm/pl111/Makefile
>> @@ -1,4 +1,5 @@
>>  pl111_drm-y +=   pl111_display.o \
>> + pl111_versatile.o \
>>   pl111_drv.o
>>
>>  pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
>> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
>> b/drivers/gpu/drm/pl111/pl111_display.c
>> index 37f409867934..f7b043f4fed6 100644
>> --- a/drivers/gpu/drm/pl111/pl111_display.c
>> +++ b/drivers/gpu/drm/pl111/pl111_display.c
>> @@ -454,13 +454,6 @@ int pl111_display_init(struct drm_device *drm)
>>   }
>>   of_node_put(endpoint);
>>
>> - if (tft_r0b0g0[0] != 0 ||
>> - tft_r0b0g0[1] != 8 ||
>> - tft_r0b0g0[2] != 16) {
>> - dev_err(dev, "arm,pl11x,tft-r0g0b0-pads != [0,8,16] not yet 
>> supported\n");
>> - return -EINVAL;
>> - }
>
> I had a note in the DOC section of pl111_drv.c about needing to filter
> available formats based on this property.  Could you update that with
> some explanation of the new state of things?  (Do we actually need to
> filter the formats?)

No we don't need to filter it really, only the Nomadik makes use of this
property and I haven't come to adding support for that yet.

> I haven't verified that we get the same pin routing setup as the fbdev
> driver did for these platforms, but even if they don't match yet this
> seems like an excellent start and we can make sure we sort them out as
> we add panel drivers.

This should be fine with panels I think, the problem is how the
CLCD/PL11x is integrated with the silicon, as sometimes the VHDL
coders just arbitrarily manage to switch things around. It should
be handled entirely in the PL11x driver.

> I've verified that my Cygnus board continues working with your series.

Nice! I have graphics working on the RealView machines.

Now I just need to figure out a few minor things like augmenting the
list of resolutions from the panel for the bus bandwidth and
some dumb VGA bridge business.

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel