Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

2017-08-20 Thread Thierry Reding 
On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noralf Trønnes wrote:
> Reject mapping an imported dma-buf since is's an invalid use-case.
> 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Sean Paul 
> Cc: Daniel Vetter 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_gem.c | 6 ++
>  1 file changed, 6 insertions(+)

I'm not sure we've documented exactly why this is an invalid use-case.
Perhaps that's something we should do along with this patch, or maybe
as a follow-up.

Either way, I think this is a good idea, so:

Acked-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: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

2017-08-20 Thread Laurent Pinchart 
Hi Hean Loong,

On Monday, 21 August 2017 04:40:09 EEST Ong, Hean Loong wrote:
> On Fri, 2017-08-18 at 16:11 +0300, Laurent Pinchart wrote:
> > On Friday 18 Aug 2017 08:34:44 Ong, Hean Loong wrote:
> > > 
> > > Hi Laurent,
> > > Thanks for the comments, I drafted a copy of the DT bindings based
> > > on your recommendations and inputs. I inserted the changes below the
> > > previous comments. 
> > 
> > [snip]
> > 
> > > 
> > > Intel Video and Image Processing(VIP) Frame Buffer II bindings
> > > 
> > > Supported hardware: Intel FPGA SoC Arria10 and above with display
> > > portIP
> > > 
> > > The Video Frame Buffer II in Video Image Processing (VIP) suite is
> > > an IP core that interfaces between system memory and Avalon-ST video
> > > ports. The IP core can be configured to support the memory reader (from
> > > memory to Avalon-ST) and/or memory writer (from Avalon-ST to memory)
> > > interfaces.
> > > 
> > > Connections between the Frame Buffer II and other video IP cores in
> > > the system are modelled using the OF graph DT bindings. The Frame
> > > Buffer II node has up to two OF graph ports. When the memory writer
> > > interface is enabled, port 0 maps to the Avalon-ST Input (din) port.
> > > When the memory reader interface is enabled, port 1 maps to the Avalon-
> > > ST Output (dout) port.
> > > 
> > > More information the FPGA video IP component can be acquired from
> > > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
> > > /literature/ug/ug_vip.pdf
> > > 
> > > New bindings:
> > > =
> > 
> > How are the bindings "new" ? You can omit that title.
> 
> Noted.
> 
> > > 
> > > Required properties:
> > > 
> > > - compatible: "altr,vip-frame-buffer-2.0"
> > > - reg: Physical base address and length of the framebuffer
> > > controller's registers.
> > > - altr,max-width: The maximum width of the framebuffer in pixels.
> > > - altr,max-height: The maximum height of the framebuffer in pixels.
> > > - altr,mem-port-width = the bus width of the avalon master port 
> > >   on the frame reader
> > 
> > You need to mention the ports here as they are mandatory. I would
> > move the second paragraph from the introduction to here. You should also
> > refer to the file defining the OF graph DT bindings. You can find examples
> > in other DT bindings.
> 
> Noted
> 
> > > 
> > > Example:
> > > 
> > >  +-+  +---+  ++  +---+
> > >  |  D  |  | Frame |  | DP/HDMI TX |  | DP/HDMI   |
> > >  |  D  |->| Buffer II |->| Controller |->| Connector |
> > >  |  R  |  |   |  ||  |   |
> > >  +-+  +---+  ++  +---+
> > > 
> > > framebuffer@10280 {
> > > compatible = "altr,vip-frame-buffer-2.0";
> > > reg = <0x0001 0x0280 0x0040>;
> > > altr,max-width = <1280>;
> > > altr,max-height = <720>;
> > > altr,mem-port-width = <128>;
> > > 
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > 
> > > port@1 {
> > > reg = <1>;
> > > fb_output: endpoint {
> > > remote-endpoint =
> > > <_encoder_input>;
> > > };
> > > };
> > > };
> > > };
> > > 
> > > If there is a need to scale the Frame Buffer II IP cores in
> > > the pipeline, each node would have its own node, connected
> > > through ports and endpoints. 
> > > 
> > > hdmi-encoder@. {
> > > compatible = "altr,hdmi-tx-16.0";
> > 
> > This was just an example, please use the real compatible string of
> > the HDMI controller (and please submit DT bindings for the HDMI controller
> > :-)). Please also fill the reg property with values from a real example.
> 
> I was trying to get overall picture to be correct before I proceed
> further. We currently do not have support for HDMI therefore I would
> omit this until a HDMI IP is available. The only values are available
> for the Display Port.

No problem. In that case the best option is to replace the HDMI encoder with a 
DisplayPort encoder in the example.

