Re: [PATCH] drm/doc: Make igts for cross-driver stuff strongly suggested

[Jani Nikula]

On Mon, 28 Jan 2019, Daniel Vetter  wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:

This is no longer compatible with the v2 changelog below. ;)

I'm biased so this doesn't carry so much value, but here goes anyway,

Acked-by: Jani Nikula 

>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
>   and a sysroot build (should address all the build/cross platform
>   concerns raised in the RFC discussions).
>
> - tests reorganized into subdirectories so that the i915-gem tests
>   don't clog the main/shared tests directory anymore
>
> - quite a few more non-intel people contributing/reviewing/committing
>   igt tests patches.
>
> I think this addresses all the concerns raised in the RFC discussions,
> and assuming there's enough Acks and no new issues that pop up, we can
> go ahead with this.
>
> v2:
> - Use "should" (in the usual RFC sense) to make it clear that in the
>   end this is all up to reviewer's discretion, as usual (Jani).
> - Also in the title s/mandatory/strongly suggested/ (me)
> - Make it clear we're not going to block features if a testcase is not
>   feasible, given hw and state of igt, both having some good gaps in
>   what can be tested (Harry, Eric, Sean, ...).
>
> 1: https://patchwork.kernel.org/patch/10648851/
> Cc: Petri Latvala 
> Cc: Arkadiusz Hiler 
> Cc: Liviu Dudau 
> Cc: Sean Paul 
> Cc: Eric Anholt 
> Cc: Alex Deucher 
> Cc: Dave Airlie 
> Cc: Daniel Stone 
> Cc: "Wentland, Harry" 
> Cc: Brian Starkey 
> Reviewed-by: Eric Anholt  (v1)
> Acked-by: Petri Latvala 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Sean Paul 
> Acked-by: "Wentland, Harry" 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-uapi.rst | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index a752aa561ea4..c9fd23efd957 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly 
> unintuitive meaning of
>  Testing and validation
>  ==
>  
> +Testing Requirements for userspace API
> +--
> +
> +New cross-driver userspace interface extensions, like new IOCTL, new KMS
> +properties, new files in sysfs or anything else that constitutes an API 
> change
> +should have driver-agnostic testcases in IGT for that feature, if such a test
> +can be reasonably made using IGT for the target hardware.
> +
>  Validating changes with IGT
>  ---

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202445] New: amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202445

Bug ID: 202445
   Summary: amdgpu/dc: framerate dropping below adaptive sync
range causes screen flickering
   Product: Drivers
   Version: 2.5
Kernel Version: 5.0rc4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: li...@protonmail.com
Regression: No

linux 5.0rc4
mesa 4aa64940c
xf86-video-amdgpu a1b479c

hardware:
- R9 Fury
- Samsung C27HG70 (1020.0 firmware, Freesync Ultimate Engine)

I'm running the Unigine Valley benchmark extremely smoothly as long as the
framerate stays in between 48-144fps. When it drops below that, I'm observing
heavy stuttering and flickering in the darker parts of the image. The
flickering also affects the loading screen when frames are rendered very
infrequently.

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

[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator

[bugzilla-daemon]

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

--- Comment #8 from e88z4  ---
Hi, 

This bug still occurs with kernel 5.0-rc4 with Mesa 19.0-devel (commit
932ed9c00b99e6ec92146ec9e820f546cf3e6551). There are more error logs in dmesg
like below.

[ 1132.040752] amdgpu :23:00.0: GPU fault detected: 147 0x0a808802 for
process yuzu pid 19573 thread yuzu:cs0 pid 19577
[ 1132.040761] amdgpu :23:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0003F350
[ 1132.040766] amdgpu :23:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C088002
[ 1132.040773] amdgpu :23:00.0: VM fault (0x02, vmid 6, pasid 32770) at
page 258896, read from 'TC6' (0x54433600) (136)
[ 1142.103758] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=50481, emitted seq=50484
[ 1142.103820] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process yuzu pid 19573 thread yuzu:cs0 pid 19577
[ 1142.103826] amdgpu :23:00.0: GPU reset begin!
[ 1149.487464] WARNING: CPU: 9 PID: 19117 at kernel/kthread.c:501
kthread_park+0x20/0x67
[ 1149.487467] Modules linked in: hid_switchcon hidp tda18271 s5h1411 rfcomm
fuse cmac bnep binfmt_misc amdgpu mfd_core kvm irqbypass ghash_clmulni_intel
btusb btrtl btbcm btintel bluetooth snd_hda_codec_realtek snd_hda_codec_generic
snd_usb_audio snd_usbmidi_lib snd_hda_codec_hdmi sha256_generic snd_rawmidi
snd_pcsp chash gpu_sched saa7164 xpad snd_hda_intel tveeprom drm_kms_helper
joydev evdev aesni_intel syscopyarea dvb_core sysfillrect snd_hda_codec
sysimgblt fb_sys_fops aes_x86_64 snd_hwdep ttm crypto_simd snd_hda_core cryptd
ff_memless drbg glue_helper snd_pcm drm snd_timer i2c_algo_bit videodev snd
ecdh_generic sp5100_tco soundcore k10temp media sg 8250 8250_base serial_core
button acpi_cpufreq nct6775 hwmon_vid autofs4 ext4 crc16 mbcache jbd2 sd_mod
hid_generic usbhid hid i2c_piix4 ahci xhci_pci crc32c_intel i2c_core libahci
xhci_hcd r8169 libata realtek libphy usbcore scsi_mod usb_common
[ 1149.487525] CPU: 9 PID: 19117 Comm: MemoryInfra Not tainted 5.0.0-rc4-htpc+
#3
[ 1149.487526] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./B450M Pro4, BIOS P2.00 12/18/2018
[ 1149.487530] RIP: 0010:kthread_park+0x20/0x67
[ 1149.487533] Code: e8 09 ff ff ff 48 89 c7 eb 8f 55 53 e8 fd fe ff ff f6 47
24 04 74 09 0f 0b b8 da ff ff ff eb 4e 48 89 c3 48 8b 00 a8 04 74 09 <0f> 0b b8
f0 ff ff ff eb 3b 48 89 fd f0 80 0b 04 65 48 8b 04 25 40
[ 1149.487534] RSP: 0018:c900030d7bc0 EFLAGS: 00010202
[ 1149.487537] RAX: 0004 RBX: 88840868f680 RCX:

[ 1149.487538] RDX: 8883d0794330 RSI: 88827243f330 RDI:
88840732ee80
[ 1149.487540] RBP: 888407ad7398 R08: 0001 R09:
888288facd80
[ 1149.487541] R10: 0040 R11: c900030d7bc0 R12:
000d
[ 1149.487543] R13: 0006 R14: 88840b01d000 R15:
88840b01d0f0
[ 1149.487545] FS:  7f96304a6700() GS:88841ee4()
knlGS:
[ 1149.487547] CS:  0010 DS:  ES:  CR0: 80050033
[ 1149.487548] CR2: 7f229032b000 CR3: 000407b9 CR4:
003406e0
[ 1149.487549] Call Trace:
[ 1149.487559]  drm_sched_entity_fini+0x4c/0xeb [gpu_sched]
[ 1149.487612]  amdgpu_ctx_mgr_entity_fini+0x80/0xa8 [amdgpu]
[ 1149.487662]  amdgpu_ctx_mgr_fini+0x22/0x8b [amdgpu]
[ 1149.487706]  amdgpu_driver_postclose_kms+0x188/0x242 [amdgpu]
[ 1149.487717]  drm_file_free+0x1e6/0x22d [drm]
[ 1149.487728]  drm_release+0x75/0xdf [drm]
[ 1149.487733]  __fput+0xe9/0x18f
[ 1149.487737]  task_work_run+0x68/0x7c
[ 1149.487741]  do_exit+0x450/0x917
[ 1149.487744]  do_group_exit+0x95/0x95
[ 1149.487748]  get_signal+0x439/0x461
[ 1149.487752]  do_signal+0x31/0x4cc
[ 1149.487757]  prepare_exit_to_usermode+0x8b/0xf5
[ 1149.487762]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1149.487764] RIP: 0033:0x7f964651ffac
[ 1149.487772] Code: Bad RIP value.
[ 1149.487773] RSP: 002b:7f96304a5640 EFLAGS: 0246 ORIG_RAX:
00ca
[ 1149.487776] RAX: fe00 RBX: 7f96304a57b0 RCX:
7f964651ffac
[ 1149.48] RDX:  RSI: 0080 RDI:
7f96304a57d8
[ 1149.487778] RBP:  R08:  R09:
7fff49705080
[ 1149.487779] R10:  R11: 0246 R12:

[ 1149.487781] R13: 7f96304a5788 R14:  R15:
7f96304a57d8
[ 1149.487784] ---[ end trace 540c7632a8289097 ]---
[ 1152.333861] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:47:crtc-0]
hw_done or flip_done timed out


If you need more clarification or detail, please let me know.

-- 
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

libdrm README rename

[Dave Airlie]

So libdrm README renamed to README.rst, however that means it no
longer gets included in the dist tarball.

I think autotools considers README special, so we might need to fix it,

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

Re: [PATCH v4 RESEND] drm/panel: add Kingdisplay kd097d04 panel driver

[Ezequiel Garcia]

On Mon, 28 Jan 2019 at 12:59, Thierry Reding  wrote:
>
> On Thu, Jan 24, 2019 at 12:51:36PM -0500, Sean Paul wrote:
> > On Thu, Jan 24, 2019 at 05:18:12PM +0100, Thierry Reding wrote:
> > > On Thu, Jan 24, 2019 at 12:01:55PM -0300, Ezequiel Garcia wrote:
> > > > On Tue, 2018-10-30 at 10:15 +0100, Heiko Stuebner wrote:
> > > > > From: Nickey Yang 
> > > > >
> > > > > Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> > > > > it is a MIPI dual-DSI panel.
> > > > >
> > > > > v4-resend:
> > > > > - Thierry noted missing dt-bindings for v4 but forgot that he
> > > > >   already had applied them one kernel release back in
> > > > >   
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df
> > > > > v4:
> > > > > - address Philipp's comments
> > > > >   - real range for usleep_range and
> > > > >   - poweroff ordering in kingdisplay_panel_prepare
> > > > >   - return value beautification in panel_probe
> > > > > - update author naming for full name
> > > > > v3:
> > > > > - address Thierry's comments
> > > > >   - error handling for init dsi writes in init
> > > > >   - unconditionally remove the panel
> > > > >   - don't use drm_panel_detach
> > > > >   - a bit of variable signednes wiggling
> > > > > - I did talk to ChromeOS people and the delays really should be as 
> > > > > short
> > > > >   as possible, so dropped the 100ms from the delay comments
> > > > > v2:
> > > > > - update timing + cmds from chromeos kernel
> > > > > - new backlight API including switch to devm_of_find_backlight
> > > > > - fix most of Sean Paul's comments
> > > > >   enable/prepare tracking seems something all panels do
> > > > > - document origins of the init sequence
> > > > > - lanes per dsi interface to 4 (two interfaces). Matches how tegra
> > > > >   and pending rockchip dual-dsi handle (dual-)dsi lanes
> > > > > - spdx header instead of license boilerplate
> > > > >
> > > > > Signed-off-by: Nickey Yang 
> > > > > Signed-off-by: Heiko Stuebner 
> > > >
> > > > Hm, this v4 patch has been stalling here for *four full months*.
> > > >
> > > > Which deity do we need to pray to get this one moving? ;-)
> > > >
> > > > Seriously, can someone please apply this?
> > >
> > > If you care about this driver, perhaps you'd like to review and provide
> > > a Reviewed-by?
> >
> > Looks good to me,
> >
> > Reviewed-by: Sean Paul 
>
> I was aiming for a Reviewed-by from Ezequiel, but I'll take yours as
> well, thanks very much.
>

Looks like this got reviewed and merged before I could react.

Thanks Sean and reviewing and Thierry for merging it!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/powerplay: Fix missing break in switch

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: cd70f3d6e3fa drm/amd/powerplay: PP/DAL interface changes for 
dynamic clock switch.

The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96.

v4.20.5: Build OK!
v4.19.18: Build OK!
v4.14.96: Failed to apply! Possible dependencies:
Unable to calculate


How should we proceed with this patch?

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

Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects

[Eric Anholt]

Noralf Trønnes  writes:

> Den 28.01.2019 21.57, skrev Rob Herring:
>> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes  wrote:
>>>
>>>
>>> Den 30.11.2018 00.58, skrev Eric Anholt:
 Daniel Vetter  writes:

> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
>> Daniel Vetter  writes:
>>
>>> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
 Daniel Vetter  writes:

> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>> Noralf Trønnes  writes:
>>> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>>> +{
>>> +  struct drm_gem_object *obj = vma->vm_private_data;
>>> +  struct drm_gem_shmem_object *shmem = 
>>> to_drm_gem_shmem_obj(obj);
>>> +
>>> +  drm_gem_shmem_put_pages(shmem);
>>> +  drm_gem_vm_close(vma);
>>> +}
>>> +
>>> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>>> +  .fault = drm_gem_shmem_fault,
>>> +  .open = drm_gem_vm_open,
>>> +  .close = drm_gem_shmem_vm_close,
>>> +};
>>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
>> I just saw a warning from drm_gem_shmem_put_pages() for
>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
>> drm_gem_shmem_get_pages().
> Yeah we need a drm_gem_shmem_vm_open here.
 Adding one of those fixed my refcounting issues, so I've sent out a v6
 with it.