> > > reg = <.>;
> > > /* Other IP-specific properties here */
> > > 
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > 
> > > port@0 {
> > > reg = <0>;
> > > hdmi_tx_input: endpoint {
> > > remote-endpoint = <_output>;
> > > };
> > > };
> > > 
> > > port@1 {
> > > reg = <1>;
> > > hdmi_tx_output: endpoint {
> > > remote-endpoint =
> > > <_conn_input>;
> > >

Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

2017-08-20 Thread Ong, Hean Loong 
Hi Laurent Thanks. my replies are below

On Fri, 2017-08-18 at 16:11 +0300, Laurent Pinchart wrote:
> Hi Hean Loong,
> 
> (CC'ing dri-devel again as I noticed it wasn't CC'ed anymore)
> 
> On Friday 18 Aug 2017 08:34:44 Ong, Hean Loong wrote:
> > 
> > Hi Laurent,
> > Thanks for the comments, I drafted a copy of the DT bindings based
> > on
> > your recommendations and inputs. I inserted the changes below the
> > previous comments. 
> [snip]
> 
> > 
> > Intel Video and Image Processing(VIP) Frame Buffer II bindings
> > 
> > Supported hardware: Intel FPGA SoC Arria10 and above with display
> > port
> > IP
> > 
> > The Video Frame Buffer II in Video Image Processing (VIP) suite is
> > an IP
> > core that interfaces between system memory and Avalon-ST video
> > ports. The IP
> > core can be configured to support the memory reader (from memory to
> > Avalon-
> > ST) and/or memory writer (from Avalon-ST to memory) interfaces.
> > 
> > Connections between the Frame Buffer II and other video IP cores in
> > the
> > system are modelled using the OF graph DT bindings. The Frame
> > Buffer II node
> > has up to two OF graph ports. When the memory writer interface is
> > enabled,
> > port 0 maps to the Avalon-ST Input (din) port. When the memory
> > reader
> > interface is enabled, port 1 maps to the Avalon-ST Output (dout)
> > port.
> > 
> > More information the FPGA video IP component can be acquired from
> > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
> > /literature/ug/ug_vip.pdf
> > 
> > New bindings:
> > =
> How are the bindings "new" ? You can omit that title.
> 

Noted.
> > 
> > Required properties:
> > 
> > - compatible: "altr,vip-frame-buffer-2.0"
> > - reg: Physical base address and length of the framebuffer
> > controller's
> > registers.
> > - altr,max-width: The maximum width of the framebuffer in pixels.
> > - altr,max-height: The maximum height of the framebuffer in pixels.
> > - altr,mem-port-width = the bus width of the avalon master port 
> > on the frame reader
> You need to mention the ports here as they are mandatory. I would
> move the 
> second paragraph from the introduction to here. You should also refer
> to the 
> file defining the OF graph DT bindings. You can find examples in
> other DT 
> bindings.
> 
Noted
> > 
> > Example:
> > 
> >  +-+  +---+  ++  +---+
> >  |  D  |  | Frame |  | DP/HDMI TX |  | DP/HDMI   |
> >  |  D  |->| Buffer II |->| Controller |->| Connector |
> >  |  R  |  |   |  ||  |   |
> >  +-+  +---+  ++  +---+
> > 
> > framebuffer@10280 {
> > compatible = "altr,vip-frame-buffer-2.0";
> > reg = <0x0001 0x0280 0x0040>;
> > altr,max-width = <1280>;
> > altr,max-height = <720>;
> > altr,mem-port-width = <128>;
> > 
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > port@1 {
> > reg = <1>;
> > fb_output: endpoint {
> > remote-endpoint =
> > <_encoder_input>;
> > };
> > };
> > };
> > };
> > 
> > If there is a need to scale the Frame Buffer II IP cores in
> > the pipeline, each node would have its own node, connected
> > through ports and endpoints. 
> > 
> > hdmi-encoder@. {
> > compatible = "altr,hdmi-tx-16.0";
> This was just an example, please use the real compatible string of
> the HDMI 
> controller (and please submit DT bindings for the HDMI controller :-
> )). Please 
> also fill the reg property with values from a real example.
> 
I was trying to get overall picture to be correct before I proceed
further. We currently do not have support for HDMI therefore I would
omit this until a HDMI IP is available. The only values are available
for the Display Port.
> > 
> > reg = <.>;
> > /* Other IP-specific properties here */
> > 
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > port@0 {
> > reg = <0>;
> > hdmi_tx_input: endpoint {
> > remote-endpoint = <_output>;
> > };
> > };
> > 
> > port@1 {
> > reg = <1>;
> > hdmi_tx_output: endpoint {
> > remote-endpoint =
> > <_conn_input>;
> > };
> > };
> > };
> > };
> > 
> > hdmi-connector@0 {
> > compatible = "hdmi-connector";
> > type = "a";
> > 
> > port {
> > hdmi_conn_input: endpoint {
> >

[Bug 98324] amd-staging-4.7: problems with unblanking displays when monitors are switched off

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98324

--- Comment #1 from dwagner  ---
JFYI: A similar, but more dramatic symptom that may be related I reported in
https://bugs.freedesktop.org/show_bug.cgi?id=102323

-- 
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 102323] System crashes when woken up from S3 sleep while HDMI display is switched off

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102323

Bug ID: 102323
   Summary: System crashes when woken up from S3 sleep while HDMI
display is switched off
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jb5sgc1n@20mm.eu

My system invariably crashes (no picture, no reaction to any input, not even
from a remote ssh session) when I do the following:

1. echo mem >/sys/power/state

2. Wait until the blinking power LED of the system indicates it is S3-sleeping

3. Switch off the one single HDMI display connected to the GPU. (Make sure it
is actually off in a way that powers down the HDMI input - some displays have
"soft-off" modes that keep HDMI inputs powered.)

4. Press some key to make the system wake up from S3-sleep (while the display
is still off).

At this point, the system is inresponsive. If I power up the display, it
reports no HDMI input signal (so not just a black image, actually no signal).

My system is using an RX 460 GPU to drive one single HDMI display.

To narrow down the possible causes, I did not start X11 at all after freshly
rebooting, and I use "video=DP-1:d video=DVI-D-1:d video=HDMI-A-1:1024x768" on
the kernel command line to make sure that really just that one connected
display is driven, at a harmless 1024x768 mode.
(The symptom also occurs when using X11 other resolutions.)

I am running a kernel compiled from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next as of
"commit 94097b0f7f1bfa54b3b1f8b0d74bbd271a0564e4" (so the very latest amdgpu
version as of today).

Notice that my system does not crash if I wake it up from S3 sleep after
turning on the HDMI display.


Unluckily, above described 100% reproducable crash scenario does not produce
any error log / dmesg messages I could cite here.

However, I can cite some scary dmesg output that occurs if instead of sending
the system to S3 sleep I just:

1. Switch off the one single HDMI display connected to the GPU.

2. Press Ctrl-Alt-F2 then Ctrl-Alt-F3 to cycle through some virtual consoles
(notice: again no X11 involved, here).

This action causes dmesg output like this:

[ 3196.798430] [drm] link=1, dc_sink_in=  (null) is now Disconnected
[ 3196.798433] [drm] DCHPD: connector_id=1: Old sink=8807f6804c00 New sink=
 (null)
[ 3196.798475] [ cut here ]
[ 3196.798491] WARNING: CPU: 0 PID: 89 at drivers/gpu/drm/drm_mode_object.c:237
drm_object_property_set_value+0x5d/0x70 [drm]
[ 3196.798492] Modules linked in: blowfish_generic blowfish_x86_64
blowfish_common des3_ede_x86_64 des_generic cast5_avx_x86_64 cast5_generic
cast_common cbc twofish_generic twofish_avx_x86_64 twofish_x86_64_3way
twofish_x86_64 twofish_common serpent_avx2 serpent_avx_x86_64
serpent_sse2_x86_64 serpent_generic lrw gf128mul ablk_helper xts arc4 md4
nls_utf8 cifs ccm dns_resolver fscache ipt_REJECT nf_reject_ipv4 nf_log_ipv4
nf_log_common xt_LOG xt_tcpudp xt_owner cmac xt_mark iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep
iptable_mangle cpufreq_ondemand msr iptable_filter btusb snd_hda_codec_realtek
btrtl btbcm snd_hda_codec_generic btintel bluetooth snd_hda_codec_hdmi
nls_iso8859_1 snd_hda_intel nls_cp437 snd_hda_codec ecdh_generic vfat rfkill
fat igb snd_hda_core crc16
[ 3196.798519]  ptp pps_core edac_mce_amd dca snd_hwdep kvm_amd snd_pcm
snd_timer kvm snd soundcore sp5100_tco irqbypass evdev i2c_piix4 shpchp
input_leds pcspkr led_class tpm_tis tpm_tis_core tpm 8250_dw button
acpi_cpufreq sch_fq_codel usbip_host usbip_core sg exfat(O) it87(O) hwmon_vid
ip_tables x_tables algif_skcipher af_alg sd_mod uas usb_storage serio_raw atkbd
libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
aes_x86_64 crypto_simd glue_helper cryptd ccp rng_core ahci xhci_pci libahci
xhci_hcd libata usbcore scsi_mod usb_common i8042 serio amdgpu i2c_algo_bit ttm
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xfs libcrc32c
crc32c_generic crc32c_intel dm_crypt dm_mod dax nvme nvme_core i2c_dev
[ 3196.798554] CPU: 0 PID: 89 Comm: kworker/0:1 Tainted: GW  O   
4.13.0-rc5-amd+ #3
[ 3196.798555] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 0807 07/19/2017
[ 3196.798612] Workqueue: events dm_irq_work_func [amdgpu]
[ 3196.798613] task: 8807fad82940 task.stack: c9000354c000
[ 3196.798626] RIP: 0010:drm_object_property_set_value+0x5d/0x70 [drm]
[ 3196.798627] RSP: 0018:c9000354fdb8 EFLAGS: 00010246
[ 3196.798629] RAX: a04b4c80 RBX: 8807f5896000 RCX:
8807f5896148
[ 3196.798629] RDX:  RSI: 8807fa8bf180 RDI:
8807f5896028
[ 3196.798630] RBP: c9000354fdb8 R08: 0009 R09:

[Bug 98874] amdgpu: [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, [drm] IP block:5 is hang

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98874

--- Comment #13 from dwagner  ---
Notice that my bug report https://bugs.freedesktop.org/show_bug.cgi?id=102322
might be about the same symptom - but using a different GPU architecture, a
bleeding-edge new kernel, and I wanted to report this on the "amdgpu" driver
(not Mesa), because amdgpu produces the only logged error messages, and if the
bug was in Mesa that would not explain why my system totally crashes (and not
just X11).

-- 
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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102322

Bug ID: 102322
   Summary: System crashes after "[drm] IP block:gmc_v8_0 is
hung!" / [drm] IP block:sdma_v3_0 is hung!
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jb5sgc1n@20mm.eu

I consistently experience complete system crashes when browsing web pages using
firefox for about 30 minutes, with the following dmesg output from the amdgpu
driver:

[ 2330.720711] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout,
last signaled seq=40778, last emitted seq=40780
[ 2330.720768] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout,
last signaled seq=31305, last emitted seq=31306
[ 2330.720771] [drm] IP block:gmc_v8_0 is hung!
[ 2330.720774] [drm] IP block:gmc_v8_0 is hung!
[ 2330.720775] [drm] IP block:sdma_v3_0 is hung!
[ 2330.720778] [drm] IP block:sdma_v3_0 is hung!

(Above cited messages are the last to make it to a network-filesystem by
running "dmesg -w" before the system stops to do anything.)

I am running a kernel compiled from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next as of
"commit 94097b0f7f1bfa54b3b1f8b0d74bbd271a0564e4" (so the very latest as of
today).
My GPU is an RX 460.

Notice that this bug may be the same symptom as reported in
https://bugs.freedesktop.org/show_bug.cgi?id=98874

However, the system crashes for me occur usually while vertically scrolling
through some (ordinary) web page.

-- 
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 v4 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

2017-08-20 Thread Hans de Goede 

Hi,

On 20-08-17 15:05, Hans de Goede wrote:

Hi,

Note this v4 is send from my gmail in an attempt to keep the
X-Mailer: git-send-email header which the test-infra wants, but
that seems to have failed.

I've also just send another copy through my isp-s mail server,
but I've not received a copy of that copy myself ? If anyone
else has a second copy of this series can you please check if
the git-send-email header is there ?

If not can someone resend this series so that it can go through
the test infra ?


Ok, it seems that this first attempt (sending through gmail)
actually worked, but I could not see the header because it
gets stripped by the RH mail infra on receiving it too...

Anyways this series now has gone through the Fi.CI.BAT
without problems.

If someone can pick these up and push them to drm-intel-next-queued
that would be great.

Regards,

Hans





On 20-08-17 14:51, Hans de Goede wrote:

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:

intel_runtime_pm_put does:

atomic_dec(_priv->pm.wakeref_count);

pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);

And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).

This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.

Reported-by: FKr 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Reword comment explaining why disabling the wakeref asserts is
  ok and necessary
-Add Imre's Reviewed-by
---
  drivers/gpu/drm/i915/intel_uncore.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1d7b879cc68c..2d3aad319229 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier(struct 
notifier_block *nb,
   * bus, which will be busy after this notification, leading to:
   * "render: timed out waiting for forcewake ack request."
   * errors.
+ *
+ * The notifier is unregistered during intel_runtime_suspend(),
+ * so it's ok to access the HW here without holding a RPM
+ * wake reference -> disable wakeref asserts for the time of
+ * the access.
   */
+disable_rpm_wakeref_asserts(dev_priv);
  intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+enable_rpm_wakeref_asserts(dev_priv);
  break;
  case MBI_PMIC_BUS_ACCESS_END:
  intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);


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

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

2017-08-20 Thread Benjamin Herrenschmidt 
On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:
> So if ARM64 doesn't have these PCI legacy resources, does that mean an
> ARM64 host bridge cannot generate these legacy addresses on PCI?  That
> is, there's no host bridge window that maps to those PCI addresses?
> That seems like a curious restriction on host bridges, but I guess it
> would be possible.

It's rather common. For example on POWER8:

 - 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 we effectively have no path to the legacy areas, and that hasn't
been a problem so far.

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

[Bug 102319] Crashes and freezes when switching VTs

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102319

--- Comment #1 from Ilia Mirkin  ---
Try booting with nouveau.modeset=0 to rule out any nouveau interaction in your
problem.

But perhaps the issue lies in the fact that nouveau suspends the GPU and intel
is waiting on some fence to complete?

-- 
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 99191] Weird blocky green stuff rendered in High Fidelity

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99191

--- Comment #5 from Ilia Mirkin  ---
Tried it on nouveau, but I get a ton of

Mesa: User error: GL_INVALID_VALUE in glBindBufferRange(offset misaligned
704/256)

This is due to the alignment requirements for constant (and texture) buffers
being higher on NVIDIA hw than AMD hw.

-- 
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 v4 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

2017-08-20 Thread Hans de Goede 
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.

Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).

But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset

In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.

This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.

To allow holding the lock over both calls we need an unlocked
variant of iosf_mbi_unregister_pmic_bus_access_notifier. Since
intel_uncore.c is the only user of this function, we simply
modify it in this commit. Doing this in a separate commit would
require first adding an unlocked variant, then this commit and
then removing the unused normal variant.

Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Keep punit acquired / locked over the unregister + forcewake_reset
 call combo to avoid a race hitting between the 2 calls
-This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier
 to not take the lock itself, since we are the only users this is done
 in this same commit

Changes in v4:
-Fix missing rename in doc-comment
-Add and use iosf_mbi_assert_punit_acquired() helper
-Add missing acquiqre surrounding intel_uncore_forcewake_reset() inside
 intel_uncore_check_forcewake_domains()
-Add Imre's Reviewed-by
---
 arch/x86/include/asm/iosf_mbi.h   | 20 +---
 arch/x86/platform/intel/iosf_mbi.c| 20 +++-
 drivers/gpu/drm/i915/intel_uncore.c   | 17 +
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  3 +++
 4 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index c313cac36f56..0f0de4303180 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -139,11 +139,17 @@ void iosf_mbi_punit_release(void);
 int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb);
 
 /**
- * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier
+ * iosf_mbi_register_pmic_bus_access_notifier_unlocked - Unregister PMIC bus
+ *   notifier
+ *
+ * Note the caller must call iosf_mbi_punit_acquire() before calling this
+ * to ensure the bus is inactive before unregistering (and call
+ * iosf_mbi_punit_release() afterwards).
  *
  * @nb: notifier_block to unregister
  */
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb);
 
 /**
  * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier chain
@@ -153,6 +159,11 @@ int iosf_mbi_unregister_pmic_bus_access_notifier(struct 
notifier_block *nb);
  */
 int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v);
 