>>> Just realized that I've reviewed this patch already, spotted that vma
>>> management issue there too. Plus a pile of other things. From reading 
>>> that
>>> other thread discussion with Noralf concluded with "not yet ready for
>>> prime time" unfortunately :-/
>> I saw stuff about how it wasn't usable for SPI because SPI does weird
>> things with DMA mapping.  Was there something else?
> Looking through that mail it was a bunch of comments to improve the
> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
> incoherent and horrible (but I guess for vkms we don't care that much).
> I'm just kinda vary of generic buffer handling that turns out to not be
> actually all that useful. We have lots of deadends and kinda-midlayers in
> this area already (but this one here definitely smells plenty better than
> lots of older ones).
 FWIW, I really want shmem helpers for v3d.  The fault handling in
 particular has magic I don't understand, and this is not my first fault
 handler. :/
>>>
>>>
>>> If you can use it for a "real" hw driver like v3d, I think it makes a lot
>>> sense to have it as a helper. I believe udl and a future simpledrm can
>>> also make use of it.
>> 
>> FWIW, I think etnaviv at least could use this too.
>> 
>> I'm starting to look at panfrost and lima drivers and was trying to
>> figure out where to start with the GEM code. So I've been comparing
>> etnaviv, freedreno, and vgem implementations. They are all pretty
>> similar from what I see. The per driver GEM obj structs certainly are.
>> I can't bring myself to just copy etnaviv code over and do a
>> s/etnaviv/panfrost/. So searching around a bit, I ended up on this
>> thread. This seems to be what I need for panfrost (based on my brief
>> study).
>> 
>
> I gave up on this due to problems with SPI DMA.
> Eric tried to use it with vkms, but it failed. On his blog he speculates
> that it might be due to cached CPU mappings:
> https://anholt.github.io/twivc4/2018/12/03/twiv/
>
> For tinydrm I wanted cached mappings, but it might not work that well
> with shmem. Maybe that's why I had problems with SPI DMA.

Actually, for tinydrm buffers that are dma-buf exported through prime, I
really want tinydrm using WC mappings so that vc4 or v3d rendering (now
supported on Mesa master with kmsro) works.


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

Re: [PATCH v5 0/8] drm/msm/dsi: Get PHY ref clocks from the DT

[Matthias Kaehlcke]

Hi,

this series has gone through multiple rounds of review and there are
no outstanding comments. It seems it should be ready to land, or is
there anything left that needs to be addressed?

Thanks

Matthias

On Wed, Dec 19, 2018 at 03:55:20PM -0800, Matthias Kaehlcke wrote:
> The MSM DSI PHY drivers currently hardcode the name and the rate of
> the PHY ref clock. Get the ref clock from the device tree instead.
> 
> Note: testing of this series was limited to SDM845 and the 10nm PHY
> 
> Major changes in v5:
> - none (see per-patch change log for minor changes)
> 
> Major changes in v4:
> - always use parent rate for 28nm and 28nm 8960 PHYs
> 
> Major changes in v3:
> - keep supporting DTs without ref clock for the 28nm and the 28nm
>   8960 PHYs
> - added patch to add ref clock to qcom-apq8064.dtsi
> 
> Major changes in v2:
> - apply to all MSM DSI PHY drivers, not only 10nm
> 
> Matthias Kaehlcke (8):
>   dt-bindings: msm/dsi: Add ref clock for PHYs
>   drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT
>   drm/msm/dsi: 28nm PHY: Get ref clock from the DT
>   drm/msm/dsi: 14nm PHY: Get ref clock from the DT
>   drm/msm/dsi: 10nm PHY: Get ref clock from the DT
>   arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY
>   arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs
>   ARM: dts: qcom-apq8064: Set 'xo_board' as ref clock of the DSI PHY
> 
>  .../devicetree/bindings/display/msm/dsi.txt   |  1 +
>  arch/arm/boot/dts/qcom-apq8064.dtsi   |  5 +--
>  arch/arm64/boot/dts/qcom/msm8916.dtsi |  5 +--
>  arch/arm64/boot/dts/qcom/sdm845.dtsi  | 10 +++---
>  drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c| 20 +--
>  drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c| 23 +---
>  drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c| 36 +--
>  .../gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c   | 24 ++---
>  8 files changed, 92 insertions(+), 32 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: add definitions for DP Audio/Video compliance tests

[Chandan Uddaraju]

This change adds definitions needed for DP audio compliance testing.
It also adds missing definition for DP video compliance.

Changes in V2:
-- Delete cover letter for this patch.
-- Move the description from cover letter into patch commit message.
-- Remove DPU from subject prefix

Signed-off-by: Chandan Uddaraju 
---
 include/drm/drm_dp_helper.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5736c94..e688e05 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -556,6 +556,8 @@
 # define DP_TEST_LINK_EDID_READ(1 << 2)
 # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */
 # define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */
+# define DP_TEST_LINK_AUDIO_PATTERN (1 << 5) /* DPCD >= 1.2 */
+# define DP_TEST_LINK_AUDIO_DISABLED_VIDEO  (1 << 6) /* DPCD >= 1.2 */
 
 #define DP_TEST_LINK_RATE  0x219
 # define DP_LINK_RATE_162  (0x6)
@@ -604,6 +606,7 @@
 # define DP_COLOR_FORMAT_RGB(0 << 1)
 # define DP_COLOR_FORMAT_YCbCr422   (1 << 1)
 # define DP_COLOR_FORMAT_YCbCr444   (2 << 1)
+# define DP_TEST_DYNAMIC_RANGE_VESA (0 << 3)
 # define DP_TEST_DYNAMIC_RANGE_CEA  (1 << 3)
 # define DP_TEST_YCBCR_COEFFICIENTS (1 << 4)
 # define DP_YCBCR_COEFFICIENTS_ITU601   (0 << 4)
@@ -653,6 +656,16 @@
 
 #define DP_TEST_SINK   0x270
 # define DP_TEST_SINK_START(1 << 0)
+#define DP_TEST_AUDIO_MODE 0x271
+#define DP_TEST_AUDIO_PATTERN_TYPE 0x272
+#define DP_TEST_AUDIO_PERIOD_CH1   0x273
+#define DP_TEST_AUDIO_PERIOD_CH2   0x274
+#define DP_TEST_AUDIO_PERIOD_CH3   0x275
+#define DP_TEST_AUDIO_PERIOD_CH4   0x276
+#define DP_TEST_AUDIO_PERIOD_CH5   0x277
+#define DP_TEST_AUDIO_PERIOD_CH6   0x278
+#define DP_TEST_AUDIO_PERIOD_CH7   0x279
+#define DP_TEST_AUDIO_PERIOD_CH8   0x27A
 
 #define DP_FEC_STATUS  0x280/* 1.4 */
 # define DP_FEC_DECODE_EN_DETECTED (1 << 0)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects

[Rob Herring]

On Mon, Jan 28, 2019 at 3:26 PM Noralf Trønnes  wrote:
>
>
>
> Den 28.01.2019 21.57, skrev Rob Herring:
> > On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes  wrote:
> >>
> >>
> >> Den 30.11.2018 00.58, skrev Eric Anholt:
> >>> Daniel Vetter  writes:
> >>>
>  On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> > Daniel Vetter  writes:
> >
> >> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
> >>> Daniel Vetter  writes:
> >>>
>  On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> > Noralf Trønnes  writes:
> >> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> >> +{
> >> +  struct drm_gem_object *obj = vma->vm_private_data;
> >> +  struct drm_gem_shmem_object *shmem = 
> >> to_drm_gem_shmem_obj(obj);
> >> +
> >> +  drm_gem_shmem_put_pages(shmem);
> >> +  drm_gem_vm_close(vma);
> >> +}
> >> +
> >> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
> >> +  .fault = drm_gem_shmem_fault,
> >> +  .open = drm_gem_vm_open,
> >> +  .close = drm_gem_shmem_vm_close,
> >> +};
> >> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> > I just saw a warning from drm_gem_shmem_put_pages() for
> > !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> > drm_gem_shmem_get_pages().
>  Yeah we need a drm_gem_shmem_vm_open here.
> >>> Adding one of those fixed my refcounting issues, so I've sent out a v6
> >>> with it.
> >> Just realized that I've reviewed this patch already, spotted that vma
> >> management issue there too. Plus a pile of other things. From reading 
> >> that
> >> other thread discussion with Noralf concluded with "not yet ready for
> >> prime time" unfortunately :-/
> > I saw stuff about how it wasn't usable for SPI because SPI does weird
> > things with DMA mapping.  Was there something else?
>  Looking through that mail it was a bunch of comments to improve the
>  kerneldoc. Plus a note that buffer sharing/mmap is going to be all
>  incoherent and horrible (but I guess for vkms we don't care that much).
>  I'm just kinda vary of generic buffer handling that turns out to not be
>  actually all that useful. We have lots of deadends and kinda-midlayers in
>  this area already (but this one here definitely smells plenty better than
>  lots of older ones).
> >>> FWIW, I really want shmem helpers for v3d.  The fault handling in
> >>> particular has magic I don't understand, and this is not my first fault
> >>> handler. :/
> >>
> >>
> >> If you can use it for a "real" hw driver like v3d, I think it makes a lot
> >> sense to have it as a helper. I believe udl and a future simpledrm can
> >> also make use of it.
> >
> > FWIW, I think etnaviv at least could use this too.
> >
> > I'm starting to look at panfrost and lima drivers and was trying to
> > figure out where to start with the GEM code. So I've been comparing
> > etnaviv, freedreno, and vgem implementations. They are all pretty
> > similar from what I see. The per driver GEM obj structs certainly are.
> > I can't bring myself to just copy etnaviv code over and do a
> > s/etnaviv/panfrost/. So searching around a bit, I ended up on this
> > thread. This seems to be what I need for panfrost (based on my brief
> > study).
> >
>
> I gave up on this due to problems with SPI DMA.
> Eric tried to use it with vkms, but it failed. On his blog he speculates
> that it might be due to cached CPU mappings:
> https://anholt.github.io/twivc4/2018/12/03/twiv/
>
> For tinydrm I wanted cached mappings, but it might not work that well
> with shmem. Maybe that's why I had problems with SPI DMA.

I think for most ARM systems, a cached mapping is not coherent. So
there will need to be cache flushes using the dma API. I see there's
been some discussion around that too.

> Maybe this change to drm_gem_shmem_mmap() is all it takes:
>
> -   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> +   vma->vm_page_prot = 
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));

Seems like at least this part needs some flexibility. etnaviv,
freedreno, and omap at least all appear to support cached, uncached,
and writecombined based on flags in the GEM object.

> The memory subsystem is really complicated and I have kind of given up
> on trying to decipher it.

Yes. All the more reason to not let each driver figure out what to do.

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

[PATCH v2] staging: android: ion: Allocate from heap ID directly without mask

[Andrew F. Davis]

Previously the heap to allocate from was selected by a mask of allowed
heap types. This may have been done as a primitive form of constraint
solving, the first heap type that matched any set bit of the heap mask
was allocated from, unless that heap was excluded by having its heap
ID bit not set in the separate passed in heap ID mask.

The heap type does not really represent constraints that should be
matched against to begin with. So the patch [0] removed the the heap type
mask matching but unfortunately left the heap ID mask check (possibly by
mistake or to preserve API). Therefor we now only have a mask of heap
IDs, but heap IDs are unique identifiers and have nothing to do with the
underlying heap, so mask matching is not useful here. This also limits us
to 32 heaps total in a system.

With the heap query API users can find the right heap based on type or
name themselves then just supply the ID for that heap. Remove heap ID
mask and allow users to specify heap ID directly by its number.

I know this is an ABI break, but we are in staging so lets get this over
with now rather than limit ourselves later.

[0] commit 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client")

Signed-off-by: Andrew F. Davis 
---

This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?

This is base on -next as to be on top of the other taken Ion patches.

Changes from v1:
 - Fix spelling in commit message
 - Cleanup logic per Brian's suggestion

 drivers/staging/android/ion/ion.c  | 28 +---
 drivers/staging/android/uapi/ion.h |  6 ++
 2 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 92c2914239e3..b0b0d0b587c2 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,7 +387,7 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
 };
 
-static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+static int ion_alloc(size_t len, unsigned int heap_id, unsigned int flags)
 {
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
@@ -396,27 +396,25 @@ static int ion_alloc(size_t len, unsigned int 
heap_id_mask, unsigned int flags)
int fd;
struct dma_buf *dmabuf;
 
-   pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
-len, heap_id_mask, flags);
-   /*
-* traverse the list of heaps available in this system in priority
-* order.  If the heap type is supported by the client, and matches the
-* request of the caller allocate from it.  Repeat until allocate has
-* succeeded or all heaps have been tried
-*/
+   pr_debug("%s: len %zu heap_id %u flags %x\n", __func__,
+len, heap_id, flags);
+
len = PAGE_ALIGN(len);
 
if (!len)
return -EINVAL;
 
+   /*
+* Traverse the list of heaps available in this system.  If the
+* heap id matches the request of the caller allocate from it.
+*/
down_read(&dev->lock);
plist_for_each_entry(heap, &dev->heaps, node) {
-   /* if the caller didn't specify this heap id */
-   if (!((1 << heap->id) & heap_id_mask))
-   continue;
-   buffer = ion_buffer_create(heap, dev, len, flags);
-   if (!IS_ERR(buffer))
+   /* if the caller specified this heap id */
+   if (heap->id == heap_id) {
+   buffer = ion_buffer_create(heap, dev, len, flags);
break;
+   }
}
up_read(&dev->lock);
 
@@ -541,7 +539,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
int fd;
 
fd = ion_alloc(data.allocation.len,
-  data.allocation.heap_id_mask,
+  data.allocation.heap_id,
   data.allocation.flags);
if (fd < 0)
return fd;
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 5d7009884c13..6a78a1e23251 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -35,8 +35,6 @@ enum ion_heap_type {
   */
 };
 
-#define ION_NUM_HEAP_IDS   (sizeof(unsigned int) * 8)
-
 /**
  * allocation flags - the lower 16 bits are used by core ion, the upper 16
  * bits are reserved for use by the heaps themselves.
@@ -59,7 +57,7 @@ enum ion_heap_type {
 /**
  * struct ion_allocation_data - metadata passed from userspace for allocations
  * @len:   size of the allocation
- * @heap_id_mask:  mask of heap ids to allocate fr

[Bug 109487] drm-next-5.1-wip broken as of 672c6238

[bugzilla-daemon]

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

--- Comment #3 from asavah  ---
No, sadly it doesn't help.
Additional observations:
If amdgpu is built as module the system boots without graphics, but networking
and ssh are working, however it's impossible to reboot the system, it just
hangs after issuing "reboot".
If amdgpu is built-in (with embedded raven* firmware blobs) the system just
hangs with black screen, no network.

-- 
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: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects

[Noralf Trønnes]

Den 28.01.2019 21.57, skrev Rob Herring:
> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes  wrote:
>>
>>
>> Den 30.11.2018 00.58, skrev Eric Anholt:
>>> Daniel Vetter  writes:
>>>
 On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> Daniel Vetter  writes:
>
>> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
>>> Daniel Vetter  writes:
>>>
 On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> Noralf Trønnes  writes:
>> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>> +{
>> +  struct drm_gem_object *obj = vma->vm_private_data;
>> +  struct drm_gem_shmem_object *shmem = 
>> to_drm_gem_shmem_obj(obj);
>> +
>> +  drm_gem_shmem_put_pages(shmem);
>> +  drm_gem_vm_close(vma);
>> +}
>> +
>> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>> +  .fault = drm_gem_shmem_fault,
>> +  .open = drm_gem_vm_open,
>> +  .close = drm_gem_shmem_vm_close,
>> +};
>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> I just saw a warning from drm_gem_shmem_put_pages() for
> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> drm_gem_shmem_get_pages().
 Yeah we need a drm_gem_shmem_vm_open here.
>>> Adding one of those fixed my refcounting issues, so I've sent out a v6
>>> with it.
>> Just realized that I've reviewed this patch already, spotted that vma
>> management issue there too. Plus a pile of other things. From reading 
>> that
>> other thread discussion with Noralf concluded with "not yet ready for
>> prime time" unfortunately :-/
> I saw stuff about how it wasn't usable for SPI because SPI does weird
> things with DMA mapping.  Was there something else?
 Looking through that mail it was a bunch of comments to improve the
 kerneldoc. Plus a note that buffer sharing/mmap is going to be all
 incoherent and horrible (but I guess for vkms we don't care that much).
 I'm just kinda vary of generic buffer handling that turns out to not be
 actually all that useful. We have lots of deadends and kinda-midlayers in
 this area already (but this one here definitely smells plenty better than
 lots of older ones).
>>> FWIW, I really want shmem helpers for v3d.  The fault handling in
>>> particular has magic I don't understand, and this is not my first fault
>>> handler. :/
>>
>>
>> If you can use it for a "real" hw driver like v3d, I think it makes a lot
>> sense to have it as a helper. I believe udl and a future simpledrm can
>> also make use of it.
> 
> FWIW, I think etnaviv at least could use this too.
> 
> I'm starting to look at panfrost and lima drivers and was trying to
> figure out where to start with the GEM code. So I've been comparing
> etnaviv, freedreno, and vgem implementations. They are all pretty
> similar from what I see. The per driver GEM obj structs certainly are.
> I can't bring myself to just copy etnaviv code over and do a
> s/etnaviv/panfrost/. So searching around a bit, I ended up on this
> thread. This seems to be what I need for panfrost (based on my brief
> study).
> 

I gave up on this due to problems with SPI DMA.
Eric tried to use it with vkms, but it failed. On his blog he speculates
that it might be due to cached CPU mappings:
https://anholt.github.io/twivc4/2018/12/03/twiv/

For tinydrm I wanted cached mappings, but it might not work that well
with shmem. Maybe that's why I had problems with SPI DMA.

Maybe this change to drm_gem_shmem_mmap() is all it takes:

-   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));

The memory subsystem is really complicated and I have kind of given up
on trying to decipher it.

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

Re: [PATCH 2/4] drm/msm: dpu: Simplify frame_done watchdog timeout calculation

[Abhinav Kumar]

On 2019-01-28 12:42, Sean Paul wrote:

From: Sean Paul 

Instead of setting the timeout and then immediately reading it back
(along with the hand-rolled msecs_to_jiffies calculation), just
calculate it once and set it in both places at the same time.

Signed-off-by: Sean Paul 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dd71cb6ba4f5c..83a4c47dbed2d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1791,6 +1791,7 @@ void dpu_encoder_kickoff(struct drm_encoder
*drm_enc, bool async)
 {
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
+   unsigned long timeout_ms;
ktime_t wakeup_time;
unsigned int i;

@@ -1803,11 +1804,12 @@ void dpu_encoder_kickoff(struct drm_encoder
*drm_enc, bool async)

trace_dpu_enc_kickoff(DRMID(drm_enc));

-   atomic_set(&dpu_enc->frame_done_timeout,
-   DPU_FRAME_DONE_TIMEOUT * 1000 /
-   
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
-   mod_timer(&dpu_enc->frame_done_timer, jiffies +
-   ((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
+   timeout_ms = DPU_FRAME_DONE_TIMEOUT * 1000 /
+   drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
+
+   atomic_set(&dpu_enc->frame_done_timeout, timeout_ms);
+   mod_timer(&dpu_enc->frame_done_timer,
+ jiffies + msecs_to_jiffies(timeout_ms));

/* All phys encs are ready to go, trigger the kickoff */
_dpu_encoder_kickoff_phys(dpu_enc, async);

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

Re: [PATCH 1/4] drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh

[Abhinav Kumar]

On 2019-01-28 12:42, Sean Paul wrote:

From: Sean Paul 

Use the drm_mode_vrefresh helper where we need refresh rate in case
vrefresh is empty.

Signed-off-by: Sean Paul 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 6 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 941ac25d2a023..dd71cb6ba4f5c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -522,8 +522,8 @@ static void _dpu_encoder_adjust_mode(struct
drm_connector *connector,

list_for_each_entry(cur_mode, &connector->modes, head) {
if (cur_mode->vdisplay == adj_mode->vdisplay &&
-   cur_mode->hdisplay == adj_mode->hdisplay &&
-   cur_mode->vrefresh == adj_mode->vrefresh) {
+   cur_mode->hdisplay == adj_mode->hdisplay &&
+   drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode)) 
{
adj_mode->private = cur_mode->private;
adj_mode->private_flags |= cur_mode->private_flags;
}
@@ -1805,7 +1805,7 @@ void dpu_encoder_kickoff(struct drm_encoder
*drm_enc, bool async)

atomic_set(&dpu_enc->frame_done_timeout,
DPU_FRAME_DONE_TIMEOUT * 1000 /
-   drm_enc->crtc->state->adjusted_mode.vrefresh);
+   
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
mod_timer(&dpu_enc->frame_done_timer, jiffies +
((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 99ab5ca9bed3b..f21163313d635 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -404,7 +404,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
return;
}

-   tc_cfg.vsync_count = vsync_hz / (mode->vtotal * mode->vrefresh);
+   tc_cfg.vsync_count = vsync_hz /
+   (mode->vtotal * drm_mode_vrefresh(mode));

/* enable external TE after kickoff to avoid premature autorefresh */
tc_cfg.hw_vsync_mode = 0;
@@ -424,7 +425,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
DPU_DEBUG_CMDENC(cmd_enc,
"tc %d vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
phys_enc->hw_pp->idx - PINGPONG_0, vsync_hz,
-   mode->vtotal, mode->vrefresh);
+   mode->vtotal, drm_mode_vrefresh(mode));
DPU_DEBUG_CMDENC(cmd_enc,
"tc %d enable %u start_pos %u rd_ptr_irq %u\n",
phys_enc->hw_pp->idx - PINGPONG_0, tc_enable, tc_cfg.start_pos,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index b01183b309b9e..da1f727d74957 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -387,7 +387,7 @@ static void _dpu_plane_set_ot_limit(struct 
drm_plane *plane,

ot_params.width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
ot_params.height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
-   ot_params.frame_rate = crtc->mode.vrefresh;
+   ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
ot_params.vbif_idx = VBIF_RT;
ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
ot_params.rd = true;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
index c1962f29ec7d6..6341ac010f7de 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
@@ -59,10 +59,10 @@ static int pingpong_tearcheck_setup(struct
drm_encoder *encoder,
return -EINVAL;
}

-   total_lines_x100 = mode->vtotal * mode->vrefresh;
+   total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode);
if (!total_lines_x100) {
DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
-   __func__, mode->vtotal, mode->vrefresh);
+ __func__, mode->vtotal, drm_mode_vrefresh(mode));
return -EINVAL;
}

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

[PATCH] drm/nouveau: Don't WARN_ON VCPI allocation failures

[Lyude Paul]

This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.

Signed-off-by: Lyude Paul 
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
multi-stream")
Cc: Ben Skeggs 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc:  # v4.10+
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2e8a5fd9b262..09a9c747c7bb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -811,7 +811,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
 
slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots);
-   WARN_ON(!r);
+   if (!r)
+   DRM_DEBUG_KMS("Failed to allocate VCPI\n");
 