+/**
+ * iosf_mbi_assert_punit_acquired - Assert that the P-Unit has been acquired.
+ */
+void iosf_mbi_assert_punit_acquired(void);
+
 #else /* CONFIG_IOSF_MBI is not enabled */
 static inline
 bool iosf_mbi_available(void)
@@ -191,7 +202,8 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
 }
 
 static inline
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb)
 {
return 0;
 }
@@ -202,6 +214,8 @@ int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned 
long val, void *v)
return 0;
 }
 
+static inline void iosf_mbi_assert_punit_acquired(void) {}
+
 #endif /* CONFIG_IOSF_MBI */
 
 #endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/platform/intel/iosf_mbi.c 
b/arch/x86/platform/intel/iosf_mbi.c
index a952ac199741..a5361fd11e6e 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -218,19 +218,15 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
 }
 EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
 
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
+int

[PATCH v4 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

2017-08-20 Thread Hans de Goede 
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.

intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.

Reported-by: Imre Deak 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 6 ++
 drivers/gpu/drm/i915/intel_uncore.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 43100229613c..4715f320c8fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2585,6 +2585,8 @@ static int intel_runtime_resume(struct device *kdev)
ret = vlv_resume_prepare(dev_priv, true);
}
 
+   intel_uncore_runtime_resume(dev_priv);
+
/*
 * No point of rolling back things in case of an error, as the best
 * we can do is to hope that things will still work (and disable RPM).
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2d3aad319229..e9ed02518406 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct drm_i915_private 
*dev_priv)
i915_check_and_clear_faults(dev_priv);
 }
 
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
+{
+   iosf_mbi_register_pmic_bus_access_notifier(
+   _priv->uncore.pmic_bus_access_nb);
+}
+
 void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
 {
i915.enable_rc6 = sanitize_rc6_option(dev_priv, i915.enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 5f90278da461..0bdc3fcc0e64 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -121,6 +121,7 @@ bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv
 void intel_uncore_fini(struct drm_i915_private *dev_priv);
 void intel_uncore_suspend(struct drm_i915_private *dev_priv);
 void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
 
 u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
 void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
-- 
2.13.4

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

[PATCH v4 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

2017-08-20 Thread Hans de Goede 
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."

Reported-by: Ville Syrjälä 
Suggested-by: Imre Deak 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4715f320c8fa..5bf231abe010 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2490,6 +2490,8 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_disable_interrupts(dev_priv);
 
+   intel_uncore_suspend(dev_priv);
+
ret = 0;
if (IS_GEN9_LP(dev_priv)) {
bxt_display_core_uninit(dev_priv);
@@ -2502,6 +2504,8 @@ static int intel_runtime_suspend(struct device *kdev)
 
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
+   intel_uncore_runtime_resume(dev_priv);
+
intel_runtime_pm_enable_interrupts(dev_priv);
 
enable_rpm_wakeref_asserts(dev_priv);
@@ -2509,8 +2513,6 @@ static int intel_runtime_suspend(struct device *kdev)
return ret;
}
 
-   intel_uncore_suspend(dev_priv);
-
enable_rpm_wakeref_asserts(dev_priv);
WARN_ON_ONCE(atomic_read(_priv->pm.wakeref_count));
 
-- 
2.13.4

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

[PATCH v4 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

2017-08-20 Thread Hans de Goede 
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:

intel_runtime_pm_put does:

   atomic_dec(_priv->pm.wakeref_count);

   pm_runtime_mark_last_busy(kdev);
   pm_runtime_put_autosuspend(kdev);

And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).

This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.

Reported-by: FKr 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Reword comment explaining why disabling the wakeref asserts is
 ok and necessary
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/intel_uncore.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1d7b879cc68c..2d3aad319229 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier(struct 
notifier_block *nb,
 * bus, which will be busy after this notification, leading to:
 * "render: timed out waiting for forcewake ack request."
 * errors.
+*
+* The notifier is unregistered during intel_runtime_suspend(),
+* so it's ok to access the HW here without holding a RPM
+* wake reference -> disable wakeref asserts for the time of
+* the access.
 */