if (!mstm->links++)
nv50_outp_acquire(mstm->outp);
-- 
2.20.1

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

Re: [PATCH AUTOSEL 4.19 083/258] drm: Move drm_mode_setcrtc() local re-init to failure path

[Sean Paul]

On Mon, Jan 28, 2019 at 10:56:29AM -0500, Sasha Levin wrote:
> From: Sean Paul 
> 
> [ Upstream commit c232e9f41b136c141df9938024e521191a7b910d ]
> 
> Instead of always re-initializing the variables we need to clean up on
> out, move the re-initialization into the branch that goes back to retry
> label.
> 
> This is a lateral move right now, but will allow us to pull out the
> modeset locking into common code. I kept this change separate to make
> things easier to review.
> 
> Changes in v2:
> - None
> 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-2-s...@poorly.run
> Signed-off-by: Sasha Levin 

This probably doesn't need to get pulled back to stable. It was a pre-cursor for
some new helper macros that also don't need to be pulled back.

(Same comment for the 4.20 version)

Sean

> ---
>  drivers/gpu/drm/drm_crtc.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9cbe8f5c9aca..ed9d7fc4cb2c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -567,9 +567,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   struct drm_mode_crtc *crtc_req = data;
>   struct drm_crtc *crtc;
>   struct drm_plane *plane;
> - struct drm_connector **connector_set, *connector;
> - struct drm_framebuffer *fb;
> - struct drm_display_mode *mode;
> + struct drm_connector **connector_set = NULL, *connector;
> + struct drm_framebuffer *fb = NULL;
> + struct drm_display_mode *mode = NULL;
>   struct drm_mode_set set;
>   uint32_t __user *set_connectors_ptr;
>   struct drm_modeset_acquire_ctx ctx;
> @@ -598,10 +598,6 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   mutex_lock(&crtc->dev->mode_config.mutex);
>   drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  retry:
> - connector_set = NULL;
> - fb = NULL;
> - mode = NULL;
> -
>   ret = drm_modeset_lock_all_ctx(crtc->dev, &ctx);
>   if (ret)
>   goto out;
> @@ -763,6 +759,12 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   }
>   kfree(connector_set);
>   drm_mode_destroy(dev, mode);
> +
> + /* In case we need to retry... */
> + connector_set = NULL;
> + fb = NULL;
> + mode = NULL;
> +
>   if (ret == -EDEADLK) {
>   ret = drm_modeset_backoff(&ctx);
>   if (!ret)
> -- 
> 2.19.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects

[Rob Herring]

On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes  wrote:
>
>
> Den 30.11.2018 00.58, skrev Eric Anholt:
> > Daniel Vetter  writes:
> >
> >> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> >>> Daniel Vetter  writes:
> >>>
>  On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
> > Daniel Vetter  writes:
> >
> >> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> >>> Noralf Trønnes  writes:
>  +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>  +{
>  +  struct drm_gem_object *obj = vma->vm_private_data;
>  +  struct drm_gem_shmem_object *shmem = 
>  to_drm_gem_shmem_obj(obj);
>  +
>  +  drm_gem_shmem_put_pages(shmem);
>  +  drm_gem_vm_close(vma);
>  +}
>  +
>  +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>  +  .fault = drm_gem_shmem_fault,
>  +  .open = drm_gem_vm_open,
>  +  .close = drm_gem_shmem_vm_close,
>  +};
>  +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> >>> I just saw a warning from drm_gem_shmem_put_pages() for
> >>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> >>> drm_gem_shmem_get_pages().
> >> Yeah we need a drm_gem_shmem_vm_open here.
> > Adding one of those fixed my refcounting issues, so I've sent out a v6
> > with it.
>  Just realized that I've reviewed this patch already, spotted that vma
>  management issue there too. Plus a pile of other things. From reading 
>  that
>  other thread discussion with Noralf concluded with "not yet ready for
>  prime time" unfortunately :-/
> >>> I saw stuff about how it wasn't usable for SPI because SPI does weird
> >>> things with DMA mapping.  Was there something else?
> >> Looking through that mail it was a bunch of comments to improve the
> >> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
> >> incoherent and horrible (but I guess for vkms we don't care that much).
> >> I'm just kinda vary of generic buffer handling that turns out to not be
> >> actually all that useful. We have lots of deadends and kinda-midlayers in
> >> this area already (but this one here definitely smells plenty better than
> >> lots of older ones).
> > FWIW, I really want shmem helpers for v3d.  The fault handling in
> > particular has magic I don't understand, and this is not my first fault
> > handler. :/
>
>
> If you can use it for a "real" hw driver like v3d, I think it makes a lot
> sense to have it as a helper. I believe udl and a future simpledrm can
> also make use of it.

FWIW, I think etnaviv at least could use this too.

I'm starting to look at panfrost and lima drivers and was trying to
figure out where to start with the GEM code. So I've been comparing
etnaviv, freedreno, and vgem implementations. They are all pretty
similar from what I see. The per driver GEM obj structs certainly are.
I can't bring myself to just copy etnaviv code over and do a
s/etnaviv/panfrost/. So searching around a bit, I ended up on this
thread. This seems to be what I need for panfrost (based on my brief
study).

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

[PATCH v2 0/3] drm/i915: MST and wakeref leak fixes

[Lyude Paul]

While trying to fix a problem with suspend/resume that I introduced in
the atomic VCPI helpers for MST, I also ran into some issues with i915
varying from "not that bad" to "oh wow that's very bad". Here are the
fixes for those issues.

This series was originally just one patch,
"drm/i915: Don't send MST hotplugs during resume"

Lyude Paul (3):
  drm/i915: Block fbdev HPD processing during suspend
  drm/i915: Don't send MST hotplugs during resume
  drm/i915: Don't send hotplug in intel_dp_check_mst_status()

 drivers/gpu/drm/i915/intel_dp.c| 13 +++--
 drivers/gpu/drm/i915/intel_drv.h   | 10 ++
 drivers/gpu/drm/i915/intel_fbdev.c | 30 +-
 3 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.20.1

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

[PATCH v2 2/3] drm/i915: Don't send MST hotplugs during resume

[Lyude Paul]

We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though since hotplug events are already sent from
drm_dp_connector_destroy_work() every time connectors are unregistered
from userspace's PoV. Additionally, extra calls to
drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
connector probe somewhere we shouldn't.

So, don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.

Signed-off-by: Lyude Paul 
Cc: Imre Deak 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..c2399acf177b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private 
*dev_priv)
continue;
 
ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr);
-   if (ret)
-   intel_dp_check_mst_status(intel_dp);
+   if (ret) {
+   intel_dp->is_mst = false;
+   drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+   false);
+   }
}
 }
-- 
2.20.1

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

[PATCH v2 1/3] drm/i915: Block fbdev HPD processing during suspend

[Lyude Paul]

When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.

However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.

This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.

(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).

We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.

This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.

Signed-off-by: Lyude Paul 
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte 
Cc: Dave Airlie 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Imre Deak 
Cc: intel-...@lists.freedesktop.org
Cc:  # v3.17+
---
 drivers/gpu/drm/i915/intel_drv.h   | 10 ++
 drivers/gpu/drm/i915/intel_fbdev.c | 30 +-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913ea6e80..c8549588b2ce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -213,6 +213,16 @@ struct intel_fbdev {
unsigned long vma_flags;
async_cookie_t cookie;
int preferred_bpp;
+
+   /* Whether or not fbdev hpd processing is temporarily suspended */
+   bool hpd_suspended : 1;
+   /* Set when a hotplug was received while HPD processing was
+* suspended
+*/
+   bool hpd_waiting : 1;
+
+   /* Protects hpd_suspended */
+   struct mutex hpd_lock;
 };
 
 struct intel_encoder {
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 8cf3efe88f02..3a6c0bebaaf9 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -681,6 +681,7 @@ int intel_fbdev_init(struct drm_device *dev)
if (ifbdev == NULL)
return -ENOMEM;
 
+   mutex_init(&ifbdev->hpd_lock);
drm_fb_helper_prepare(dev, &ifbdev->helper, &intel_fb_helper_funcs);
 
if (!intel_fbdev_init_bios(dev, ifbdev))
@@ -754,6 +755,23 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
intel_fbdev_destroy(ifbdev);
 }
 
+/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
+ * processing, fbdev will perform a full connector reprobe if a hotplug event
+ * was received while HPD was suspended.
+ */
+static void intel_fbdev_hpd_set_suspend(struct intel_fbdev *ifbdev, int state)
+{
+   mutex_lock(&ifbdev->hpd_lock);
+   ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
+   if (ifbdev->hpd_waiting) {
+   ifbdev->hpd_waiting = false;
+
+   DRM_DEBUG_KMS("Handling delayed fbcon HPD event\n");
+   drm_fb_helper_hotplug_event(&ifbdev->helper);
+   }
+   mutex_unlock(&ifbdev->hpd_lock);
+}
+
 void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -775,6 +793,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool syn

[PATCH v2 3/3] drm/i915: Don't send hotplug in intel_dp_check_mst_status()

[Lyude Paul]

This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.

Signed-off-by: Lyude Paul 
Cc: Imre Deak 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c2399acf177b..f9113c0cdfcd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4608,12 +4608,10 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
 
return ret;
} else {
-   struct intel_digital_port *intel_dig_port = 
dp_to_dig_port(intel_dp);
DRM_DEBUG_KMS("failed to get ESI - device may have 
failed\n");
intel_dp->is_mst = false;
-   drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, 
intel_dp->is_mst);
-   /* send a hotplug event */
-   
drm_kms_helper_hotplug_event(intel_dig_port->base.base.dev);
+   drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+   intel_dp->is_mst);
}
}
return -EINVAL;
-- 
2.20.1

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

[PATCH 4/4] drm/msm: dpu: Don't queue the frame_done watchdog for cursor

[Sean Paul]

From: Sean Paul 

In the case of an async/cursor update, we don't wait for the frame_done
event, which means handle_frame_done is never called, and the frame_done
watchdog isn't canceled. Currently, this results in a frame_done timeout
every time the cursor moves without a synchronous frame following it up
before the timeout expires. Since we don't wait for frame_done, and
don't handle it, we shouldn't modify the watchdog.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 51e46b206c73e..05145cf9fb408 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1794,7 +1794,6 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 {
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
-   unsigned long timeout_ms;
ktime_t wakeup_time;
unsigned int i;
 
@@ -1807,12 +1806,20 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 
trace_dpu_enc_kickoff(DRMID(drm_enc));
 
-   timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
-   drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
+   /*
+* Asynchronous frames don't handle FRAME_DONE events. As such, they
+* shouldn't enable the frame_done watchdog since it will always time
+* out.
+*/
+   if (!async) {
+   unsigned long timeout_ms;
+   timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
+   drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
 
-   atomic_set(&dpu_enc->frame_done_timeout_ms, timeout_ms);
-   mod_timer(&dpu_enc->frame_done_timer,
- jiffies + msecs_to_jiffies(timeout_ms));
+   atomic_set(&dpu_enc->frame_done_timeout_ms, timeout_ms);
+   mod_timer(&dpu_enc->frame_done_timer,
+ jiffies + msecs_to_jiffies(timeout_ms));
+   }
 
/* All phys encs are ready to go, trigger the kickoff */
_dpu_encoder_kickoff_phys(dpu_enc, async);
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 3/4] drm/msm: dpu: Untangle frame_done timeout units

[Sean Paul]

From: Sean Paul 

There exists a bunch of confusion as to what the actual units of
frame_done is:

- The definition states it's in # of frames
- CRTC treats it like it's ms
- frame_done_timeout comment thinks it's Hz, but it stores ms
- frame_done timer is setup such that it _should_ be in frames, but the
  timeout is super long

So this patch tries to interpret what the driver really wants. I've
de-centralized the #define since the consumers are expecting different
units.

For crtc, we just use 60ms since that's what it was doing before.
Perhaps we could get fancy and scale with vrefresh, but that's for
another time.

For encoder, fix the comments and rename frame_done_timeout so it's
obvious what the units are. In practice, frame_done_timeout is really
just checked against 0 || !0, which I guess is why the units being wrong
didn't matter. I've also dropped the timeout from the previous 60 frames
to 5. That seems like more than enough time to give up on a frame, and
my guess is that no one intended for the timeout to _actually_ be 60
frames.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |  3 ---
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4e4b64821c9e8..b0b394af2a7ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -46,6 +46,9 @@
 #define LEFT_MIXER 0
 #define RIGHT_MIXER 1
 