+   disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+   enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
-- 
2.13.4

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

Re: [PATCH v4 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

2017-08-20 Thread Hans de Goede 

Hi,

Note this v4 is send from my gmail in an attempt to keep the
X-Mailer: git-send-email header which the test-infra wants, but
that seems to have failed.

I've also just send another copy through my isp-s mail server,
but I've not received a copy of that copy myself ? If anyone
else has a second copy of this series can you please check if
the git-send-email header is there ?

If not can someone resend this series so that it can go through
the test infra ?

Regards,

Hans

On 20-08-17 14:51, Hans de Goede wrote:

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:

intel_runtime_pm_put does:

atomic_dec(_priv->pm.wakeref_count);

pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);

And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).

This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.

Reported-by: FKr 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Reword comment explaining why disabling the wakeref asserts is
  ok and necessary
-Add Imre's Reviewed-by
---
  drivers/gpu/drm/i915/intel_uncore.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1d7b879cc68c..2d3aad319229 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier(struct 
notifier_block *nb,
 * bus, which will be busy after this notification, leading to:
 * "render: timed out waiting for forcewake ack request."
 * errors.
+*
+* The notifier is unregistered during intel_runtime_suspend(),
+* so it's ok to access the HW here without holding a RPM
+* wake reference -> disable wakeref asserts for the time of
+* the access.
 */
+   disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+   enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);


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

Re: [PATCH v3 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

2017-08-20 Thread Hans de Goede 

Hi,

On 17-08-17 14:22, Imre Deak wrote:

On Mon, Aug 14, 2017 at 09:58:32PM +0200, Hans de Goede wrote:

intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.

Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).

But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset

In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.

This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.

To allow holding the lock over both calls we need an unlocked
variant of iosf_mbi_unregister_pmic_bus_access_notifier. Since
intel_uncore.c is the only user of this function, we simply
modify it in this commit. Doing this in a separate commit would
require first adding an unlocked variant, then this commit and
then removing the unused normal variant.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Keep punit acquired / locked over the unregister + forcewake_reset
  call combo to avoid a race hitting between the 2 calls