+/* timeout in ms waiting for frame done */
+#define DPU_CRTC_FRAME_DONE_TIMEOUT_MS 60
+
 static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
 {
struct msm_drm_private *priv = crtc->dev->dev_private;
@@ -683,7 +686,7 @@ static int _dpu_crtc_wait_for_frame_done(struct drm_crtc 
*crtc)
 
DPU_ATRACE_BEGIN("frame done completion wait");
ret = wait_for_completion_timeout(&dpu_crtc->frame_done_comp,
-   msecs_to_jiffies(DPU_FRAME_DONE_TIMEOUT));
+   msecs_to_jiffies(DPU_CRTC_FRAME_DONE_TIMEOUT_MS));
if (!ret) {
DRM_ERROR("frame done wait timed out, ret:%d\n", ret);
rc = -ETIMEDOUT;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 83a4c47dbed2d..51e46b206c73e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -69,6 +69,9 @@
 
 #define MAX_VDISPLAY_SPLIT 1080
 
+/* timeout in frames waiting for frame done */
+#define DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES 5
+
 /**
  * enum dpu_enc_rc_events - events for resource control state machine
  * @DPU_ENC_RC_EVENT_KICKOFF:
@@ -158,7 +161,7 @@ enum dpu_enc_rc_states {
  * Bit0 = phys_encs[0] etc.
  * @crtc_frame_event_cb:   callback handler for frame event
  * @crtc_frame_event_cb_data:  callback handler private data
- * @frame_done_timeout:frame done timeout in Hz
+ * @frame_done_timeout_ms: frame done timeout in ms
  * @frame_done_timer:  watchdog timer for frame done event
  * @vsync_event_timer: vsync timer
  * @disp_info: local copy of msm_display_info struct
@@ -196,7 +199,7 @@ struct dpu_encoder_virt {
void (*crtc_frame_event_cb)(void *, u32 event);
void *crtc_frame_event_cb_data;
 
-   atomic_t frame_done_timeout;
+   atomic_t frame_done_timeout_ms;
struct timer_list frame_done_timer;
struct timer_list vsync_event_timer;
 
@@ -1184,7 +1187,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder 
*drm_enc)
}
 
/* after phys waits for frame-done, should be no more frames pending */
-   if (atomic_xchg(&dpu_enc->frame_done_timeout, 0)) {
+   if (atomic_xchg(&dpu_enc->frame_done_timeout_ms, 0)) {
DPU_ERROR("enc%d timeout pending\n", drm_enc->base.id);
del_timer_sync(&dpu_enc->frame_done_timer);
}
@@ -1341,7 +1344,7 @@ static void dpu_encoder_frame_done_callback(
}
 
if (!dpu_enc->frame_busy_mask[0]) {
-   atomic_set(&dpu_enc->frame_done_timeout, 0);
+   atomic_set(&dpu_enc->frame_done_timeout_ms, 0);
del_timer(&dpu_enc->frame_done_timer);
 
dpu_encoder_resource_control(drm_enc,
@@ -1804,10 +1807,10 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 
trace_dpu_enc_kickoff(DRMID(drm_enc));
 
-   timeout_ms = DPU_FRAME_DONE_TIMEOUT * 1000 /
+   timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
 
-   atomic_set(&dpu_enc->frame_done_timeout, timeout_ms);
+   atomic_set(&dpu_enc->frame_done_timeout_ms, timeout_ms);

[PATCH 2/4] drm/msm: dpu: Simplify frame_done watchdog timeout calculation

[Sean Paul]

From: Sean Paul 

Instead of setting the timeout and then immediately reading it back
(along with the hand-rolled msecs_to_jiffies calculation), just
calculate it once and set it in both places at the same time.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dd71cb6ba4f5c..83a4c47dbed2d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1791,6 +1791,7 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 {
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
+   unsigned long timeout_ms;
ktime_t wakeup_time;
unsigned int i;
 
@@ -1803,11 +1804,12 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 
trace_dpu_enc_kickoff(DRMID(drm_enc));
 
-   atomic_set(&dpu_enc->frame_done_timeout,
-   DPU_FRAME_DONE_TIMEOUT * 1000 /
-   
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
-   mod_timer(&dpu_enc->frame_done_timer, jiffies +
-   ((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
+   timeout_ms = DPU_FRAME_DONE_TIMEOUT * 1000 /
+   drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
+
+   atomic_set(&dpu_enc->frame_done_timeout, timeout_ms);
+   mod_timer(&dpu_enc->frame_done_timer,
+ jiffies + msecs_to_jiffies(timeout_ms));
 
/* All phys encs are ready to go, trigger the kickoff */
_dpu_encoder_kickoff_phys(dpu_enc, async);
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[PATCH 1/4] drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh

[Sean Paul]

From: Sean Paul 

Use the drm_mode_vrefresh helper where we need refresh rate in case
vrefresh is empty.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 6 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 941ac25d2a023..dd71cb6ba4f5c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -522,8 +522,8 @@ static void _dpu_encoder_adjust_mode(struct drm_connector 
*connector,
 
list_for_each_entry(cur_mode, &connector->modes, head) {
if (cur_mode->vdisplay == adj_mode->vdisplay &&
-   cur_mode->hdisplay == adj_mode->hdisplay &&
-   cur_mode->vrefresh == adj_mode->vrefresh) {
+   cur_mode->hdisplay == adj_mode->hdisplay &&
+   drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode)) 
{
adj_mode->private = cur_mode->private;
adj_mode->private_flags |= cur_mode->private_flags;
}
@@ -1805,7 +1805,7 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc, 
bool async)
 
atomic_set(&dpu_enc->frame_done_timeout,
DPU_FRAME_DONE_TIMEOUT * 1000 /
-   drm_enc->crtc->state->adjusted_mode.vrefresh);
+   
drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
mod_timer(&dpu_enc->frame_done_timer, jiffies +
((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 99ab5ca9bed3b..f21163313d635 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -404,7 +404,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
return;
}
 
-   tc_cfg.vsync_count = vsync_hz / (mode->vtotal * mode->vrefresh);
+   tc_cfg.vsync_count = vsync_hz /
+   (mode->vtotal * drm_mode_vrefresh(mode));
 
/* enable external TE after kickoff to avoid premature autorefresh */
tc_cfg.hw_vsync_mode = 0;
@@ -424,7 +425,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
DPU_DEBUG_CMDENC(cmd_enc,
"tc %d vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
phys_enc->hw_pp->idx - PINGPONG_0, vsync_hz,
-   mode->vtotal, mode->vrefresh);
+   mode->vtotal, drm_mode_vrefresh(mode));
DPU_DEBUG_CMDENC(cmd_enc,
"tc %d enable %u start_pos %u rd_ptr_irq %u\n",
phys_enc->hw_pp->idx - PINGPONG_0, tc_enable, tc_cfg.start_pos,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index b01183b309b9e..da1f727d74957 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -387,7 +387,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane *plane,
ot_params.width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
ot_params.height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
-   ot_params.frame_rate = crtc->mode.vrefresh;
+   ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
ot_params.vbif_idx = VBIF_RT;
ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
ot_params.rd = true;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
index c1962f29ec7d6..6341ac010f7de 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
@@ -59,10 +59,10 @@ static int pingpong_tearcheck_setup(struct drm_encoder 
*encoder,
return -EINVAL;
}
 
-   total_lines_x100 = mode->vtotal * mode->vrefresh;
+   total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode);
if (!total_lines_x100) {
DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
-   __func__, mode->vtotal, mode->vrefresh);
+ __func__, mode->vtotal, drm_mode_vrefresh(mode));
return -EINVAL;
}
 
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[Bug 109487] drm-next-5.1-wip broken as of 672c6238

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Does reverting this commit help?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=12c51ee226c12933d0188b8f04804166a69f6f6e

-- 
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 109487] drm-next-5.1-wip broken as of 672c6238

[bugzilla-daemon]

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

asavah  changed:

   What|Removed |Added

 Attachment #143242|0   |1
is obsolete||

--- Comment #1 from asavah  ---
Created attachment 143243
  --> https://bugs.freedesktop.org/attachment.cgi?id=143243&action=edit
another dmesg with warning backtrace before GPF

Previous dmesg was from a build containing a patch to make shut up the warning
which hasn't been fixed for months ...

-- 
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 109487] drm-next-5.1-wip broken as of 672c6238

[bugzilla-daemon]

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

Bug ID: 109487
   Summary: drm-next-5.1-wip broken as of 672c6238
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: irher...@gmail.com

Created attachment 143242
  --> https://bugs.freedesktop.org/attachment.cgi?id=143242&action=edit
dmesg with backtrace

Currently https://cgit.freedesktop.org/~agd5f/linux/tree/?h=drm-next-5.1-wip is
totally broken at least for raven 2400g apu.

4.20.5 works pretty well on this machine.

Dmesg with backtrace attached.

Dear AMD developers: it would be bad if drm-next-5.1-wip code in its current
state went into mainline, please review and fix.

-- 
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 v6 1/2] dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.

Add dt-bingings for it.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
---
Changes for v6, v5, v4, v3:
- none
Changes for v2:
- new patch, derived from another dsi series 

 .../display/panel/feiyang,fy07024di26a30d.txt | 20 +++
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt 
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
new file mode 100644
index ..82caa7b65ae8
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
@@ -0,0 +1,20 @@
+Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
+
+Required properties:
+- compatible: must be "feiyang,fy07024di26a30d"
+- reg: DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+   compatible = "feiyang,fy07024di26a30d";
+   reg = <0>;
+   avdd-supply = <®_dc1sw>;
+   dvdd-supply = <®_dldo2>;
+   reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+   backlight = <&backlight>;
+};
-- 
2.18.0.321.gffc6fa0e3

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

[PATCH v6 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.

Add panel driver for it.

Reviewed-by: Sam Ravnborg 
Tested-by: Bhushan Shah 
Signed-off-by: Jagan Teki 
---
Changes for v6:
- add space b/w msleep and comment line
- use multi comment line style
- add sentinel
- collect Sam Ravnborg Reviewed-by
Changes for v5:
- drop drmP.h header
- order include files
- add empty line after kzalloc()
- drop gpio set for reset
- drop backlight put_device from probe()
- drop backlight put_device from remove()
- collect Tested-by from Bhushan Shah
Changes for v4:
- rebase on master
- adjust the hporch values to satisfy the refresh
Changes for v3:
- use simple structure for command init
- update proper comments on power, reset delay sequnce
- fix to use set_display_off in disable function
- move mode type to structure
- drop refres rate value, let drm compute
Changes for v2:
- new patch, derived from another dsi series

 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-feiyang-fy07024di26a30d.c | 271 ++
 4 files changed, 287 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e3f785bad68b..5c8591eb5840 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4831,6 +4831,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
+M: Jagan Teki 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+F: 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 151ddf720b83..5304db7b7b55 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -47,6 +47,15 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_FEIYANG_FY07024DI26A30D
+   tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Feiyang FY07024DI26A30-D MIPI-DSI interface.
+
 config DRM_PANEL_ILITEK_IL9322
tristate "Ilitek ILI9322 320x240 QVGA panels"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 54db0921f329..c88dacf9d439 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_BANANAPI_S070WV20_ICN6211) += 
panel-bananapi-s070wv20-icn6211.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c 
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
new file mode 100644
index ..4ecf408d6492
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FEIYANG_INIT_CMD_LEN   2
+
+struct feiyang {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator*dvdd;
+   struct regulator*avdd;
+   struct gpio_desc*reset;
+};
+
+static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
+{
+   return container_of(panel, struct feiyang, panel);
+}
+
+struct feiyang_init_cmd {
+   u8 data[FEIYANG_INIT_CMD_LEN];
+};
+
+static const struct feiyang_init_cmd feiyang_init_cmds[] = {
+   { .data = { 0x80, 0x58 } },
+   { .data = { 0x81, 0x47 } },
+   { .data = { 0x82, 0xD4 } },
+   { .data = { 0x83, 0x88 } },
+   { .data = { 0x84, 0xA9 } },
+   { .data = { 0x85, 0xC3 } },
+   { .data = { 0x86, 0x82 } },
+};
+
+static int feiyang_prepare(struct drm_panel *panel)
+{
+   struct feiyang *ctx = panel_to_feiyang(panel);
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   unsigned int i;
+   int ret;
+
+   ret = regulator_enable(ctx->dvdd);
+   if (ret)
+   ret

[PULL] drm-intel-next

[Rodrigo Vivi]

Hi Dave,

This pull includes the tag as described below and the GVT stuff, which
"
includes Coffeelake support for GVT,
making kvmgt as self load module to have better dependence with
vfio/mdev, with some const treatment and kernel type change.
"

Also please notice that we have a drm color management LUT validation helper
coming on this bucket.


Here goes drm-intel-next-2019-01-24:
- Track all runtime-PM wakerefs and other rpm improvements (Chris)
- Fix ILK-IVB primary plane enable delays (Juha-Pekka)
- Differentiate between gtt->mutex and ppgtt->mutex (Chris)
- Prevent concurrent GGTT update and use on Braswell (Chris)
- Fix CNL macros for DDI vswing (Aditya)
- Fix static code analysis warning (RK)
- Only dump GPU state on set-wedged if interesting (Chris)
- Port F detection improvements (Imre)
- userptr mutex lock fixes (Chris)
- Fix on MST allocation by propagating error value at compute_config (Lyude)
- Serialise concurrent calls to set_wedge (Chris)
- Unify reset functionality into i915_reset.c (Chris)
- Switch to kernel fixed size types (Jani)
- Limit the for_each_set_bit to the valid range (Chris)
- Fix wakeref cooie handling (Tvrtko)
- IRQs handling improvements (Chris)
- Selftests improvements (Chris)
- Remove superfluous PANEL_POWER_OFF macro (Jani)
- Global seqno fix (Chris)
- DSI fixes (Hans)
- Refactor out intel_context_init() (Chris)
- Show all active engines on hangcheck (Chris)
- PSR2 fixes and improvements (Jose)
- Do a posting read after irq install on Ice Lake (Daniele)
- Add few more device IDs for Ice Lake (Rodrigo)
- Mark up priority boost on preemption (Chris)
- Add color management LUT validation helper (Matt)
- Split out intel_crt_present to platform specific setup (Jani)
- LVDS and TV clean up and improvements (Jani)
- Simplify CRT VBT check for per-VLV/DDI (Jani)
- De-inline intel_context_init() (Chris)
- Backlight fixes (Maarten)
- Enable fastset for non-boot modesets (Maarten)
- Make HW readout mark CRTC scaler as in use (Maarten)

Thanks,
Rodrigo.

The following changes since commit f164a94c2c87752caeb1a3cbe068c440e7f7921f:

  Merge tag 'drm-misc-next-2019-01-16' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-01-18 09:31:28 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-01-24

for you to fetch changes up to 85baa5dbf79163026dcb78f742294c522e176432:

  drm/i915: Update DRIVER_DATE to 20190124 (2019-01-24 15:00:59 -0800)


- Track all runtime-PM wakerefs and other rpm improvements (Chris)
- Fix ILK-IVB primary plane enable delays (Juha-Pekka)
- Differentiate between gtt->mutex and ppgtt->mutex (Chris)
- Prevent concurrent GGTT update and use on Braswell (Chris)
- Fix CNL macros for DDI vswing (Aditya)
- Fix static code analysis warning (RK)
- Only dump GPU state on set-wedged if interesting (Chris)
- Port F detection improvements (Imre)
- userptr mutex lock fixes (Chris)
- Fix on MST allocation by propagating error value at compute_config (Lyude)
- Serialise concurrent calls to set_wedge (Chris)
- Unify reset functionality into i915_reset.c (Chris)
- Switch to kernel fixed size types (Jani)
- Limit the for_each_set_bit to the valid range (Chris)
- Fix wakeref cooie handling (Tvrtko)
- IRQs handling improvements (Chris)
- Selftests improvements (Chris)
- Remove superfluous PANEL_POWER_OFF macro (Jani)
- Global seqno fix (Chris)
- DSI fixes (Hans)
- Refactor out intel_context_init() (Chris)
- Show all active engines on hangcheck (Chris)
- PSR2 fixes and improvements (Jose)
- Do a posting read after irq install on Ice Lake (Daniele)
- Add few more device IDs for Ice Lake (Rodrigo)
- Mark up priority boost on preemption (Chris)
- Add color management LUT validation helper (Matt)
- Split out intel_crt_present to platform specific setup (Jani)
- LVDS and TV clean up and improvements (Jani)
- Simplify CRT VBT check for per-VLV/DDI (Jani)
- De-inline intel_context_init() (Chris)
- Backlight fixes (Maarten)
- Enable fastset for non-boot modesets (Maarten)
- Make HW readout mark CRTC scaler as in use (Maarten)


Aditya Swarup (1):
  drm/i915/cnl: Fix CNL macros for Voltage Swing programming

Chris Wilson (46):
  drm/i915: Track all held rpm wakerefs
  drm/i915: Markup paired operations on wakerefs
  drm/i915: Track GT wakeref
  drm/i915: Track the rpm wakerefs for error handling
  drm/i915: Mark up sysfs with rpm wakeref tracking
  drm/i915: Mark up debugfs with rpm wakeref tracking
  drm/i915/perf: Track the rpm wakeref
  drm/i915/pmu: Track rpm wakeref
  drm/i915/guc: Track the rpm wakeref
  drm/i915/gem: Track the rpm wakerefs
  drm/i915/fb: Track rpm wakerefs
  drm/i915/hotplug: Track temporary rpm wakeref
  drm/i915/panel: Track temporary rpm wakeref
  drm/i915/selftests: Mark up rpm wakerefs
  drm/i9

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

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

--- Comment #54 from Shmerl  ---
(In reply to Jerry Zuo from comment #53)
> The fix should show up in the coming release.

Great, thanks!

-- 
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 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

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

--- Comment #53 from Jerry Zuo  ---
The fix should show up in the coming release.

-- 
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/doc: Make igts for cross-driver stuff strongly suggested

[Liviu Dudau]

On Mon, Jan 28, 2019 at 06:22:58PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
> 
> - gitlab CI builds with: reduced configs/libraries, arm cross build
>   and a sysroot build (should address all the build/cross platform
>   concerns raised in the RFC discussions).
> 
> - tests reorganized into subdirectories so that the i915-gem tests
>   don't clog the main/shared tests directory anymore
> 
> - quite a few more non-intel people contributing/reviewing/committing
>   igt tests patches.
> 
> I think this addresses all the concerns raised in the RFC discussions,
> and assuming there's enough Acks and no new issues that pop up, we can
> go ahead with this.
> 
> v2:
> - Use "should" (in the usual RFC sense) to make it clear that in the
>   end this is all up to reviewer's discretion, as usual (Jani).
> - Also in the title s/mandatory/strongly suggested/ (me)
> - Make it clear we're not going to block features if a testcase is not
>   feasible, given hw and state of igt, both having some good gaps in
>   what can be tested (Harry, Eric, Sean, ...).
> 
> 1: https://patchwork.kernel.org/patch/10648851/
> Cc: Petri Latvala 
> Cc: Arkadiusz Hiler 
> Cc: Liviu Dudau 
> Cc: Sean Paul 
> Cc: Eric Anholt 
> Cc: Alex Deucher 
> Cc: Dave Airlie 
> Cc: Daniel Stone 
> Cc: "Wentland, Harry" 
> Cc: Brian Starkey 
> Reviewed-by: Eric Anholt  (v1)
> Acked-by: Petri Latvala 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Sean Paul 
> Acked-by: "Wentland, Harry" 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-uapi.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index a752aa561ea4..c9fd23efd957 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly 
> unintuitive meaning of
>  Testing and validation
>  ==
>  
> +Testing Requirements for userspace API
> +--
> +
> +New cross-driver userspace interface extensions, like new IOCTL, new KMS
> +properties, new files in sysfs or anything else that constitutes an API 
> change
> +should have driver-agnostic testcases in IGT for that feature, if such a test
> +can be reasonably made using IGT for the target hardware.
> +
>  Validating changes with IGT
>  ---

Acked-by: Liviu Dudau 

Thanks for the updates!

Best regards,
Liviu

>  
> -- 
> 2.20.1
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/doc: Make igts for cross-driver stuff strongly suggested

[Daniel Vetter]

Compared to the RFC[1] no changes to the patch itself, but igt moved
forward a lot:

- gitlab CI builds with: reduced configs/libraries, arm cross build
  and a sysroot build (should address all the build/cross platform
  concerns raised in the RFC discussions).

- tests reorganized into subdirectories so that the i915-gem tests
  don't clog the main/shared tests directory anymore

- quite a few more non-intel people contributing/reviewing/committing
  igt tests patches.

I think this addresses all the concerns raised in the RFC discussions,
and assuming there's enough Acks and no new issues that pop up, we can
go ahead with this.

v2:
- Use "should" (in the usual RFC sense) to make it clear that in the
  end this is all up to reviewer's discretion, as usual (Jani).
- Also in the title s/mandatory/strongly suggested/ (me)
- Make it clear we're not going to block features if a testcase is not
  feasible, given hw and state of igt, both having some good gaps in
  what can be tested (Harry, Eric, Sean, ...).

1: https://patchwork.kernel.org/patch/10648851/
Cc: Petri Latvala 
Cc: Arkadiusz Hiler 
Cc: Liviu Dudau 
Cc: Sean Paul 
Cc: Eric Anholt 
Cc: Alex Deucher 
Cc: Dave Airlie 
Cc: Daniel Stone 
Cc: "Wentland, Harry" 
Cc: Brian Starkey 
Reviewed-by: Eric Anholt  (v1)
Acked-by: Petri Latvala 
Acked-by: Arkadiusz Hiler 
Acked-by: Sean Paul 
Acked-by: "Wentland, Harry" 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-uapi.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index a752aa561ea4..c9fd23efd957 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly 
unintuitive meaning of
 Testing and validation
 ==
 
+Testing Requirements for userspace API
+--
+
+New cross-driver userspace interface extensions, like new IOCTL, new KMS
+properties, new files in sysfs or anything else that constitutes an API change
+should have driver-agnostic testcases in IGT for that feature, if such a test
+can be reasonably made using IGT for the target hardware.
+
 Validating changes with IGT
 ---
 
-- 
2.20.1

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

Re: [PATCH] drm/doc: Make igts for cross-driver stuff mandatory

[Daniel Vetter]

Hi Liviu,

On Mon, Jan 28, 2019 at 3:03 PM Liviu Dudau  wrote:
>
> On Tue, Jan 22, 2019 at 05:28:19PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 22, 2019 at 5:11 PM Sean Paul  wrote:
> > > On Tue, Jan 22, 2019 at 04:17:25PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 22, 2019 at 4:08 PM Brian Starkey  
> > > > wrote:
> > > > >
> > > > > On Tue, Jan 22, 2019 at 03:03:59PM +0100, Daniel Vetter wrote:
> > > > > > On Tue, Jan 22, 2019 at 2:27 PM Brian Starkey 
> > > > > >  wrote:
> > > > >
> > >
> > > /snip
> > >
> > > >
> > > > > > > > > > That seems a bit out of order to me. It would be like me 
> > > > > > > > > > saying "all
> > > > > > > > > > KMS drivers must use Arm's test suite, which uses writeback 
> > > > > > > > > > and pixel
> > > > > > > > > > checking", and you'd be in a pickle because you don't have 
> > > > > > > > > > writeback.
> > > > > > > > > >
> > > > > > > > > > In a similar vein, I remember having to fix igt on devices 
> > > > > > > > > > which
> > > > > > > > > > didn't have cursor planes, before I could even think about 
> > > > > > > > > > writing
> > > > > > > > > > tests.
> > > > > > > > > >
> > > > > > > > > > If you can prove that issues like these are all resolved 
> > > > > > > > > > now in igt,
> > > > > > > > > > then great! Otherwise, I don't think igt is "ready" to be 
> > > > > > > > > > used as a
> > > > > > > > > > requirement for merging KMS kernel API.
> > > > > > > >
> > > > > > > > With a night's worth of sleep, this here is what annoys me - you
> > > > > > > > demand I "prove" that igt works everywhere. That's not 
> > > > > > > > realistic.
> > > > > > > > Intel is not going to pay the bill to get a CI farm for every 
> > > > > > > > drm
> > > > > > > > driver existing up&running, including fixing all the bugs that 
> > > > > > > > will
> > > > > > > > uncover (both in igt and even more so in drivers). Especially 
> > > > > > > > not if
> > > > > > > > mere mortals can't even buy the hardware. Nor is anyone else 
> > > > > > > > going to
> > > > > > > > do that. If there are some fundamental overall issues with igt 
> > > > > > > > then
> > > > > > > > I'm ofc happy to get them addressed (like the build issues 
> > > > > > > > raised a
> > > > > > > > few months ago).
> > > > > > >
> > > > > > > I'm really not asking you to. I'm sorry that I've annoyed you, 
> > > > > > > and I'm
> > > > > > > not being deliberately awkward.
> > > > > > >
> > > > > > > I genuinely don't know what the current state of "not-i915" 
> > > > > > > testing is
> > > > > > > in igt. Do you really not think it's a good idea to have that 
> > > > > > > known
> > > > > > > and documented before you make igt a mandatory part of the DRM 
> > > > > > > tree?
> > > > > > >
> > > > > > > Sure, there's commits from non-intel folks - heck there's even a 
> > > > > > > few
> > > > > > > from me. But I can tell you right away that doesn't mean that igt
> > > > > > > works in any meaningful way on my platform. Does it work well 
> > > > > > > enough
> > > > > > > for me to add new test cases? Honestly I don't know.
> > > > > > >
> > > > > > > Maybe you can suggest some suites which are expected to already be
> > > > > > > fully generic and should run anywhere which we can use as
> > > > > > > confirmation? To me, having some reasonable subset of the active
> > > > > > > driver devs building and running that on their platforms and 
> > > > > > > reporting
> > > > > > > back before you merge this patch wouldn't be unreasonable or
> > > > > > > outlandish.
> > > > > >
> > > > > > So my Grand Plan is to get vkms up to par, and even get that
> > > > > > integrated into igt and drm autobuilds we'll run on gitlab CI. But
> > > > > > vkms is still a few internships away from being useful, atm it has 
> > > > > > one
> > > > > > primary plane and one non-plane cursor (it's not even a universal
> > > > > > cursor plane yet). Will give you _lots_ of skips.
> > > > > >
> > > > > > But I guess we could fairly easily add vkms as one of the machines
> > > > > > we're testing to intel's CI farm, which means every patch and every
> > > > > > commit gets at least tested on non-i915, and you'll get tons of data
> > > > > > of which tests blow up, and even more which will just skip (due to
> > > > > > lack of features on vkms' side). We did have that situation a while
> > > > > > back with amdgpu and kbl-g (the intel+amd gpu's chip), but only by
> > > > > > accident (we do still run i915+amdgpu buffer sharing tests, since we
> > > > > > care about that). Took us a while to realize that igt preferred
> > > > > > running on amdgpu somehow. Running random non-i915 chips in our CI
> > > > > > farm isn't something that'll happen, but vkms should not be hard to
> > > > > > set up and get going.
> > > > > >
> > > > > > Would that be useful if we get that done first?
> > > > >
> > > > > Sure, that would be useful. I'm not even saying I want it in CI
> > > > > though, just for some people who aren't @intel.com to try it on 

Re: [PATCH v2] drm/meson: Fix atomic mode switching regression

[Greg KH]

On Mon, Jan 28, 2019 at 05:21:12PM +0100, Neil Armstrong wrote:
> Hi Stable kernel team,
> 
> On 14/01/2019 16:31, Neil Armstrong wrote:
> > Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
> > example) the display gets blurry, looking like an invalid framebuffer width.
> > 
> > This commit fixed atomic crtc modesetting in a totally wrong way and
> > introduced a local unnecessary ->enabled crtc state.
> > 
> > This commit reverts the crctc _begin() and _enable() changes and simply
> > adds drm_atomic_helper_commit_tail_rpm as helper.
> > 
> > Reported-by: Tony McKahan 
> > Suggested-by: Daniel Vetter 
> > Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
> > Signed-off-by: Neil Armstrong 
> 
> This fix has landed in linus master with id 
> ce0210c12433031aba3bbacd75f4c02ab77f2004
> 
> could it be applied to 4.19 and 4.20 stable trees ?

Now queued up, thanks.

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

[PATCH v2] drm/msm/dpu: remove struct encoder_kickoff_params

[Sean Paul]

From: Bruce Wang 

The contents of struct encoder_kickoff_params are never used. Remove the
structure and all remnants of it from function calls.

Changes in v2 (seanpaul):
- Actually remove the struct (Jeykumar)

Cc: Jeykumar Sankaran 
Signed-off-by: Bruce Wang 
Signed-off-by: Sean Paul 
---

Sending v2 since Bruce has returned to school.

Sean

 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  7 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  7 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 13 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h|  3 +--
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c|  5 ++---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c|  5 ++---
 6 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4e4b64821c9e8..f3a37aa4d0988 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -716,11 +716,8 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc, bool 
async)
 * may delay and flush at an irq event (e.g. ppdone)
 */
drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc->state->encoder_mask) {
-   struct dpu_encoder_kickoff_params params = { 0 };
-   dpu_encoder_prepare_for_kickoff(encoder, ¶ms, async);
-   }
-
+ crtc->state->encoder_mask)
+   dpu_encoder_prepare_for_kickoff(encoder, async);
 
if (!async) {
/* wait for frame_event_done completion */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 941ac25d2a023..b2c86762bcf29 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1747,15 +1747,14 @@ static void dpu_encoder_vsync_event_work_handler(struct 
kthread_work *work)
nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
 }
 
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc,
-   struct dpu_encoder_kickoff_params *params, bool async)
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc, bool async)
 {
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
bool needs_hw_reset = false;
unsigned int i;
 
-   if (!drm_enc || !params) {
+   if (!drm_enc) {
DPU_ERROR("invalid args\n");
return;
}
@@ -1769,7 +1768,7 @@ void dpu_encoder_prepare_for_kickoff(struct drm_encoder 
*drm_enc,
phys = dpu_enc->phys_encs[i];
if (phys) {
if (phys->ops.prepare_for_kickoff)
-   phys->ops.prepare_for_kickoff(phys, params);
+   phys->ops.prepare_for_kickoff(phys);
if (phys->enable_state == DPU_ENC_ERR_NEEDS_HW_RESET)
needs_hw_reset = true;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 3f5dafe00580e..d77f74fb26d4b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -37,15 +37,6 @@ struct dpu_encoder_hw_resources {
enum dpu_intf_mode intfs[INTF_MAX];
 };
 
-/**
- * dpu_encoder_kickoff_params - info encoder requires at kickoff
- * @affected_displays:  bitmask, bit set means the ROI of the commit lies 
within
- *  the bounds of the physical display at the bit index
- */
-struct dpu_encoder_kickoff_params {
-   unsigned long affected_displays;
-};
-
 /**
  * dpu_encoder_get_hw_resources - Populate table of required hardware resources
  * @encoder:   encoder pointer
@@ -88,11 +79,9 @@ void dpu_encoder_register_frame_event_callback(struct 
drm_encoder *encoder,
  * Immediately: if no previous commit is outstanding.
  * Delayed: Block until next trigger can be issued.
  * @encoder:   encoder pointer
- * @params:kickoff time parameters
  * @async: true if this is an asynchronous commit
  */
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder,
-   struct dpu_encoder_kickoff_params *params, bool async);
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder,  bool async);
 
 /**
  * dpu_encoder_trigger_kickoff_pending - Clear the flush bits from previous
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 44e6f8b68e70d..db94f3d3bea31 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -144,8 +144,7 @@ struct dpu_encoder_phys_ops {
int (*wait_for_commit_done)(struct dpu_encoder_phys *phys_enc);
int (*wait_for_tx_complete)(struct dpu_encoder_phys *phys_enc);

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

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

--- Comment #52 from Shmerl  ---
(In reply to Jerry Zuo from comment #51)
> Good to hear that the patch fixes your issue. The official patch will be
> merged to the next kernel release. Thank you so much for your dedicated
> testing and prompt feedback ^_^

Thanks! Do you mean the fix will land in 5.0 or the one release after that?

-- 
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 AUTOSEL 3.18 45/61] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/console/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index eb976ee3a02f..614d3209d465 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3018,7 +3018,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 3.18 43/61] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 8a29ec5992fd..ea2bd6208a2f 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -433,7 +433,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -445,7 +447,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

[PATCH AUTOSEL 3.18 42/61] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index 49a7bb4ef02f..dd8fd28d6132 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.4 58/80] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 8a29ec5992fd..ea2bd6208a2f 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -433,7 +433,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -445,7 +447,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.4 57/80] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index 649b32f78c08..c55109524fd5 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.4 60/80] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/console/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 4e3c78d88832..c03c5b9602bb 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3032,7 +3032,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.4 01/80] drm/bufs: Fix Spectre v1 vulnerability

[Sasha Levin]

From: "Gustavo A. R. Silva" 

[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma->buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181016095549.ga23...@embeddedor.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_bufs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index f1a204d253cc..ac22b8d86249 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
 #include 
 #include "drm_legacy.h"
 
+#include 
+
 static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
  struct drm_local_map *map)
 {
@@ -1332,6 +1334,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
  idx, dma->buf_count - 1);
return -EINVAL;
}
+   idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 079/107] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/console/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 4db10d7990c9..178b507a6fe0 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3030,7 +3030,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 075/107] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index ff561073ee4e..42f909618f04 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 076/107] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 74273bc7ca9a..a1d93151c059 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -433,7 +433,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -445,7 +447,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

Re: [PATCH v9 2/2] drm/panel: Add Sitronix ST7701 panel driver

[Thierry Reding]

On Fri, Jan 25, 2019 at 03:21:31AM +0530, Jagan Teki wrote:
[...]
> +static const struct of_device_id st7701_of_match[] = {
> + { .compatible = "techstar,ts8550b", .data = &ts8550b_desc },

checkpatch flags techstar as being an undocumented vendor prefix. Can
you please send a patch that adds it?

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 v2] drm/meson: Fix atomic mode switching regression

[Neil Armstrong]

Hi Stable kernel team,

On 14/01/2019 16:31, Neil Armstrong wrote:
> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
> example) the display gets blurry, looking like an invalid framebuffer width.
> 
> This commit fixed atomic crtc modesetting in a totally wrong way and
> introduced a local unnecessary ->enabled crtc state.
> 
> This commit reverts the crctc _begin() and _enable() changes and simply
> adds drm_atomic_helper_commit_tail_rpm as helper.
> 
> Reported-by: Tony McKahan 
> Suggested-by: Daniel Vetter 
> Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
> Signed-off-by: Neil Armstrong 

This fix has landed in linus master with id 
ce0210c12433031aba3bbacd75f4c02ab77f2004

could it be applied to 4.19 and 4.20 stable trees ?

Thanks,
Neil

> ---
>  drivers/gpu/drm/meson/meson_crtc.c | 23 ++-
>  drivers/gpu/drm/meson/meson_drv.c  |  6 ++
>  2 files changed, 8 insertions(+), 21 deletions(-)
> 
> Changes since v1:
> - drop the unecessary local ->enabled logic
> - use drm_atomic_helper_commit_tail_rpm as atomic_commit_tail helper
> 
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
> b/drivers/gpu/drm/meson/meson_crtc.c
> index 75d97f1b2e8f..4f5c67f70c4d 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -46,7 +46,6 @@ struct meson_crtc {
>   struct drm_crtc base;
>   struct drm_pending_vblank_event *event;
>   struct meson_drm *priv;
> - bool enabled;
>  };
>  #define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
>  
> @@ -82,7 +81,8 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
>  
>  };
>  
> -static void meson_crtc_enable(struct drm_crtc *crtc)
> +static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
> +  struct drm_crtc_state *old_state)
>  {
>   struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>   struct drm_crtc_state *crtc_state = crtc->state;
> @@ -108,20 +108,6 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
>  
>   drm_crtc_vblank_on(crtc);
>  
> - meson_crtc->enabled = true;
> -}
> -
> -static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
> -  struct drm_crtc_state *old_state)
> -{
> - struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
> - struct meson_drm *priv = meson_crtc->priv;
> -
> - DRM_DEBUG_DRIVER("\n");
> -
> - if (!meson_crtc->enabled)
> - meson_crtc_enable(crtc);
> -
>   priv->viu.osd1_enabled = true;
>  }
>  
> @@ -153,8 +139,6 @@ static void meson_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>  
>   crtc->state->event = NULL;
>   }
> -
> - meson_crtc->enabled = false;
>  }
>  
>  static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
> @@ -163,9 +147,6 @@ static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
>   struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>   unsigned long flags;
>  
> - if (crtc->state->enable && !meson_crtc->enabled)
> - meson_crtc_enable(crtc);
> -
>   if (crtc->state->event) {
>   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 3ee4d4a4ecba..a74d861ddceb 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -75,6 +75,11 @@ static const struct drm_mode_config_funcs 
> meson_mode_config_funcs = {
>   .fb_create   = drm_gem_fb_create,
>  };
>  
> +
> +static const struct drm_mode_config_helper_funcs meson_mode_config_helpers = 
> {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
>  static irqreturn_t meson_irq(int irq, void *arg)
>  {
>   struct drm_device *dev = arg;
> @@ -266,6 +271,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>   drm->mode_config.max_width = 3840;
>   drm->mode_config.max_height = 2160;
>   drm->mode_config.funcs = &meson_mode_config_funcs;
> + drm->mode_config.helper_private = &meson_mode_config_helpers;
>  
>   /* Hardware Initialization */
>  
> 

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

[PATCH AUTOSEL 4.9 012/107] drm/vc4: ->x_scaling[1] should never be set to VC4_SCALING_NONE

[Sasha Levin]

From: Boris Brezillon 

[ Upstream commit 0560054da5673b25d56bea6c57c8d069673af73b ]

For the YUV conversion to work properly, ->x_scaling[1] should never
be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
into VC4_SCALING_PPF when that happens.

The old ->x_scaling[0] adjustment is dropped as I couldn't find any
mention to this constraint in the spec and it's proven to be
unnecessary (I tested various multi-planar YUV formats with scaling
disabled, and all of them worked fine without this adjustment).

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezil...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 70051bf0ee5c..0376c0c2fc66 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -345,12 +345,14 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
vc4_get_scaling_mode(vc4_state->src_h[1],
 vc4_state->crtc_h);
 
-   /* YUV conversion requires that horizontal scaling be enabled,
-* even on a plane that's otherwise 1:1. Looks like only PPF
-* works in that case, so let's pick that one.
+   /* YUV conversion requires that horizontal scaling be enabled
+* on the UV plane even if vc4_get_scaling_mode() returned
+* VC4_SCALING_NONE (which can happen when the down-scaling
+* ratio is 0.5). Let's force it to VC4_SCALING_PPF in this
+* case.
 */
-   if (vc4_state->is_unity)
-   vc4_state->x_scaling[0] = VC4_SCALING_PPF;
+   if (vc4_state->x_scaling[1] == VC4_SCALING_NONE)
+   vc4_state->x_scaling[1] = VC4_SCALING_PPF;
} else {
vc4_state->is_yuv = false;
vc4_state->x_scaling[1] = VC4_SCALING_NONE;
-- 
2.19.1

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

Re: [PATCH] drm/amd/powerplay: Fix missing break in switch

[Alex Deucher]

On Fri, Jan 25, 2019 at 5:31 PM Gustavo A. R. Silva
 wrote:
>
> Add missing break statement in order to prevent the code from falling
> through to the default case.
>
> The resoning for this is that pclk_vol_table is an automatic variable.
> So, it makes no sense to update it just before falling through to the
> default case and return -EINVAL.
>
> This bug was found thanks to the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Fixes: cd70f3d6e3fa ("drm/amd/powerplay: PP/DAL interface changes for dynamic 
> clock switch")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index f95c5f50eb0f..5273de3c5b98 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -1033,6 +1033,7 @@ static int smu10_get_clock_by_type_with_latency(struct 
> pp_hwmgr *hwmgr,
> break;
> case amd_pp_dpp_clock:
> pclk_vol_table = pinfo->vdd_dep_on_dppclk;
> +   break;
> default:
> return -EINVAL;
> }
> --
> 2.20.1
>
> ___
> 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 AUTOSEL 4.9 001/107] drm/bufs: Fix Spectre v1 vulnerability

[Sasha Levin]

From: "Gustavo A. R. Silva" 

[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma->buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181016095549.ga23...@embeddedor.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_bufs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index adb1dd7fde5f..9ccd7d702cd3 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
 #include 
 #include "drm_legacy.h"
 
+#include 
+
 static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
  struct drm_local_map *map)
 {
@@ -1413,6 +1415,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
  idx, dma->buf_count - 1);
return -EINVAL;
}
+   idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
-- 
2.19.1

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

[PATCH AUTOSEL 4.9 004/107] gpu: ipu-v3: image-convert: Prevent race between run and unprepare

[Sasha Levin]

From: Steve Longerbeam 

[ Upstream commit 819bec35c8c9706185498c9222bd244e0781ad35 ]

Prevent possible race by parallel threads between ipu_image_convert_run()
and ipu_image_convert_unprepare(). This involves setting ctx->aborting
to true unconditionally so that no new job runs can be queued during
unprepare, and holding the ctx->aborting flag until the context is freed.

Note that the "normal" ipu_image_convert_abort() case (e.g. not during
context unprepare) should clear the ctx->aborting flag after aborting
any active run and clearing the context's pending queue. This is because
it should be possible to continue to use the conversion context and queue
more runs after an abort.

Signed-off-by: Steve Longerbeam 
Tested-by: Philipp Zabel 
Signed-off-by: Philipp Zabel 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/ipu-v3/ipu-image-convert.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index 805b6fa7b5f4..50b73f3876fb 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1513,7 +1513,7 @@ int ipu_image_convert_queue(struct ipu_image_convert_run 
*run)
 EXPORT_SYMBOL_GPL(ipu_image_convert_queue);
 
 /* Abort any active or pending conversions for this context */
-void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+static void __ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
 {
struct ipu_image_convert_chan *chan = ctx->chan;
struct ipu_image_convert_priv *priv = chan->priv;
@@ -1540,7 +1540,7 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx 
*ctx)
 
need_abort = (run_count || active_run);
 
-   ctx->aborting = need_abort;
+   ctx->aborting = true;
 
spin_unlock_irqrestore(&chan->irqlock, flags);
 
@@ -1561,7 +1561,11 @@ void ipu_image_convert_abort(struct 
ipu_image_convert_ctx *ctx)
dev_warn(priv->ipu->dev, "%s: timeout\n", __func__);
force_abort(ctx);
}
+}
 