-This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier
  to not take the lock itself, since we are the only users this is done
  in this same commit
---
  arch/x86/include/asm/iosf_mbi.h | 10 --
  arch/x86/platform/intel/iosf_mbi.c  | 14 +-
  drivers/gpu/drm/i915/intel_uncore.c | 17 +
  3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index c313cac36f56..f8841bb06d98 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -141,9 +141,14 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb);
  /**
   * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier


You missed the rename in the doc.


Thx, fixed for v4.


   *
+ * Note the caller must call iosf_mbi_punit_acquire() before calling this
+ * to ensure the bus is inactive before unregistering (and call
+ * iosf_mbi_punit_release() afterwards).
+ *
   * @nb: notifier_block to unregister
   */
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb);
  
  /**

   * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier chain
@@ -191,7 +196,8 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
  }
  
  static inline

-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb)
  {
return 0;
  }
diff --git a/arch/x86/platform/intel/iosf_mbi.c 
b/arch/x86/platform/intel/iosf_mbi.c
index a952ac199741..5596a3ec1b89 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -218,19 +218,15 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
  }
  EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
  
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)

+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb)
  {
-   int ret;
+   WARN_ON(!mutex_is_locked(_mbi_punit_mutex));
  
-	/* Wait for the bus to go inactive before unregistering */

-   mutex_lock(_mbi_punit_mutex);
-   ret = blocking_notifier_chain_unregister(
+   return blocking_notifier_chain_unregister(
_mbi_pmic_bus_access_notifier, nb);
-   mutex_unlock(_mbi_punit_mutex);
-
-   return ret;
  }
-EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier);
+EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier_unlocked);
  
  int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v)

  {
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 569d115918eb..7be6150520ed 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -229,6 +229,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
return HRTIMER_NORESTART;
  }
  