+void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+{
+   __ipu_image_convert_abort(ctx);
ctx->aborting = false;
 }
 EXPORT_SYMBOL_GPL(ipu_image_convert_abort);
@@ -1575,7 +1579,7 @@ void ipu_image_convert_unprepare(struct 
ipu_image_convert_ctx *ctx)
bool put_res;
 
/* make sure no runs are hanging around */
-   ipu_image_convert_abort(ctx);
+   __ipu_image_convert_abort(ctx);
 
dev_dbg(priv->ipu->dev, "%s: task %u: removing ctx %p\n", __func__,
chan->ic_task, ctx);
-- 
2.19.1

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

Re: [PATCH v2 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel

[Thierry Reding]

On Mon, Jan 14, 2019 at 09:43:31AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev 
> 
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
> 
> Signed-off-by: Eugen Hristev 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 27 +++
>  1 file changed, 27 insertions(+)

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 v2 2/3] dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0

[Thierry Reding]

On Mon, Jan 14, 2019 at 09:43:28AM +, eugen.hris...@microchip.com wrote:
> From: Cristian Birsan 
> 
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
> Adding Device Tree bindings for this panel.
> 
> Signed-off-by: Cristian Birsan 
> [eugen.hris...@microchip.com]: specified backlight and supply bindings
> Signed-off-by: Eugen Hristev 
> ---
> Changes in v2:
> - added binding explanations for required properties from simple-panel:
> backlight and power supply which are mandatory
> 
>  .../devicetree/bindings/display/panel/pda,91-00156-a0.txt  | 14 
> ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt

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 v2 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.

[Thierry Reding]

On Mon, Jan 14, 2019 at 09:43:26AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev 
> 
> Precision Design Associates, Inc. (PDA) manufactures standard and custom
> capacitive touch screens, LCD's embedded controllers and custom embedded
> software. They specialize in industrial, rugged and outdoor applications.
> Website: http://www.pdaatl.com/
> 
> Signed-off-by: Eugen Hristev 
> Reviewed-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

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

[PATCH AUTOSEL 4.14 129/170] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 11d73b5fc885..302cce7185e3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -435,7 +435,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -447,7 +449,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 133/170] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..85787119bfbf 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3041,7 +3041,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 127/170] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index ff561073ee4e..42f909618f04 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 054/170] drm: Clear state->acquire_ctx before leaving drm_atomic_helper_commit_duplicated_state()

[Sasha Levin]

From: Sean Paul 

[ Upstream commit aa394b0dd68cb00c483e151dcd84713d4d517ed1 ]

drm_atomic_helper_commit_duplicated_state() sets state->acquire_ctx to
the context given in the argument and leaves it in state after it
quits. The lifetime of state and context are not guaranteed to be the
same, so we shouldn't leave that pointer hanging around. This patch
resets the context to NULL to avoid any oopses.

Changes in v2:
- Added to the set

Suggested-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-1-s...@poorly.run
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 1f08d597b87a..d05ed0521e20 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2899,7 +2899,7 @@ EXPORT_SYMBOL(drm_atomic_helper_suspend);
 int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
  struct drm_modeset_acquire_ctx 
*ctx)
 {
-   int i;
+   int i, ret;
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
struct drm_connector *connector;
@@ -2918,7 +2918,11 @@ int drm_atomic_helper_commit_duplicated_state(struct 
drm_atomic_state *state,
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
 
-   return drm_atomic_commit(state);
+   ret = drm_atomic_commit(state);
+
+   state->acquire_ctx = NULL;
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 030/170] drm/rockchip: fix for mailbox read size

[Sasha Levin]

From: Damian Kos 

[ Upstream commit fa68d4f8476bea4cdf441062b614b41bb85ef1da ]

Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block)
allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is
used by them, can read only up to 255 bytes at once. Normally, it's
not a big issue as DPCD or EDID reads won't (hopefully) exceed that
value.
The real issue here is the revocation list read during the HDCP
authentication process. (problematic use case:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152)
The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv +
4 bytes of an additional info).
In other words - CTSes with HDCP Repeater won't pass without this
fix. Oh, and the driver will most likely stop working (best case
scenario).

Signed-off-by: Damian Kos 
Signed-off-by: Heiko Stuebner 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-d...@cadence.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index b14d211f6c21..0ed7e91471f6 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -147,7 +147,7 @@ static int cdn_dp_mailbox_validate_receive(struct 
cdn_dp_device *dp,
 }
 
 static int cdn_dp_mailbox_read_receive(struct cdn_dp_device *dp,
-  u8 *buff, u8 buff_size)
+  u8 *buff, u16 buff_size)
 {
u32 i;
int ret;
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 019/170] drm/vc4: ->x_scaling[1] should never be set to VC4_SCALING_NONE

[Sasha Levin]

From: Boris Brezillon 

[ Upstream commit 0560054da5673b25d56bea6c57c8d069673af73b ]

For the YUV conversion to work properly, ->x_scaling[1] should never
be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
into VC4_SCALING_PPF when that happens.

The old ->x_scaling[0] adjustment is dropped as I couldn't find any
mention to this constraint in the spec and it's proven to be
unnecessary (I tested various multi-planar YUV formats with scaling
disabled, and all of them worked fine without this adjustment).

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezil...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 5bd3c2ef0067..6277a3f2d5d1 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -347,12 +347,14 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
vc4_get_scaling_mode(vc4_state->src_h[1],
 vc4_state->crtc_h);
 
-   /* YUV conversion requires that horizontal scaling be enabled,
-* even on a plane that's otherwise 1:1. Looks like only PPF
-* works in that case, so let's pick that one.
+   /* YUV conversion requires that horizontal scaling be enabled
+* on the UV plane even if vc4_get_scaling_mode() returned
+* VC4_SCALING_NONE (which can happen when the down-scaling
+* ratio is 0.5). Let's force it to VC4_SCALING_PPF in this
+* case.
 */
-   if (vc4_state->is_unity)
-   vc4_state->x_scaling[0] = VC4_SCALING_PPF;
+   if (vc4_state->x_scaling[1] == VC4_SCALING_NONE)
+   vc4_state->x_scaling[1] = VC4_SCALING_PPF;
} else {
vc4_state->is_yuv = false;
vc4_state->x_scaling[1] = VC4_SCALING_NONE;
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 003/170] drm/vgem: Fix vgem_init to get drm device available.

[Sasha Levin]

From: Deepak Sharma 

[ Upstream commit d5c04dff24870ef07ce6453a3f4e1ffd9cf88d27 ]

Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.

v2: rebase, address checkpatch typo and line over 80 characters

Cc: Daniel Vetter 
Signed-off-by: Deepak Sharma 
Reviewed-by: Sean Paul 
Signed-off-by: Emil Velikov 
Reviewed-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-1-emil.l.veli...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2524ff116f00..81c7ab10c083 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -472,31 +472,31 @@ static int __init vgem_init(void)
if (!vgem_device)
return -ENOMEM;
 
-   ret = drm_dev_init(&vgem_device->drm, &vgem_driver, NULL);
-   if (ret)
-   goto out_free;
-
vgem_device->platform =
platform_device_register_simple("vgem", -1, NULL, 0);
if (IS_ERR(vgem_device->platform)) {
ret = PTR_ERR(vgem_device->platform);
-   goto out_fini;
+   goto out_free;
}
 
dma_coerce_mask_and_coherent(&vgem_device->platform->dev,
 DMA_BIT_MASK(64));
+   ret = drm_dev_init(&vgem_device->drm, &vgem_driver,
+  &vgem_device->platform->dev);
+   if (ret)
+   goto out_unregister;
 
/* Final step: expose the device/driver to userspace */
ret  = drm_dev_register(&vgem_device->drm, 0);
if (ret)
-   goto out_unregister;
+   goto out_fini;
 
return 0;
 
-out_unregister:
-   platform_device_unregister(vgem_device->platform);
 out_fini:
drm_dev_fini(&vgem_device->drm);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
 out_free:
kfree(vgem_device);
return ret;
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 006/170] gpu: ipu-v3: image-convert: Prevent race between run and unprepare

[Sasha Levin]

From: Steve Longerbeam 

[ Upstream commit 819bec35c8c9706185498c9222bd244e0781ad35 ]

Prevent possible race by parallel threads between ipu_image_convert_run()
and ipu_image_convert_unprepare(). This involves setting ctx->aborting
to true unconditionally so that no new job runs can be queued during
unprepare, and holding the ctx->aborting flag until the context is freed.

Note that the "normal" ipu_image_convert_abort() case (e.g. not during
context unprepare) should clear the ctx->aborting flag after aborting
any active run and clearing the context's pending queue. This is because
it should be possible to continue to use the conversion context and queue
more runs after an abort.

Signed-off-by: Steve Longerbeam 
Tested-by: Philipp Zabel 
Signed-off-by: Philipp Zabel 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/ipu-v3/ipu-image-convert.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index 524a717ab28e..a5e33d58e02f 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1518,7 +1518,7 @@ int ipu_image_convert_queue(struct ipu_image_convert_run 
*run)
 EXPORT_SYMBOL_GPL(ipu_image_convert_queue);
 
 /* Abort any active or pending conversions for this context */
-void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+static void __ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
 {
struct ipu_image_convert_chan *chan = ctx->chan;
struct ipu_image_convert_priv *priv = chan->priv;
@@ -1545,7 +1545,7 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx 
*ctx)
 
need_abort = (run_count || active_run);
 
-   ctx->aborting = need_abort;
+   ctx->aborting = true;
 
spin_unlock_irqrestore(&chan->irqlock, flags);
 
@@ -1566,7 +1566,11 @@ void ipu_image_convert_abort(struct 
ipu_image_convert_ctx *ctx)
dev_warn(priv->ipu->dev, "%s: timeout\n", __func__);
force_abort(ctx);
}
+}
 
+void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+{
+   __ipu_image_convert_abort(ctx);
ctx->aborting = false;
 }
 EXPORT_SYMBOL_GPL(ipu_image_convert_abort);
@@ -1580,7 +1584,7 @@ void ipu_image_convert_unprepare(struct 
ipu_image_convert_ctx *ctx)
bool put_res;
 
/* make sure no runs are hanging around */
-   ipu_image_convert_abort(ctx);
+   __ipu_image_convert_abort(ctx);
 
dev_dbg(priv->ipu->dev, "%s: task %u: removing ctx %p\n", __func__,
chan->ic_task, ctx);
-- 
2.19.1

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

[PATCH AUTOSEL 4.14 001/170] drm/bufs: Fix Spectre v1 vulnerability

[Sasha Levin]

From: "Gustavo A. R. Silva" 

[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma->buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181016095549.ga23...@embeddedor.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_bufs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 1ee84dd802d4..0f05b8d8fefa 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
 #include 
 #include "drm_legacy.h"
 
+#include 
+
 static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
  struct drm_local_map *map)
 {
@@ -1417,6 +1419,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
  idx, dma->buf_count - 1);
return -EINVAL;
}
+   idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 211/258] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 75ebbbf0a1fb..5d961e3ac66e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3066,7 +3066,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 206/258] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 20405421a5ed..77cee99fc36c 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -435,7 +435,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -447,7 +449,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 204/258] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index ff561073ee4e..42f909618f04 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 203/258] drm/amd/display: validate extended dongle caps

[Sasha Levin]

From: Wenjing Liu 

[ Upstream commit 99b922f9ed6a6313c0d2247cde8aa1e4a0bd67e4 ]

[why]
Some dongle doesn't have a valid extended dongle caps,
but we still set the extended dongle caps to be valid.
This causes validation fails for all timing.

[how]
If no dp_hdmi_max_pixel_clk is provided,
don't use extended dongle caps.

Signed-off-by: Wenjing Liu 
Reviewed-by: Aric Cyr 
Reviewed-by: Jun Lei 
Acked-by: Abdoulaye Berthe 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index a7553b6d59c2..05840f5bddd5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2240,7 +2240,8 @@ static void get_active_converter_info(
translate_dpcd_max_bpc(

hdmi_color_caps.bits.MAX_BITS_PER_COLOR_COMPONENT);
 
-   link->dpcd_caps.dongle_caps.extendedCapValid = 
true;
+   if 
(link->dpcd_caps.dongle_caps.dp_hdmi_max_pixel_clk != 0)
+   
link->dpcd_caps.dongle_caps.extendedCapValid = true;
}
 
break;
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 185/258] drm/amd/display: fix YCbCr420 blank color

[Sasha Levin]

From: Eric Yang 

[ Upstream commit 12750d1647f118496f1da727146f255f5e44d500 ]

[Why]
YCbCr420 packing format uses two chanels for luma, and 1
channel for both chroma component. Our previous implementation
did not account for this and results in every other pixel having
very high luma value, showing greyish color instead of black.

YCbCr444 = ;  .
YCbCr420 = ;  .

[How]
Program the second channel with the black color value for luma
as well.

Signed-off-by: Eric Yang 
Reviewed-by: Hugo Hu 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../drm/amd/display/dc/dce110/dce110_hw_sequencer.c   | 11 ++-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |  9 +
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index 0941f3c689bc..580e7e82034f 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -1268,10 +1268,19 @@ static void program_scaler(const struct dc *dc,
pipe_ctx->plane_res.scl_data.lb_params.depth,
&pipe_ctx->stream->bit_depth_params);
 
-   if (pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color)
+   if (pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color) {
+   /*
+* The way 420 is packed, 2 channels carry Y component, 1 
channel
+* alternate between Cb and Cr, so both channels need the pixel
+* value for Y
+*/
+   if (pipe_ctx->stream->timing.pixel_encoding == 
PIXEL_ENCODING_YCBCR420)
+   color.color_r_cr = color.color_g_y;
+
pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color(
pipe_ctx->stream_res.tg,
&color);
+   }
 

pipe_ctx->plane_res.xfm->funcs->transform_set_scaler(pipe_ctx->plane_res.xfm,
&pipe_ctx->plane_res.scl_data);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 33a9d0c58966..4058b59d9bea 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -2121,6 +2121,15 @@ static void dcn10_blank_pixel_data(
color_space = stream->output_color_space;
color_space_to_black_color(dc, color_space, &black_color);
 
+   /*
+* The way 420 is packed, 2 channels carry Y component, 1 channel
+* alternate between Cb and Cr, so both channels need the pixel
+* value for Y
+*/
+   if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR420)
+   black_color.color_r_cr = black_color.color_g_y;
+
+
if (stream_res->tg->funcs->set_blank_color)
stream_res->tg->funcs->set_blank_color(
stream_res->tg,
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 183/258] drm/amd/display: Add retry to read ddc_clock pin

[Sasha Levin]

From: Paul Hsieh 

[ Upstream commit bd4905a9583c760da31ded7256dca6f71483c3dc ]

[WHY]
On customer board, there is one pluse (1v , < 1ms) on
DDC_CLK pin when plug / unplug DP cable. Driver will read
it and config DP to HDMI/DVI dongle.

[HOW]
If there is a real dongle, DDC_CLK should be always pull high.
Try to read again to recovery this special case. Retry times = 3.
Need additional 3ms to detect DP passive dongle(3 failures)

Signed-off-by: Paul Hsieh 
Reviewed-by: Eric Yang 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 23 ++-
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 7c89785fd731..23a7ef97afdd 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -324,7 +324,7 @@ bool dc_link_is_dp_sink_present(struct dc_link *link)
 {
enum gpio_result gpio_result;
uint32_t clock_pin = 0;
-
+   uint8_t retry = 0;
struct ddc *ddc;
 
enum connector_id connector_id =
@@ -353,11 +353,22 @@ bool dc_link_is_dp_sink_present(struct dc_link *link)
return present;
}
 
-   /* Read GPIO: DP sink is present if both clock and data pins are zero */
-   /* [anaumov] in DAL2, there was no check for GPIO failure */
-
-   gpio_result = dal_gpio_get_value(ddc->pin_clock, &clock_pin);
-   ASSERT(gpio_result == GPIO_RESULT_OK);
+   /*
+* Read GPIO: DP sink is present if both clock and data pins are zero
+*
+* [W/A] plug-unplug DP cable, sometimes customer board has
+* one short pulse on clk_pin(1V, < 1ms). DP will be config to HDMI/DVI
+* then monitor can't br light up. Add retry 3 times
+* But in real passive dongle, it need additional 3ms to detect
+*/
+   do {
+   gpio_result = dal_gpio_get_value(ddc->pin_clock, &clock_pin);
+   ASSERT(gpio_result == GPIO_RESULT_OK);
+   if (clock_pin)
+   udelay(1000);
+   else
+   break;
+   } while (retry++ < 3);
 
present = (gpio_result == GPIO_RESULT_OK) && !clock_pin;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 138/258] drm/msm: dpu: Only check flush register against pending flushes

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 5f79e03b1f7c1b2cf0019ce6365fe5d52629813d ]

There exists a case where a flush of a plane/dma may have been triggered
& started from an async commit. If that plane/dma is subsequently disabled
by the next commit, the flush register will continue to hold the flush
bit for the disabled plane. Since the bit remains active,
pending_kickoff_cnt will never decrement and we'll miss frame_done
events.

This patch limits the check of flush_register to include only those bits
which have been updated with the latest commit.

Changes in v2:
- None

Reviewed-by: Jeykumar Sankaran 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 14fc7c2a6bb7..c9962a36b86b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -331,7 +331,7 @@ static void dpu_encoder_phys_vid_vblank_irq(void *arg, int 
irq_idx)
if (hw_ctl && hw_ctl->ops.get_flush_register)
flush_register = hw_ctl->ops.get_flush_register(hw_ctl);
 