+/* Note callers must have

[Bug 102319] Crashes and freezes when switching VTs

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102319

Bug ID: 102319
   Summary: Crashes and freezes when switching VTs
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: General
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marcin.marci...@gmail.com

I have a weird problem while switching vts

I have a dual-GPU setup: intel i5-5200U as the default OpenGL renderer and
GeForce 940M as the discrete card. I'm using the intel modesetting driver for
the Intel graphics and xf86-video-nouveau for DRI_PRIME.

If I run SDDM/LXDM as my display manager (on Arch Linux), then switch the TTY
to tty2, then switch back to tty7 (DM), I get only a blinking cursor.
If I run LightDM as my display manager, it survives a tty switch, but if I
start an X server in tty2 and then switch directly to tty7, LightDM crashes.
If I switch tty2 -> tty3 (no x server) -> tty7, on the other hand, the DM does
*not* crash.

The whole problem doesn't occur when using the `nomodeset` kernel option, (i.e.
when my DE runs in software rendering mode)

Whenever I switch the ttys or when I launch the DM I get the following output
in the dmesg log: https://pastebin.com/FgzZLEGg

I asked about it on #nouveau and I was told that since the intel driver takes
care of the rendering, it is the one to blame here.

On the intel side, the problem occurs with both xf86-video-intel and the
modesetting driver

The problem only occurs with the X server that is launched by a DM. If I run
startx directly from the tty on both vts, everything works correctly.

It is not observed on a machine without nvidia graphics and with intel i5-7500K
as the CPU/integrated GPU, with fairly same software stack.

OS: Arch Linux, DE: Cinnamon

-- 
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 01/15] EDAC: make device_type const

2017-08-20 Thread Borislav Petkov 
On Sat, Aug 19, 2017 at 01:52:12PM +0530, Bhumika Goyal wrote:
> Make these const as they are only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/edac/edac_mc_sysfs.c | 8 
>  drivers/edac/i7core_edac.c   | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99191] Weird blocky green stuff rendered in High Fidelity

2017-08-20 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99191

Christoph Haag  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Christoph Haag  ---
I've reopened, but feel free to close again if it still doesn't work on other
drivers.

Now that it doesn't hang my GPU anymore I've spent a couple of hours tweaking
the source code, available here:
https://github.com/ChristophHaag/hifi/commits/master

The rendering is better now: The blocky stuff is not green anymore, but it did
not disappear. New video showing the problem:
https://www.youtube.com/watch?v=pda7cNx3ATE

And here is a new trace that runs with an actual 4.5 core context with no mesa
GL errors anymore:
https://haagch.frickel.club/files/interface-blockartifacts.trace.xz (512 mb
uncompressed)

If you want to run this trace right now, you need the patch from bug 102308,
currently on the list
https://lists.freedesktop.org/archives/mesa-dev/2017-August/166827.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

[PATCH 2/4 v2] drm/tve200: Add new driver for TVE200

2017-08-20 Thread Linus Walleij 
This adds a new DRM driver for the Faraday Technology TVE200
block. This "TV Encoder" encodes a ITU-T BT.656 stream and can
be found in the StorLink SL3516 (later Cortina Systems CS3516)
as well as the Grain Media GM8180.

I do not have definitive word from anyone at Faraday that this
IP block is theirs, but it bears the hallmark of their 3-digit
version code (200) and is used in two SoCs from completely
different companies. (Grain Media was fully owned by Faraday
until it was transferred to NovoTek this january, and
Faraday did lots of work on the StorLink SoCs.)

The D-Link DIR-685 uses this in connection with the Ilitek
ILI9322 panel driver that supports BT.656 input, while the
GM8180 apparently has been used with the Cirrus Logic CS4954
digital video encoder. The oldest user seems to be
something called Techwall 2835.

This driver is heavily inspired by Eric Anholt's PL111
driver and therefore I have mentioned all the ancestor authors
in the header file.

Acked-by: Daniel Vetter 
Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Drop .dpms helper as this is no longer needed.
- Fix some spelling fireing->firing
- Constify and staticize mode_config_funcs
- Delete .dumb_destroy and .dumb_map_offset as those are
  now handled by the core
- Reassign drm_gem_cma_free_object() from
  .gem_free_object to .gem_free_object_unlocked
  as we're not using the lock.
- Add CMA helper defaults to vtable entries
  .gem_prime_vmap, .gem_prime_vunmap, .gem_prime_mmap
  as this is necessary for e.g splash screens
- Switch a bunch of messages from dev_err() to
  DRM_DEBUG_KMS() in the display check routine.
---
 Documentation/gpu/index.rst   |   1 +
 Documentation/gpu/tve200.rst  |   6 +
 MAINTAINERS   |   6 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/tve200/Kconfig|  15 ++
 drivers/gpu/drm/tve200/Makefile   |   5 +
 drivers/gpu/drm/tve200/tve200_connector.c | 125 +++
 drivers/gpu/drm/tve200/tve200_display.c   | 344 ++
 drivers/gpu/drm/tve200/tve200_drm.h   | 129 +++
 drivers/gpu/drm/tve200/tve200_drv.c   | 278 
 11 files changed, 912 insertions(+)
 create mode 100644 Documentation/gpu/tve200.rst
 create mode 100644 drivers/gpu/drm/tve200/Kconfig
 create mode 100644 drivers/gpu/drm/tve200/Makefile
 create mode 100644 drivers/gpu/drm/tve200/tve200_connector.c
 create mode 100644 drivers/gpu/drm/tve200/tve200_display.c
 create mode 100644 drivers/gpu/drm/tve200/tve200_drm.h
 create mode 100644 drivers/gpu/drm/tve200/tve200_drv.c

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 35d673bf9b56..c36586dad29d 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide
pl111
tegra
tinydrm
+   tve200
vc4
vga-switcheroo
vgaarbiter
diff --git a/Documentation/gpu/tve200.rst b/Documentation/gpu/tve200.rst
new file mode 100644
index ..69b17b324e12
--- /dev/null
+++ b/Documentation/gpu/tve200.rst
@@ -0,0 +1,6 @@
+==
+ drm/tve200 Faraday TV Encoder 200
+==
+
+.. kernel-doc:: drivers/gpu/drm/tve200/tve200_drv.c
+   :doc: Faraday TV Encoder 200
diff --git a/MAINTAINERS b/MAINTAINERS
index e87cba115ea4..c3d42d68253a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4305,6 +4305,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/bochs/
 
+DRM DRIVER FOR FARADAY TVE200 TV ENCODER
+M: Linus Walleij 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/tve200/
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a88c204..c5e1a8409285 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -278,6 +278,8 @@ source "drivers/gpu/drm/tinydrm/Kconfig"
 
 source "drivers/gpu/drm/pl111/Kconfig"
 
+source "drivers/gpu/drm/tve200/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..cc81813e2238 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -100,3 +100,4 @@ obj-$(CONFIG_DRM_ZTE)   += zte/
 obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
 obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
+obj-$(CONFIG_DRM_TVE200) += tve200/
diff --git a/drivers/gpu/drm/tve200/Kconfig b/drivers/gpu/drm/tve200/Kconfig
new file mode 100644
index ..21d9841ddb88
--- /dev/null
+++ b/drivers/gpu/drm/tve200/Kconfig
@@ -0,0 +1,15 @@
+config DRM_TVE200
+   tristate

[PATCH 1/4 v2] drm/tve200: Add DT bindings

2017-08-20 Thread Linus Walleij 
This adds device tree bindings for the Faraday TVE200 IP block.
This IP block is present in the Gemini ARM SoC and also in some
Grain Media GM SoCs.

Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Fix display port bindings: list required endpoint.
- Fix the example to include an endpoint.
---
 .../devicetree/bindings/display/faraday,tve200.txt | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.txt

diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.txt 
b/Documentation/devicetree/bindings/display/faraday,tve200.txt
new file mode 100644
index ..82e3bc0b7485
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/faraday,tve200.txt
@@ -0,0 +1,54 @@
+* Faraday TV Encoder TVE200
+
+Required properties:
+
+- compatible: must be one of:
+   "faraday,tve200"
+   "cortina,gemini-tvc", "faraday,tve200"
+
+- reg: base address and size of the control registers block
+
+- interrupts: contains an interrupt specifier for the interrupt
+   line from the TVE200
+
+- clock-names: should contain "PCLK" for the clock line clocking the
+   silicon and "TVE" for the 27MHz clock to the video driver
+
+- clocks: contains phandle and clock specifier pairs for the entries
+   in the clock-names property. See
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Optional properties:
+
+- resets: contains the reset line phandle for the block
+
+Required sub-nodes:
+
+- port: describes LCD panel signals, following the common binding
+   for video transmitter interfaces; see
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+   This port should have the properties:
+   reg = <0>;
+   It should have one endpoint connected to a remote endpoint where
+   the display is connected.
+
+Example:
+
+display-controller@6a00 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "faraday,tve200";
+   reg = <0x6a00 0x1000>;
+   interrupts = <13 IRQ_TYPE_EDGE_RISING>;
+   resets = < GEMINI_RESET_TVC>;
+   clocks = < GEMINI_CLK_GATE_TVC>,
+< GEMINI_CLK_TVC>;
+   clock-names = "PCLK", "TVE";
+
+   port@0 {
+   reg = <0>;
+   display_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+};
-- 
2.13.5

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

[PATCH 4/4 v2] ARM: dts: Add TVE/TVC and ILI9322 panel to DIR-685

2017-08-20 Thread Linus Walleij 
This adds the TVE200/TVC TV-encoder and the Ilitek ILI9322 panel
to the DIR-685 device tree.

This brings graphics to this funky router and it is possible to
even run a console on its tiny screen.

Incidentally this requires us to disable the access to the
parallel (NOR) flash, as the communication pins to the panel
are shared with the flash memory.

To access the flash, a separate kernel with the panel disabled
and the flash enabled should be booted. The pin control selecting
whether to use the lines cannot be altered at runtime due to
hardware constraints.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Rename node from "tvc" to "display-controller"

DRM developers: I will merge this patch through the ARM SoC
tree. It is only included in this series for completion.
---
 arch/arm/boot/dts/gemini-dlink-dir-685.dts | 75 +-
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts 
b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
index 094a29624b8d..8e4037597a2c 100644
--- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -46,6 +46,59 @@
};
};
 
+   vdisp: regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "display-power";
+   regulator-min-microvolt = <360>;
+   regulator-max-microvolt = <360>;
+   /* Collides with LCD E */
+   gpio = < 16 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   spi {
+   compatible = "spi-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Collides with IDE pins, that's cool (we do not use them) */
+   gpio-sck = < 5 GPIO_ACTIVE_HIGH>;
+   gpio-miso = < 8 GPIO_ACTIVE_HIGH>;
+   gpio-mosi = < 7 GPIO_ACTIVE_HIGH>;
+   /* Collides with pflash CE1, not so cool */
+   cs-gpios = < 20 GPIO_ACTIVE_HIGH>;
+   num-chipselects = <1>;
+
+   panel: display@0 {
+   compatible = "ilitek,ili9322";
+   reg = <0>;
+   /* 50 ns min period = 20 MHz */
+   spi-max-frequency = <2000>;
+   spi-cpol; /* Clock active low */
+
+   /* Panel LM918A01-1A SY-B4-091116-E0199 */
+   width-mm = <65>;
+   height-mm = <50>;
+   ilitek,entry-mode = <11>;
+   ilitek,vreg1out-microvolt = <4600>;
+   ilitek,vcom-high-percent = <91>;
+   ilitek,vcom-amplitude-percent = <114>;
+   ilitek,gamma-correction-neg = <0xa>, <0x5>, <0x7>,
+   <0x7>, <0x7>, <0x5>, <0x1>, <0x6>;
+   ilitek,gamma-correction-pos = <0x7>, <0x7>, <0x3>,
+   <0x2>, <0x3>, <0x5>, <0x7>, <0x2>;
+   vcc-supply = <>;
+   iovcc-supply = <>;
+   vci-supply = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
led@7 {
@@ -114,7 +167,16 @@
 
soc {
flash@3000 {
-   status = "okay";
+   /*
+* Flash access is by default disabled, because it
+* collides with the Chip Enable signal for the display
+* panel, that reuse the parallel flash Chip Select 1
+* (CS1). Enabling flash makes graphics stop working.
+*
+* We might be able to hack around this by letting
+* GPIO poke around in the flash controller registers.
+*/
+   /* status = "okay"; */
/* 32MB of flash */
reg = <0x3000 0x0200>;
 
@@ -241,5 +303,16 @@
ata@6300 {
status = "okay";
};
+
+   display-controller@6a00 {
+   status = "okay";
+
+   port@0 {
+   reg = <0>;
+   display_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
};
 };
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH 3/4 v2] ARM: dts: Add TVE200 to the Gemini SoC DTSI

2017-08-20 Thread Linus Walleij 
The Faraday TVE200 is present in the Gemini SoC, sometimes
under the name "TVC". Add it to the SoC DTSI file along with
its resources.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Move the definition of cells to this file as it is part
  of the IP binding.
- Rename node from "tvc" to "display-controller"

DRM developers: I will merge this patch through the ARM SoC
tree. It is only included in this series for completion.
---
 arch/arm/boot/dts/gemini.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index c68e8d430234..53baba4d9392 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -141,6 +141,12 @@
groups = "idegrp";
};
};
+   tvc_default_pins: pinctrl-tvc {
+   mux {
+   function = "tvc";
+   groups = "tvcgrp";
+   };
+   };
};
};
 
@@ -346,5 +352,20 @@
memcpy-bus-width = <32>;
#dma-cells = <2>;
};
+
+   display-controller@6a00 {
+   compatible = "cortina,gemini-tvc", "faraday,tve200";
+   reg = <0x6a00 0x1000>;
+   interrupts = <13 IRQ_TYPE_EDGE_RISING>;
+   resets = < GEMINI_RESET_TVC>;
+   clocks = < GEMINI_CLK_GATE_TVC>,
+< GEMINI_CLK_TVC>;
+   clock-names = "PCLK", "TVE";
+   pinctrl-names = "default";
+   pinctrl-0 = <_default_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
};
 };
-- 
2.13.5

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

Re: [PATCH 2/4] drm/tve200: Add new driver for TVE200

2017-08-20 Thread Linus Walleij 
On Mon, Aug 14, 2017 at 8:56 PM, Eric Anholt  wrote:

> I also recommend checking out panel-bridge for deleting a bunch of the
> code,

Daniel said the same. I tried to look into this but the drivers currently
using it (like Atmel HLCDC) are so different using custom encoders and
what not that I can't really see clearly how to apply it in this case.

If you patch the PL111 driver to use the bridge helper I promise I will
follow up and patch this driver the same way though!

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