-   if (flush_register == 0)
+   if (!(flush_register & hw_ctl->ops.get_pending_flush(hw_ctl)))
new_cnt = atomic_add_unless(&phys_enc->pending_kickoff_cnt,
-1, 0);
spin_unlock_irqrestore(phys_enc->enc_spinlock, lock_flags);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 137/258] drm/msm/dsi: fix dsi clock names in DSI 10nm PLL driver

[Sasha Levin]

From: Abhinav Kumar 

[ Upstream commit c1866d44d149a1ea5c303632114fb6aa08cfd263 ]

Fix the dsi clock names in the DSI 10nm PLL driver to
match the names in the dispcc driver as those are
according to the clock plan of the chipset.

Changes in v2:
- Update the clock diagram with the new clock name

Reviewed-by: Sean Paul 
Signed-off-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 41bec570c518..31205625c734 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -17,7 +17,7 @@
  *  ||
  *  ||
  * +-+  |  +--+  |  ++
- *  dsi0vco_clk ---| out_div |--o--| divl_3_0 |--o--| /8 |-- dsi0pllbyte
+ *  dsi0vco_clk ---| out_div |--o--| divl_3_0 |--o--| /8 |-- 
dsi0_phy_pll_out_byteclk
  * +-+  |  +--+  |  ++
  *  ||
  *  || 
dsi0_pll_by_2_bit_clk
@@ -25,7 +25,7 @@
  *  ||  ++  |  |\  
dsi0_pclk_mux
  *  ||--| /2 |--o--| \   |
  *  ||  ++ |  \  |  
+-+
- *  |--|  |--o--| 
div_7_4 |-- dsi0pll
+ *  |--|  |--o--| 
div_7_4 |-- dsi0_phy_pll_out_dsiclk
  *  |--|  / 
+-+
  *  |  +-+ | /
  *  ---| /4? |--o--|/
@@ -690,7 +690,7 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm)
 
hws[num++] = hw;
 
-   snprintf(clk_name, 32, "dsi%dpllbyte", pll_10nm->id);
+   snprintf(clk_name, 32, "dsi%d_phy_pll_out_byteclk", pll_10nm->id);
snprintf(parent, 32, "dsi%d_pll_bit_clk", pll_10nm->id);
 
/* DSI Byte clock = VCO_CLK / OUT_DIV / BIT_DIV / 8 */
@@ -739,7 +739,7 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm)
 
hws[num++] = hw;
 
-   snprintf(clk_name, 32, "dsi%dpll", pll_10nm->id);
+   snprintf(clk_name, 32, "dsi%d_phy_pll_out_dsiclk", pll_10nm->id);
snprintf(parent, 32, "dsi%d_pclk_mux", pll_10nm->id);
 
/* PIX CLK DIV : DIV_CTRL_7_4*/
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 109/258] drm/amdgpu/powerplay: fix clock stretcher limits on polaris (v2)

[Sasha Levin]

From: Alex Deucher 

[ Upstream commit de4aaab5cc9770a8c4dc13d9bfb6a83b06bba57e ]

Adjust limits for newer polaris variants.

v2: fix polaris11 kicker (Jerry)

Reviewed-by: Junwei Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
index 5b67f575cd34..45629f26dbc2 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
@@ -1528,8 +1528,21 @@ static int 
polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
efuse = efuse >> 24;
 
if (hwmgr->chip_id == CHIP_POLARIS10) {
-   min = 1000;
-   max = 2300;
+   if (hwmgr->is_kicker) {
+   min = 1200;
+   max = 2500;
+   } else {
+   min = 1000;
+   max = 2300;
+   }
+   } else if (hwmgr->chip_id == CHIP_POLARIS11) {
+   if (hwmgr->is_kicker) {
+   min = 900;
+   max = 2100;
+   } else {
+   min = 1100;
+   max = 2100;
+   }
} else {
min = 1100;
max = 2100;
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 092/258] drm/v3d: Fix prime imports of buffers from other drivers.

[Sasha Levin]

From: Eric Anholt 

[ Upstream commit 62d1a752874962f072de8a779e960fcd2ab4847b ]

v3d_bo_get_pages() checks this to decide to map the imported buffer
instead of the backing shmem file.  The caller was about to set this
value anyway, and there's no error path in between.  Ideally we
wouldn't even allocate the shmem file for our imports, but that's a
more invasive fix.

Signed-off-by: Eric Anholt 
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D 
V3.x+")
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181128230927.10951-3-e...@anholt.net
Acked-by: Daniel Vetter 
Reviewed-by: Dave Emett 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/v3d/v3d_bo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 54d96518a131..a08766d39eab 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -293,6 +293,7 @@ v3d_prime_import_sg_table(struct drm_device *dev,
bo->resv = attach->dmabuf->resv;
 
bo->sgt = sgt;
+   obj->import_attach = attach;
v3d_bo_get_pages(bo);
 
v3d_mmu_insert_ptes(bo);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 082/258] drm: Clear state->acquire_ctx before leaving drm_atomic_helper_commit_duplicated_state()

[Sasha Levin]

From: Sean Paul 

[ Upstream commit aa394b0dd68cb00c483e151dcd84713d4d517ed1 ]

drm_atomic_helper_commit_duplicated_state() sets state->acquire_ctx to
the context given in the argument and leaves it in state after it
quits. The lifetime of state and context are not guaranteed to be the
same, so we shouldn't leave that pointer hanging around. This patch
resets the context to NULL to avoid any oopses.

Changes in v2:
- Added to the set

Suggested-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-1-s...@poorly.run
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f77bff5aa307..23397c08be11 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3192,7 +3192,7 @@ EXPORT_SYMBOL(drm_atomic_helper_suspend);
 int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
  struct drm_modeset_acquire_ctx 
*ctx)
 {
-   int i;
+   int i, ret;
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
struct drm_connector *connector;
@@ -3211,7 +3211,11 @@ int drm_atomic_helper_commit_duplicated_state(struct 
drm_atomic_state *state,
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
 
-   return drm_atomic_commit(state);
+   ret = drm_atomic_commit(state);
+
+   state->acquire_ctx = NULL;
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 083/258] drm: Move drm_mode_setcrtc() local re-init to failure path

[Sasha Levin]

From: Sean Paul 

[ Upstream commit c232e9f41b136c141df9938024e521191a7b910d ]

Instead of always re-initializing the variables we need to clean up on
out, move the re-initialization into the branch that goes back to retry
label.

This is a lateral move right now, but will allow us to pull out the
modeset locking into common code. I kept this change separate to make
things easier to review.

Changes in v2:
- None

Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-2-s...@poorly.run
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_crtc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9cbe8f5c9aca..ed9d7fc4cb2c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -567,9 +567,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_mode_crtc *crtc_req = data;
struct drm_crtc *crtc;
struct drm_plane *plane;
-   struct drm_connector **connector_set, *connector;
-   struct drm_framebuffer *fb;
-   struct drm_display_mode *mode;
+   struct drm_connector **connector_set = NULL, *connector;
+   struct drm_framebuffer *fb = NULL;
+   struct drm_display_mode *mode = NULL;
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
struct drm_modeset_acquire_ctx ctx;
@@ -598,10 +598,6 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
mutex_lock(&crtc->dev->mode_config.mutex);
drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
-   connector_set = NULL;
-   fb = NULL;
-   mode = NULL;
-
ret = drm_modeset_lock_all_ctx(crtc->dev, &ctx);
if (ret)
goto out;
@@ -763,6 +759,12 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
kfree(connector_set);
drm_mode_destroy(dev, mode);
+
+   /* In case we need to retry... */
+   connector_set = NULL;
+   fb = NULL;
+   mode = NULL;
+
if (ret == -EDEADLK) {
ret = drm_modeset_backoff(&ctx);
if (!ret)
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 049/258] drm/amd/display: calculate stream->phy_pix_clk before clock mapping

[Sasha Levin]

From: Yogesh Mohan Marimuthu 

[ Upstream commit 08e1c28dd521c7b08d1b0af0bae9fb22ccc012a4 ]

[why]
phy_pix_clk is one of the variable used to check if one PLL can be shared
with displays having common mode set configuration. As of now
phy_pix_clock varialbe is calculated in function dc_validate_stream().
dc_validate_stream() function is called after clocks are assigned for the
new display. Due to this during hotplug, when PLL sharing conditions are
checked for new display phy_pix_clk variable will be 0 and for displays
that are already enabled phy_pix_clk will have some value. Hence PLL will
not be shared and if the display hardware doesn't have any more PLL to
assign, mode set will fail due to resource unavailability.

[how]
Instead of only calculating the phy_pix_clk variable after the PLL is
assigned for new display, this patch calculates phy_pix_clk also during
the before assigning the PLL for new display.

Signed-off-by: Yogesh Mohan Marimuthu 
Reviewed-by: Harry Wentland 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index ea6beccfd89d..87bf422f16be 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1917,6 +1917,8 @@ enum dc_status resource_map_pool_resources(
}
*/
 
+   calculate_phy_pix_clks(stream);
+
/* acquire new resources */
pipe_idx = acquire_first_free_pipe(&context->res_ctx, pool, stream);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 048/258] drm/amd/display: fix gamma not being applied correctly

[Sasha Levin]

From: Murton Liu 

[ Upstream commit 8ce504b9389be846bcdf512ed5be8f661b3bf097 ]

[why]
Gamma was always being set as identity on SDR monitor,
leading to no changes in gamma. This caused nightlight to
not apply correctly.

[how]
Added a default gamma structure to compare against
in the sdr case.

Signed-off-by: Murton Liu 
Reviewed-by: Krunoslav Kovac 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index cfcc54f2ce65..33a9d0c58966 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1190,7 +1190,8 @@ static bool dcn10_set_input_transfer_func(struct pipe_ctx 
*pipe_ctx,
tf = plane_state->in_transfer_func;
 
if (plane_state->gamma_correction &&
-   !plane_state->gamma_correction->is_identity
+   !dpp_base->ctx->dc->debug.always_use_regamma
+   && !plane_state->gamma_correction->is_identity
&& dce_use_lut(plane_state->format))
dpp_base->funcs->dpp_program_input_lut(dpp_base, 
plane_state->gamma_correction);
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 046/258] drm/rockchip: fix for mailbox read size

[Sasha Levin]

From: Damian Kos 

[ Upstream commit fa68d4f8476bea4cdf441062b614b41bb85ef1da ]

Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block)
allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is
used by them, can read only up to 255 bytes at once. Normally, it's
not a big issue as DPCD or EDID reads won't (hopefully) exceed that
value.
The real issue here is the revocation list read during the HDCP
authentication process. (problematic use case:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152)
The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv +
4 bytes of an additional info).
In other words - CTSes with HDCP Repeater won't pass without this
fix. Oh, and the driver will most likely stop working (best case
scenario).

Signed-off-by: Damian Kos 
Signed-off-by: Heiko Stuebner 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-d...@cadence.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 3105965fc260..5a485489a1e2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -147,7 +147,7 @@ static int cdn_dp_mailbox_validate_receive(struct 
cdn_dp_device *dp,
 }
 
 static int cdn_dp_mailbox_read_receive(struct cdn_dp_device *dp,
-  u8 *buff, u8 buff_size)
+  u8 *buff, u16 buff_size)
 {
u32 i;
int ret;
-- 
2.19.1

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

Re: [PATCH v3 6/8] drm/panel: simple: Add support for the LeMaker BL035-RGB-002 3.5" LCD

[Thierry Reding]

On Wed, Nov 07, 2018 at 07:18:41PM +0100, Paul Kocialkowski wrote:
> This adds support for the 3.5" LCD panel from LeMaker, sold for use with
> BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
> requires an active-low DE signal
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 27 +++
>  1 file changed, 27 insertions(+)

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 v3 5/8] dt-bindings: Add bindings for the LeMaker BL035-RGB-002 LCD panel

[Thierry Reding]

On Wed, Nov 07, 2018 at 07:18:40PM +0100, Paul Kocialkowski wrote:
> This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5"
> QVGA TFT LCD panel, compatible with simple-panel.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../bindings/display/panel/lemaker,bl035-rgb-002.txt | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt

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

[PATCH AUTOSEL 4.19 027/258] drm/vc4: ->x_scaling[1] should never be set to VC4_SCALING_NONE

[Sasha Levin]

From: Boris Brezillon 

[ Upstream commit 0560054da5673b25d56bea6c57c8d069673af73b ]

For the YUV conversion to work properly, ->x_scaling[1] should never
be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
into VC4_SCALING_PPF when that happens.

The old ->x_scaling[0] adjustment is dropped as I couldn't find any
mention to this constraint in the spec and it's proven to be
unnecessary (I tested various multi-planar YUV formats with scaling
disabled, and all of them worked fine without this adjustment).

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezil...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 629f40424bba..ab39315c9078 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -315,12 +315,14 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
vc4_get_scaling_mode(vc4_state->src_h[1],
 vc4_state->crtc_h);
 
-   /* YUV conversion requires that horizontal scaling be enabled,
-* even on a plane that's otherwise 1:1. Looks like only PPF
-* works in that case, so let's pick that one.
+   /* YUV conversion requires that horizontal scaling be enabled
+* on the UV plane even if vc4_get_scaling_mode() returned
+* VC4_SCALING_NONE (which can happen when the down-scaling
+* ratio is 0.5). Let's force it to VC4_SCALING_PPF in this
+* case.
 */
-   if (vc4_state->is_unity)
-   vc4_state->x_scaling[0] = VC4_SCALING_PPF;
+   if (vc4_state->x_scaling[1] == VC4_SCALING_NONE)
+   vc4_state->x_scaling[1] = VC4_SCALING_PPF;
} else {
vc4_state->is_yuv = false;
vc4_state->x_scaling[1] = VC4_SCALING_NONE;
-- 
2.19.1

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

Re: [PATCH v3 4/8] dt-bindings: Add vendor prefix for LeMaker

[Thierry Reding]

On Wed, Nov 07, 2018 at 07:18:39PM +0100, Paul Kocialkowski wrote:
> This introduces a new device-tree binding vendor prefix for Shenzhen
> LeMaker Technology Co., Ltd.
> 
> This vendor was already in use but it was not documented until now.
> 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Rob Hering 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

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

[PATCH AUTOSEL 4.19 007/258] drm/sun4i: Initialize registers in tcon-top driver

[Sasha Levin]

From: Jernej Skrabec 

[ Upstream commit c96d62215fb540e2ae61de44cb7caf4db50958e3 ]

It turns out that TCON TOP registers in H6 SoC have non-zero reset
value. This may cause issues if bits are not changed during
configuration.

To prevent that, initialize registers to 0.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181104182705.18047-24-jernej.skra...@siol.net
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c 
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index d5240b777a8f..adcdf946c365 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -168,6 +168,13 @@ static int sun8i_tcon_top_bind(struct device *dev, struct 
device *master,
goto err_assert_reset;
}
 
+   /*
+* At least on H6, some registers have some bits set by default
+* which may cause issues. Clear them here.
+*/
+   writel(0, regs + TCON_TOP_PORT_SEL_REG);
+   writel(0, regs + TCON_TOP_GATE_SRC_REG);
+
/*
 * TCON TOP has two muxes, which select parent clock for each TCON TV
 * channel clock. Parent could be either TCON TV or TVE clock. For now
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 009/258] gpu: ipu-v3: image-convert: Prevent race between run and unprepare

[Sasha Levin]

From: Steve Longerbeam 

[ Upstream commit 819bec35c8c9706185498c9222bd244e0781ad35 ]

Prevent possible race by parallel threads between ipu_image_convert_run()
and ipu_image_convert_unprepare(). This involves setting ctx->aborting
to true unconditionally so that no new job runs can be queued during
unprepare, and holding the ctx->aborting flag until the context is freed.

Note that the "normal" ipu_image_convert_abort() case (e.g. not during
context unprepare) should clear the ctx->aborting flag after aborting
any active run and clearing the context's pending queue. This is because
it should be possible to continue to use the conversion context and queue
more runs after an abort.

Signed-off-by: Steve Longerbeam 
Tested-by: Philipp Zabel 
Signed-off-by: Philipp Zabel 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/ipu-v3/ipu-image-convert.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index f4081962784c..91653adc41cc 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1524,7 +1524,7 @@ int ipu_image_convert_queue(struct ipu_image_convert_run 
*run)
 EXPORT_SYMBOL_GPL(ipu_image_convert_queue);
 
 /* Abort any active or pending conversions for this context */
-void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+static void __ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
 {
struct ipu_image_convert_chan *chan = ctx->chan;
struct ipu_image_convert_priv *priv = chan->priv;
@@ -1551,7 +1551,7 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx 
*ctx)
 
need_abort = (run_count || active_run);
 
-   ctx->aborting = need_abort;
+   ctx->aborting = true;
 
spin_unlock_irqrestore(&chan->irqlock, flags);
 
@@ -1572,7 +1572,11 @@ void ipu_image_convert_abort(struct 
ipu_image_convert_ctx *ctx)
dev_warn(priv->ipu->dev, "%s: timeout\n", __func__);
force_abort(ctx);
}
+}
 
+void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx)
+{
+   __ipu_image_convert_abort(ctx);
ctx->aborting = false;
 }
 EXPORT_SYMBOL_GPL(ipu_image_convert_abort);
@@ -1586,7 +1590,7 @@ void ipu_image_convert_unprepare(struct 
ipu_image_convert_ctx *ctx)
bool put_res;
 
/* make sure no runs are hanging around */
-   ipu_image_convert_abort(ctx);
+   __ipu_image_convert_abort(ctx);
 
dev_dbg(priv->ipu->dev, "%s: task %u: removing ctx %p\n", __func__,
chan->ic_task, ctx);
-- 
2.19.1

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

[PATCH AUTOSEL 4.19 003/258] drm/vgem: Fix vgem_init to get drm device available.

[Sasha Levin]

From: Deepak Sharma 

[ Upstream commit d5c04dff24870ef07ce6453a3f4e1ffd9cf88d27 ]

Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.

v2: rebase, address checkpatch typo and line over 80 characters

Cc: Daniel Vetter 
Signed-off-by: Deepak Sharma 
Reviewed-by: Sean Paul 
Signed-off-by: Emil Velikov 
Reviewed-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-1-emil.l.veli...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 0e5620f76ee0..6887db878b38 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -471,31 +471,31 @@ static int __init vgem_init(void)
if (!vgem_device)
return -ENOMEM;
 
-   ret = drm_dev_init(&vgem_device->drm, &vgem_driver, NULL);
-   if (ret)
-   goto out_free;
-
vgem_device->platform =
platform_device_register_simple("vgem", -1, NULL, 0);
if (IS_ERR(vgem_device->platform)) {
ret = PTR_ERR(vgem_device->platform);
-   goto out_fini;
+   goto out_free;
}
 
dma_coerce_mask_and_coherent(&vgem_device->platform->dev,
 DMA_BIT_MASK(64));
+   ret = drm_dev_init(&vgem_device->drm, &vgem_driver,
+  &vgem_device->platform->dev);
+   if (ret)
+   goto out_unregister;
 
/* Final step: expose the device/driver to userspace */
ret  = drm_dev_register(&vgem_device->drm, 0);
if (ret)
-   goto out_unregister;
+   goto out_fini;
 
return 0;
 
-out_unregister:
-   platform_device_unregister(vgem_device->platform);
 out_fini:
drm_dev_fini(&vgem_device->drm);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
 out_free:
kfree(vgem_device);
return ret;
-- 
2.19.1

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

Re: [PATCH v4 RESEND] drm/panel: add Kingdisplay kd097d04 panel driver

[Thierry Reding]

On Thu, Jan 24, 2019 at 12:51:36PM -0500, Sean Paul wrote:
> On Thu, Jan 24, 2019 at 05:18:12PM +0100, Thierry Reding wrote:
> > On Thu, Jan 24, 2019 at 12:01:55PM -0300, Ezequiel Garcia wrote:
> > > On Tue, 2018-10-30 at 10:15 +0100, Heiko Stuebner wrote:
> > > > From: Nickey Yang 
> > > > 
> > > > Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> > > > it is a MIPI dual-DSI panel.
> > > > 
> > > > v4-resend:
> > > > - Thierry noted missing dt-bindings for v4 but forgot that he
> > > >   already had applied them one kernel release back in
> > > >   
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df
> > > > v4:
> > > > - address Philipp's comments
> > > >   - real range for usleep_range and
> > > >   - poweroff ordering in kingdisplay_panel_prepare
> > > >   - return value beautification in panel_probe
> > > > - update author naming for full name
> > > > v3:
> > > > - address Thierry's comments
> > > >   - error handling for init dsi writes in init
> > > >   - unconditionally remove the panel
> > > >   - don't use drm_panel_detach
> > > >   - a bit of variable signednes wiggling
> > > > - I did talk to ChromeOS people and the delays really should be as short
> > > >   as possible, so dropped the 100ms from the delay comments
> > > > v2:
> > > > - update timing + cmds from chromeos kernel
> > > > - new backlight API including switch to devm_of_find_backlight
> > > > - fix most of Sean Paul's comments
> > > >   enable/prepare tracking seems something all panels do
> > > > - document origins of the init sequence
> > > > - lanes per dsi interface to 4 (two interfaces). Matches how tegra
> > > >   and pending rockchip dual-dsi handle (dual-)dsi lanes
> > > > - spdx header instead of license boilerplate
> > > > 
> > > > Signed-off-by: Nickey Yang 
> > > > Signed-off-by: Heiko Stuebner 
> > > 
> > > Hm, this v4 patch has been stalling here for *four full months*.
> > > 
> > > Which deity do we need to pray to get this one moving? ;-)
> > > 
> > > Seriously, can someone please apply this?
> > 
> > If you care about this driver, perhaps you'd like to review and provide
> > a Reviewed-by?
> 
> Looks good to me,
> 
> Reviewed-by: Sean Paul 

I was aiming for a Reviewed-by from Ezequiel, but I'll take yours as
well, thanks very much.

Thierry


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

[PATCH AUTOSEL 4.19 001/258] drm/bufs: Fix Spectre v1 vulnerability

[Sasha Levin]

From: "Gustavo A. R. Silva" 

[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma->buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181016095549.ga23...@embeddedor.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_bufs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ba8cfe65c65b..e2f775d1c112 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -36,6 +36,8 @@
 #include 
 #include "drm_legacy.h"
 
+#include 
+
 static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
  struct drm_local_map *map)
 {
@@ -1417,6 +1419,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
  idx, dma->buf_count - 1);
return -EINVAL;
}
+   idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
DRM_ERROR("Process %d freeing buffer not owned\n",
-- 
2.19.1

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

Re: [PATCH v4 RESEND] drm/panel: add Kingdisplay kd097d04 panel driver

[Thierry Reding]

On Tue, Oct 30, 2018 at 10:15:28AM +0100, Heiko Stuebner wrote:
> From: Nickey Yang 
> 
> Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> it is a MIPI dual-DSI panel.
> 
> v4-resend:
> - Thierry noted missing dt-bindings for v4 but forgot that he
>   already had applied them one kernel release back in
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df
> v4:
> - address Philipp's comments
>   - real range for usleep_range and
>   - poweroff ordering in kingdisplay_panel_prepare
>   - return value beautification in panel_probe
> - update author naming for full name
> v3:
> - address Thierry's comments
>   - error handling for init dsi writes in init
>   - unconditionally remove the panel
>   - don't use drm_panel_detach
>   - a bit of variable signednes wiggling
> - I did talk to ChromeOS people and the delays really should be as short
>   as possible, so dropped the 100ms from the delay comments
> v2:
> - update timing + cmds from chromeos kernel
> - new backlight API including switch to devm_of_find_backlight
> - fix most of Sean Paul's comments
>   enable/prepare tracking seems something all panels do
> - document origins of the init sequence
> - lanes per dsi interface to 4 (two interfaces). Matches how tegra
>   and pending rockchip dual-dsi handle (dual-)dsi lanes
> - spdx header instead of license boilerplate
> 
> Signed-off-by: Nickey Yang 
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/gpu/drm/panel/Kconfig |  11 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  .../drm/panel/panel-kingdisplay-kd097d04.c| 473 ++
>  3 files changed, 485 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c

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 v9 1/2] dt-bindings: panel: Add Sitronix ST7701 panel documentation

[Thierry Reding]

On Fri, Jan 25, 2019 at 03:21:30AM +0530, Jagan Teki wrote:
> Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
> with inbuilt ST7701 chip.
> 
> The default regulator names in ST7701 chip is renamed in Techstar TS8550B
> so, add specific binding names for them.
> 
> Signed-off-by: Jagan Teki 
> Reviewed-by: Rob Herring 
> ---
> Changes for v8, v9:
> - none
> Changes for v7:
> - collect Rob Ack
> Changes for v6:
> - none
> 
>  .../display/panel/sitronix,st7701.txt | 30 +++
>  1 file changed, 30 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt

Both patches 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/2] drm/ttm: Implement and export ttm_dma_page_alloc_enabled

[Koenig, Christian]

Am 28.01.19 um 15:21 schrieb Thomas Hellstrom:
> On Mon, 2019-01-28 at 14:29 +0100, Thomas Hellström wrote:
>> Hi,
>>
>> On Mon, 2019-01-28 at 12:21 +, Koenig, Christian wrote:
>>> Am 25.01.19 um 14:05 schrieb Thomas Hellstrom:
 The vmwgfx driver needs to know whether the dma page pool is
 enabled
 to determine whether to refuse loading if the dma mode logic
 requests coherent memory from the dma page pool.

 Cc: "Koenig, Christian" 
 Signed-off-by: Thomas Hellstrom 
 ---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 11 +++
include/drm/ttm/ttm_page_alloc.h |  4 
2 files changed, 15 insertions(+)

 diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
 b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
 index d594f7520b7b..adf8cc189ecc 100644
 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
 +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
 @@ -1235,4 +1235,15 @@ int ttm_dma_page_alloc_debugfs(struct
 seq_file *m, void *data)
}
EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);

 +/**
 + * ttm_dma_page_alloc_enabled - Is the dma page pool enabled?
 + *
 + * Returns true if the dma page pool is enabled. false
 otherwise.
 + */
 +bool ttm_dma_page_alloc_enabled(void)
 +{
 +  return !!_manager;
 +}
 +EXPORT_SYMBOL(ttm_dma_page_alloc_enabled);
 +
>>> This is completely superfluous cause the manager is enabled as soon
>>> as
>>> it is compiled in.
>>>
>>> You could just use "#if defined(CONFIG_SWIOTLB) ||
>>> defined(CONFIG_INTEL_IOMMU)" instead.
>>>
>>> Christian.
>>>
>> Yes, that's what was done before in vmgwfx, but it's very fragile and
>> based on assumptions about what various parts of TTM does and doesn't
>> do. Chances are somebody would modify the enablement and forget to
>> modify this function.
>>
>> But of course I can change it if you think that'd be better.
>>
>> /Thomas
>>
> What about
>
> static inline bool ttm_dma_page_alloc_enabled(void)
> {
>   return (IS_ENABLED(CONFIG_INTEL_IOMMU) ||
> IS_ENABLED(CONFIG_SWIOTLB)) && _manager;
> }
>
> to avoid that layering violation?

If you drop the "&& _manager" check and move it into the header then 
that should work.

But we could as well really clean it up and add a hidden 
CONFIG_DRM_TTM_DMA_PAGE_ALLOC and remove all the references to 
CONFIG_INTEL_IOMMU and CONFIG_SWIOTLB from the code.

Christian.

>
> /Thomas
>

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

[PATCH AUTOSEL 4.20 251/304] fbdev: fbcon: Fix unregister crash when more than one framebuffer

[Sasha Levin]

From: Noralf Trønnes 

[ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ]

When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash. The fastest way for me to trigger the crash is to do a
reboot, resulting in this splat:

[   76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 
__queue_work+0x2d4/0x41c
[   76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight 
bcm2835_rng rng_core [last unloaded: tinydrm]
[   76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4
[   76.478933] Hardware name: BCM2835
[   76.478949] Backtrace:
[   76.478995] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[   76.479022]  r6: r5:c0bc73be r4: r3:6fb5bf81
[   76.479060] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c)
[   76.479134] [] (__warn) from [] 
(warn_slowpath_null+0x4c/0x58)
[   76.479165]  r9:c0eb6944 r8:0001 r7:c0e927f8 r6:c0bc73be r5:05a2 
r4:c0139e84
[   76.479197] [] (warn_slowpath_null) from [] 
(__queue_work+0x2d4/0x41c)
[   76.479222]  r6:d7666a00 r5:c0e918ee r4:dbc4e700
[   76.479251] [] (__queue_work) from [] 
(queue_work_on+0x60/0x88)
[   76.479281]  r10:c0496bf8 r9:0100 r8:c0e92ae0 r7:0001 r6:d9403700 
r5:d7666a00
[   76.479298]  r4:2113
[   76.479348] [] (queue_work_on) from [] 
(cursor_timer_handler+0x30/0x54)
[   76.479374]  r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc
[   76.479413] [] (cursor_timer_handler) from [] 
(call_timer_fn+0x100/0x230)
[   76.479435]  r4:c0e9192f r3:d758a340
[   76.479465] [] (call_timer_fn) from [] 
(expire_timers+0x10c/0x12c)
[   76.479495]  r10:4000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 
r5:c0496bf8
[   76.479513]  r4:d8a8fabc
[   76.479541] [] (expire_timers) from [] 
(run_timer_softirq+0xa8/0x184)
[   76.479570]  r9:0001 r8:c0e19280 r7: r6:c0e08088 r5:c0e1a3e0 
r4:c0e19280
[   76.479603] [] (run_timer_softirq) from [] 
(__do_softirq+0x1ac/0x3fc)
[   76.479632]  r10:c0e91680 r9:d8afc020 r8:000a r7:0100 r6:0001 
r5:0002
[   76.479650]  r4:c0eb65ec
[   76.479686] [] (__do_softirq) from [] 
(irq_exit+0xe8/0x168)
[   76.479716]  r10:d8d1a9b0 r9:d8afc000 r8:0001 r7:d949c000 r6: 
r5:c0e8b3f0
[   76.479734]  r4:
[   76.479764] [] (irq_exit) from [] 
(__handle_domain_irq+0x94/0xb0)
[   76.479793] [] (__handle_domain_irq) from [] 
(bcm2835_handle_irq+0x3c/0x48)
[   76.479823]  r8:d8afdebc r7:d8afddfc r6: r5:c0e089f8 r4:d8afddc8 
r3:d8afddc8
[   76.479851] [] (bcm2835_handle_irq) from [] 
(__irq_svc+0x70/0x98)

The problem is in the console rebinding in fbcon_fb_unbind(). It uses the
virtual console index as the new framebuffer index to bind the console(s)
to. The correct way is to use the con2fb_map lookup table to find the
framebuffer index.

Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from 
unregister_framebuffer")
Signed-off-by: Noralf Trønnes 
Reviewed-by: Mikulas Patocka 
Acked-by: Daniel Vetter 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8958ccc8b1ac..8976190b6c1f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3064,7 +3064,7 @@ static int fbcon_fb_unbind(int idx)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
con2fb_map[i] != -1) {
-   new_idx = i;
+   new_idx = con2fb_map[i];
break;
}
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.20 243/304] drm/amd/display: validate extended dongle caps

[Sasha Levin]

From: Wenjing Liu 

[ Upstream commit 99b922f9ed6a6313c0d2247cde8aa1e4a0bd67e4 ]

[why]
Some dongle doesn't have a valid extended dongle caps,
but we still set the extended dongle caps to be valid.
This causes validation fails for all timing.

[how]
If no dp_hdmi_max_pixel_clk is provided,
don't use extended dongle caps.

Signed-off-by: Wenjing Liu 
Reviewed-by: Aric Cyr 
Reviewed-by: Jun Lei 
Acked-by: Abdoulaye Berthe 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index d91df5ef0cb3..d33a5ebe990b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2240,7 +2240,8 @@ static void get_active_converter_info(
translate_dpcd_max_bpc(

hdmi_color_caps.bits.MAX_BITS_PER_COLOR_COMPONENT);
 
-   link->dpcd_caps.dongle_caps.extendedCapValid = 
true;
+   if 
(link->dpcd_caps.dongle_caps.dp_hdmi_max_pixel_clk != 0)
+   
link->dpcd_caps.dongle_caps.extendedCapValid = true;
}
 
break;
-- 
2.19.1

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

[PATCH AUTOSEL 4.20 244/304] video: clps711x-fb: release disp device node in probe()

[Sasha Levin]

From: Alexey Khoroshilov 

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/clps711x-fb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index ff561073ee4e..42f909618f04 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -287,14 +287,17 @@ static int clps711x_fb_probe(struct platform_device *pdev)
}
 
ret = of_get_fb_videomode(disp, &cfb->mode, OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   of_node_put(disp);
goto out_fb_release;
+   }
 
of_property_read_u32(disp, "ac-prescale", &cfb->ac_prescale);
cfb->cmap_invert = of_property_read_bool(disp, "cmap-invert");
 
ret = of_property_read_u32(disp, "bits-per-pixel",
   &info->var.bits_per_pixel);
+   of_node_put(disp);
if (ret)
goto out_fb_release;
 
-- 
2.19.1

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

[PATCH AUTOSEL 4.20 246/304] fbdev: fbmem: behave better with small rotated displays and many CPUs

[Sasha Levin]

From: Peter Rosin 

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/fbmem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 861bf8081619..7dd6924feaa8 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -436,7 +436,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate == FB_ROTATE_UD) {
-   for (x = 0; x < num; x++) {
+   u32 dx = image->dx;
+
+   for (x = 0; x < num && image->dx <= dx; x++) {
info->fbops->fb_imageblit(info, image);
image->dx -= image->width + 8;
}
@@ -448,7 +450,9 @@ static void fb_do_show_logo(struct fb_info *info, struct 
fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate == FB_ROTATE_CCW) {
-   for (x = 0; x < num; x++) {
+   u32 dy = image->dy;
+
+   for (x = 0; x < num && image->dy <= dy; x++) {
info->fbops->fb_imageblit(info, image);
image->dy -= image->height + 8;
}
-- 
2.19.1

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

[PATCH AUTOSEL 4.20 221/304] drm/amd/display: fix YCbCr420 blank color

[Sasha Levin]

From: Eric Yang 

[ Upstream commit 12750d1647f118496f1da727146f255f5e44d500 ]

[Why]
YCbCr420 packing format uses two chanels for luma, and 1
channel for both chroma component. Our previous implementation
did not account for this and results in every other pixel having
very high luma value, showing greyish color instead of black.

YCbCr444 = ;  .
YCbCr420 = ;  .

[How]
Program the second channel with the black color value for luma
as well.

Signed-off-by: Eric Yang 
Reviewed-by: Hugo Hu 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../drm/amd/display/dc/dce110/dce110_hw_sequencer.c   | 11 ++-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |  9 +
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index a6bcb90e8419..4443a916a0fb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -1268,10 +1268,19 @@ static void program_scaler(const struct dc *dc,
pipe_ctx->plane_res.scl_data.lb_params.depth,
&pipe_ctx->stream->bit_depth_params);
 
-   if (pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color)
+   if (pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color) {
+   /*
+* The way 420 is packed, 2 channels carry Y component, 1 
channel
+* alternate between Cb and Cr, so both channels need the pixel
+* value for Y
+*/
+   if (pipe_ctx->stream->timing.pixel_encoding == 
PIXEL_ENCODING_YCBCR420)
+   color.color_r_cr = color.color_g_y;
+
pipe_ctx->stream_res.tg->funcs->set_overscan_blank_color(
pipe_ctx->stream_res.tg,
&color);
+   }
 

pipe_ctx->plane_res.xfm->funcs->transform_set_scaler(pipe_ctx->plane_res.xfm,
&pipe_ctx->plane_res.scl_data);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 32e4c653b1b4..220ba828748d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -2165,6 +2165,15 @@ static void dcn10_blank_pixel_data(
color_space = stream->output_color_space;
color_space_to_black_color(dc, color_space, &black_color);
 
+   /*
+* The way 420 is packed, 2 channels carry Y component, 1 channel
+* alternate between Cb and Cr, so both channels need the pixel
+* value for Y
+*/
+   if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR420)
+   black_color.color_r_cr = black_color.color_g_y;
+
+
if (stream_res->tg->funcs->set_blank_color)
stream_res->tg->funcs->set_blank_color(
stream_res->tg,
-- 
2.19.1

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