Re: [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

On Mon, Feb 12, 2018 at 12:46:11PM -0500, Lyude Paul wrote:
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
[snip]
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
>
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.

Good point, I've just sent out a v2 to address your comment.  Let me know
if this isn't what you had in mind.  It may also be worth to expand the
DOC section at the top of drm_probe_helper.c to explain the interaction
between polling and runtime suspend in more detail, but I think this is
better done in a separate patch to keep the present patch small and thus
easily backportable to stable.

Thanks a lot for the review,

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

Re: [PATCH v2 22/30] drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data

[Tomi Valkeinen]

Hi,

On 13/02/18 14:00, Laurent Pinchart wrote:
> The dss_device is the top-level component in the omapdss driver. Give
> the omapdrm driver access to the dss_device pointer in order to obtain
> pointers to all other components from it. This requires a new global
> variable in the omapdss driver that will be removed when merging the
> omapdrm and omapdss drivers, but will already allow removal of several
> other global variables.

How can we support different DSS versions with this change? So far the
DSS functions used from omapdrm have been designed to be free of DSS
specific parameters, and in the TI kernel we have a separate DSS driver
for the DSS6, and omapdrm "just works" with either DSS2-5 and DSS6.

We could have the "struct dss_device *dss" and "struct dispc_device
*dispc" in omap_drv.h as "struct device" pointers instead.

Alternatively, we could just create a totally new DRM driver for DSS6,
having nothing in common with the current omapdrm. From naming
perspective that would not be so bad, as OMAP is dead =). But if we ever
get DSS7, perhaps that's again different enough that we don't want a
single DSS driver for DSS6 and DSS7.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi Rob,

On 13 February 2018 at 20:00, Rob Clark  wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, rather than an attempt at mainlining the code as it
>> currently stands. The goal is get this driver in shape over the next coming
>> months.
>
> just so others aren't confused, s/sde/dpu/g in the list below (we did
> our DAL->DC rename before sending first RFC :-P)

Heh, and it is quite a bit of code to dig through. I haven't yet got a
chance to fully check it out.

>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)

We don't really have a good story for pixel-processing API anywhere tbh.

> To add to that, a few things I've noticed (but I've mostly only gotten
> as far as the front-end of the pipeline, ie. dpu_plane):
>
>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>there are still unequal capabilities for planes (ie. some can do YUV,
>scaling, etc).
>
>But drm-hwc (or weston) isn't going to know about that, so I think we'll
>need to add support for dynamically assigning dpu_plane::pipe, similar
>to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>for drm-hwc ;-))

Formats/modifiers we do at least get per-plane. We won't know about
scaling, but at least Weston will go through trying each plane in
sequence until it finds one which accepts the configuration. Could HWC
do something like that with atomic, or does it rely on coming up with
a plan first rather than the brute-force testing approach? I haven't
seen its planner at all recently I'm afraid.

>  - I *think* we also need the same trick for combining mixers under one CRTC
>for 4k modes too?

This one I guess you can't get around though. Can they still run from
the one plane, or do you secretly consume two planes?

>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like CSC
>and scaling coefficients need to be annotated w/ __user.  (Except the 
> should
>probably be blob properties instead.. and we probably need to strip out the
>custom properties and re-introduce them separately with some userspace +
>review.)

It'd be good to know if the CSC could use the CRTC GAMMA_LUT -> CTM ->
DEGAMMA_LUT properties, if they were moved over to planes. (And if
not, why not; if there's any functionality missing from those, what it
is, etc.)

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

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

Dear drm-misc maintainers,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:

This series has been reviewed, consent has been expressed by the most
interested parties, patch [1/5] which touches files outside drivers/gpu
has been acked and I've just out a v2 addressing the only objection
raised.  My plan is thus to wait another two days for comments and,
barring further objections, push to drm-misc this weekend.

However I'm struggling with the decision whether to push to next or
fixes.  The series is marked for stable, however the number of
affected machines is limited and for an issue that's been present
for 5 years it probably doesn't matter if it soaks another two months
in linux-next befor it gets backported.  Hence I tend to err on the
side of caution and push to next, however a case could be made that
fixes is more appropriate.

I'm lacking experience making such decisions and would be interested
to learn how you'd handle this.

Thanks,

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

[Bug 105083] Random blinking display

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #1 from Michel Dänzer  ---
Please attach the output of dmesg captured while the problem is occurring,
preferably with amdgpu.dc_log=1 .

-- 
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: [Mesa-dev] [PATCH 07/21] vulkan: Add EXT_acquire_xlib_display

[Eric Engestrom]

On Tuesday, 2018-02-13 16:31:20 -0800, Keith Packard wrote:
> This extension adds the ability to borrow an X RandR output for
> temporary use directly by a Vulkan application. For DRM, we use the
> Linux resource leasing mechanism.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac|  32 +++
>  meson.build |  17 ++
>  meson_options.txt   |   7 +
>  src/vulkan/Makefile.am  |   5 +
>  src/vulkan/wsi/meson.build  |   7 +
>  src/vulkan/wsi/wsi_common_display.c | 472 
> 
>  src/vulkan/wsi/wsi_common_display.h |  17 ++
>  7 files changed, 557 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 46318365603..cf05d049c26 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1547,6 +1547,7 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = 
> xyes -a "x$dri_platform" = x
>  AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
>  AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
> xyes )
>  AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a 
> "x$dri_platform" = xwindows )
> +AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
>  
>  AC_ARG_ENABLE([shared-glapi],
>  [AS_HELP_STRING([--enable-shared-glapi],
> @@ -1846,6 +1847,18 @@ if test x"$enable_dri3" = xyes; then
>  PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
>  fi
>  
> +
> +if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; 
> then
> +have_xlease=yes
> +else
> +have_xlease=no
> +fi
> +
> +if test x"$have_xlease" = xyes; then
> +randr_modules="x11-xcb xcb-randr"
> +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> +fi
> +
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> @@ -1853,6 +1866,25 @@ AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo 
> "$platforms" | grep -q 'drm')
>  AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
> 'surfaceless')
>  AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
>  
> +AC_ARG_ENABLE(xlib-lease,
> +[AS_HELP_STRING([--enable-xlib-lease]
> +[enable VK_acquire_xlib_display using X leases])],
> +[enable_xlib_lease=$enableval], [enable_xlib_lease=auto])
> +case "x$enable_xlib_lease" in
> +xyes)
> +;;
> +xno)
> +;;
> +*)
> +if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 
> 'drm'; then
> +enable_xlib_lease=yes
> +else
> +enable_xlib_lease=no
> +fi
> +esac
> +
> +AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
> +
>  dnl
>  dnl More DRI setup
>  dnl
> diff --git a/meson.build b/meson.build
> index aeb7f5e2917..595b0f66cd7 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -262,6 +262,19 @@ if _platforms != ''
>egl_native_platform = _split[0]
>  endif
>  
> +with_xlib_lease = get_option('xlib-lease')
> +if with_xlib_lease == 'auto'
> +  if with_platform_x11 and with_platform_display
> +with_xlib_lease = true
> +  else
> +with_xlib_lease = false
> +  endif
> +elif with_xlib_lease == 'true'
> +  with_xlib_lease = true
> +else
> +  with_xlib_lease = false
> +endif

Can be simplified a bit:

  _xlib_lease = get_option('xlib-lease')
  if _xlib_lease == 'auto'
with_xlib_lease = with_platform_x11 and with_platform_display
  else
with_xlib_lease = _xlib_lease == 'true'
  endif

(We also usually try to avoid changing the type of a var, and meson might
start being more strict with types in future releases)

> +
>  with_glx = get_option('glx')
>  if with_glx == 'auto'
>if with_dri
> @@ -1151,6 +1164,7 @@ dep_xcb_present = []
>  dep_xcb_sync = []
>  dep_xcb_xfixes = []
>  dep_xshmfence = []
> +dep_xcb_xrandr = []
>  if with_platform_x11
>if with_glx == 'xlib' or with_glx == 'gallium-xlib'
>  dep_x11 = dependency('x11')
> @@ -1190,6 +1204,9 @@ if with_platform_x11
>if with_egl
>  dep_xcb_xfixes = dependency('xcb-xfixes')
>endif
> +  if with_xlib_lease
> +dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
> +  endif
>  endif
>  
>  if get_option('gallium-extra-hud')
> diff --git a/meson_options.txt b/meson_options.txt
> index 7fafe2deaac..d38c9aa6149 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -286,3 +286,10 @@ option(
>value : '',
>description : 'Comma delimited list of tools to build. choices : 
> freedreno,glsl,intel,nir,nouveau or all'
>  )
> +option(
> +  'xlib-lease',
> +  type : 'combo',
> +  value : 'auto',
> +  choices : ['auto', 'true', 'false'],
> +  description : 'Enable VK_EXT_acquire_xlib_display.'
> +)
> diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
> index c33ac5758f7..e96ef68972c 100644
> --- a/src/vulkan/Makefile.am
> +++ b/src/vulkan/Makefile.am
> 

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #16 from Alex Deucher  ---
Does disabling MSIs help?  Append amdgpu.msi=0 to the kernel command line in
grub?

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

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

I added all three patches to my next tree
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=next
This will hoepfully reveal any fallout.

Would be good to have an ACK from the score, tile and um maintainers in case
they verified that this change did not break anything.



On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on 
>>> HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to 
>>> build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
> 
>>> Signed-off-by: Farhan Ali 
>>> Tested-by: Dong Jia Shi 
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the 
>> s390
>> tree?
>>
>>
>>> ---
>>>  drivers/video/Kconfig   | 1 -
>>>  drivers/video/fbdev/Kconfig | 2 +-
>>>  2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>>  #
>>>
>>>  menu "Graphics support"
>>> -   depends on HAS_IOMEM
>>>
>>>  config HAVE_FB_ATMEL
>>> bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>>  config FB_OPENCORES
>>> tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> -   depends on FB && HAS_DMA
>>> +   depends on FB && HAS_DMA && HAS_IOMEM
>>> select FB_CFB_FILLRECT
>>> select FB_CFB_COPYAREA
>>> select FB_CFB_IMAGEBLIT
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 

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

[Bug 105089] radeonsi GPU lockup / crash with wine [The Witcher 3]

[bugzilla-daemon]

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

--- Comment #2 from galym  ---
Created attachment 137351
  --> https://bugs.freedesktop.org/attachment.cgi?id=137351=edit
Game stops working when I start the fight with the king of the wolves in quest
dedicated to Ciri

-- 
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: Question about lima kernel MM implementation

[Rob Clark]

On Tue, Feb 13, 2018 at 8:34 AM, Qiang Yu  wrote:
> Hi guys,
>
> I'm working on the Lima project for ARM mali400/450 GPU. Now lima
> kernel driver uses CMA for all buffers, but mali400/450 GPU has MMU
> for each vertex/fragment shader processor, so I want to refine the lima
> kernel driver for non-contiguous memory support.
>
> After some investigation on current available MM method used by
> several linux kernel DRM driver, I can't find an exactly match one for
> lima. So I'd like to hear some advise from you and see if I have some
> miss understanding on current MMs and if there's better approach.
> If can't use existing MM, I may have to write one for lima.
>
> About Mali400/450 GPU:
> 1. it has separate vertex and fragment shader processors, 1 vertex
> processor and 1~4 fragment processors are grouped to process an
> OpenGL draw
> 2. each processor has an MMU work independently
> 3. Mali400/450 will work with different display DRM driver, some
> display DRM driver support non-contiguous framebuffer and some
> not
>
> My requirement:
> 1. support non-contiguous memory allocation as GPU buffer
> 2. support contiguous memory allocation too for exporting to some
> display DRM driver as framebuffer

btw, I think etnaviv deals w/ contiguous scanout buffer by just
importing the scanout buffer from the other display drm driver.  So I
think you could avoid having to allocate these buffers.

(iirc, etnaviv does need contiguous buffers internally for a few
things, like cmdstream (?) and mmu pagetables)

BR,
-R

> 3. no GPU page fault for better performance and avoid multi MMU
> page fault handling, CPU page fault is OK
> 4. better have buffer swap to disk feature when memory is full
>
> Current MM:
> 1. drm_gem_cma_object, only support contiguous memory
> 2. drm_gem_get_pages
>   1) need to combine with cma method for contiguous memory
>   2) when shrink is needed, swap some idle buffer to disk and put
>   pages, need implement by myself
>   3) additional shmem layer introduced
> 3. TTM TTM_PL_SYSTEM only
>   1) no contiguous memory support
>   2) too complicated as we don't need other functions of TTM
>   3) need GPU page fault to populate memory?
>   4) no page pool for cached memory
>
> My plan:
> 1. for contiguous memory allocation use dma_alloc_*
> 2. for non-contiguous memory allocation, use a page pool from
> alloc_page
> 3. buffer is not really allocated when GEM_CREATE, but in CPU
> page fault handler and task submit buffer validation which make
> sure no GPU page fault
> 4. in shrinker handler, free un-used page in the pool, if still not
> enough, swap some idle buffer to disk
>
> 3&4 apply to both dma_alloc buffer and alloc_page buffer.
>
> Thanks,
> Qiang
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm/i915: Add HDCP support to i915

[Hans Verkuil]

On 14/02/18 14:44, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 3:33 AM, Hans Verkuil  wrote:
>> Hi Sean,
>>
>> On 13/02/18 21:18, Sean Paul wrote:
>>>
>>> Hi Dave,
>>> Here's the pull request for HDCP. Hopefully no surprises since it's been 
>>> baking
>>> in drm-tip for a while now.
>>>
>>> topic/hdcp-2018-02-13:
>>> Add HDCP support to i915 drm driver.
>>>
>>> Cheers, Sean
>>>
>>>
>>> The following changes since commit b0caa1333b6d2d928a00304e9fb6674526c37b79:
>>>
>>>   Merge tag 'imx-drm-next-2018-01-02' of 
>>> git://git.pengutronix.de/git/pza/linux into drm-next (2018-01-05 11:33:24 
>>> +1000)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13
>>>
>>> for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289:
>>>
>>>   drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 
>>> -0500)
>>>
>>> 
>>> Add HDCP support to i915 drm driver.
>>>
>>> 
>>> Chris Wilson (1):
>>>   drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
>>>
>>> Ramalingam C (12):
>>>   drm/i915: Extending HDCP for HSW, BDW and BXT+
>>>   drm/i915: II stage HDCP auth for repeater only
>>>   drm/i915: Start repeater auth on READY/CP_IRQ
>>>   drm/i915: Check for downstream topology errors
>>>   drm/i915: Handle failure from 2nd stage HDCP auth
>>>   drm/i915: Stop encryption for repeater with no sink
>>>   drm/i915: Connector info in HDCP debug msgs
>>>   drm/i915: Retry HDCP bksv read
>>>   drm/i915: Optimize HDCP key load
>>>   drm/i915: Detect panel's hdcp capability
>>>   drm/i915: Reauthenticate HDCP on failure
>>>   drm/i915: fix misalignment in HDCP register def
>>
>> Were these ever posted to dri-devel? I can't find them there.
>>
>> Do these patches from Ramalingam C add repeater support to the i915?
>> If so, then I am certainly interested in seeing these since we (Cisco)
>> are working on HDCP (including repeater support) for HDMI receivers.
>>
> 
> Hi Hans!
> We had a conversation on these patches and repeater support when I
> initially posted them :-)
> https://lists.freedesktop.org/archives/intel-gfx/2017-December/149112.html

Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen.
At least not on dri-devel. It's a bit weird.

Regards,

Hans

> 
> It'd be great if you could try it out and report back.
> 
> Cheers,
> 
> Sean
> 
>> Nothing public yet, it's too early for that. But it would be nice to
>> test with the i915 driver.
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Sean Paul (13):
>>>   drm: Fix link-status kerneldoc line lengths
>>>   drm/i915: Add more control to wait_for routines
>>>   drm: Add Content Protection property
>>>   drm: Add some HDCP related #defines
>>>   drm/i915: Add HDCP framework + base implementation
>>>   drm/i915: Make use of indexed write GMBUS feature
>>>   drm/i915: Add function to output Aksv over GMBUS
>>>   drm/i915: Implement HDCP for HDMI
>>>   drm/i915: Implement HDCP for DisplayPort
>>>   drm/i915: Don't allow HDCP on PORT E/F
>>>   drm/i915: Only disable HDCP when it's active
>>>   drm/i915: Restore HDCP DRM_INFO when with no downstream
>>>   drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS
>>>
>>>  drivers/gpu/drm/drm_atomic.c |   8 +
>>>  drivers/gpu/drm/drm_connector.c  |  87 +++-
>>>  drivers/gpu/drm/i915/Makefile|   1 +
>>>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>>>  drivers/gpu/drm/i915/i915_reg.h  |  86 
>>>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
>>>  drivers/gpu/drm/i915/intel_ddi.c |  36 ++
>>>  drivers/gpu/drm/i915/intel_display.c |   4 +
>>>  drivers/gpu/drm/i915/intel_dp.c  | 277 +++-
>>>  drivers/gpu/drm/i915/intel_drv.h | 109 -
>>>  drivers/gpu/drm/i915/intel_hdcp.c| 807 
>>> +++
>>>  drivers/gpu/drm/i915/intel_hdmi.c| 250 +++
>>>  drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
>>>  drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
>>>  drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
>>>  include/drm/drm_connector.h  |  16 +
>>>  include/drm/drm_dp_helper.h  |  17 +
>>>  include/drm/drm_hdcp.h   |  41 ++
>>>  include/uapi/drm/drm_mode.h  |   4 +
>>>  19 files changed, 1821 insertions(+), 43 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>>>  create mode 100644 include/drm/drm_hdcp.h
>>>
>>

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

Re: [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Jani Nikula]

On Tue, 13 Feb 2018, Anusha Srivatsa  wrote:
> Forward Error Correction is supported on DP 1.4.
> This patch adds corresponding DPCD register definitions.
>
> v2: Add dri-devel mailing list to the CC list(Jani)
>
> v3: Change names, add missing masks (Manasi)
>
> v4: Add missing shifts to mask (Manasi)
>
> v5: Arrange the definitions in ascending order
> of the address (Jani)

Okay, my apologies, I noticed some further errors that I really should
have noticed earlier. Please see comments inline.

>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  include/drm/drm_dp_helper.h | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c239e6e..a19d6fb 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -329,6 +329,13 @@
>  # define DP_DS_12BPC 2
>  # define DP_DS_16BPC 3
>  
> +/* DP Forward error Correction Registers */
> +#define DP_FEC_CAPABILITY(0x090)

Nitpick, the braces are unnecessary.

All the FEC dpcd offset definitions should have /* 1.4 */ at the end
(just the offset macros, not the contents).

> +# define DP_FEC_CAPABLE  (1 << 0)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
> +# define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +
>  /* link configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -445,6 +452,18 @@
>  #define DP_UPSTREAM_DEVICE_DP_PWR_NEED   0x118   /* 1.2 */
>  # define DP_PWR_NOT_NEEDED   (1 << 0)
>  
> +#define DP_FEC_CONFIGURATION 0x120
> +# define DP_FEC_READY(1 << 0)
> +# define DP_FEC_ERR_COUNT_DIS(0 << 1)
> +# define DP_FEC_UNCORR_BLK_ERROR_COUNT   (1 << 1)
> +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1)
> +# define DP_FEC_BIT_ERROR_COUNT  (3 << 1)
> +# define DP_FEC_ERR_COUNT_SEL_MASK   (0xff << 4)

# define DP_FEC_ERROR_COUNT_SEL_MASK(7 << 1)

Put that above the values for error count sel.

And then

#define DP_FEC_LANE_SELECT_MASK (3 << 4)

> +# define DP_FEC_LANE_0_SELECT(0 << 4)
> +# define DP_FEC_LANE_1_SELECT(1 << 4)
> +# define DP_FEC_LANE_2_SELECT(2 << 4)
> +# define DP_FEC_LANE_3_SELECT(3 << 4)
> +
>  #define DP_AUX_FRAME_SYNC_VALUE  0x15c   /* eDP 1.4 */
>  # define DP_AUX_FRAME_SYNC_VALID (1 << 0)
>  
> @@ -620,6 +639,17 @@
>  #define DP_TEST_SINK 0x270
>  # define DP_TEST_SINK_START  (1 << 0)
>  
> +#define DP_FEC_STATUS0x280
> +# define DP_FEC_DECODE_EN_DETECTED   (1 << 0)
> +# define DP_FEC_DECODE_DIS_DETECTED  (1 << 1)
> +
> +#define DP_FEC_ERROR_COUNT_LSB   0x0281
> +
> +#define DP_FEC_ERROR_COUNT_MSB   0x0282
> +# define DP_FEC_ERROR_COUNT_MASK 0x7F
> +# define DP_FEC_ERR_COUNT_SHIFT  8

Unnecessary.

> +# define DP_FEC_ERR_COUNT_VALID  (1 << 7)
> +
>  #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
>  # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
>  # define DP_PAYLOAD_ACT_HANDLED (1 << 1)

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

[PATCH] video: fbdev: s3c-fb: remove dead platform code for Exynos and S5PV210 platforms

[Bartlomiej Zolnierkiewicz]

Exynos5, Exynos4 and S5PV210 platforms have been converted to
use Device Tree and Exynos DRM driver long time ago.  Remove
dead platform code for these platforms and update Kconfig
s3c-fb entry accordingly.

Cc: Jingoo Han 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
 drivers/video/fbdev/Kconfig  |3 
 drivers/video/fbdev/s3c-fb.c |  162 ---
 2 files changed, 1 insertion(+), 164 deletions(-)

Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig   2018-02-12 14:28:32.392677896 +0100
+++ b/drivers/video/fbdev/Kconfig   2018-02-14 12:54:06.399057592 +0100
@@ -2020,8 +2020,7 @@ config FB_TMIO_ACCELL
 
 config FB_S3C
tristate "Samsung S3C framebuffer support"
-   depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || \
-   ARCH_S5PV210 || ARCH_EXYNOS)
+   depends on FB && (CPU_S3C2416 || ARCH_S3C64XX)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/s3c-fb.c
===
--- a/drivers/video/fbdev/s3c-fb.c  2017-10-18 14:35:22.063448310 +0200
+++ b/drivers/video/fbdev/s3c-fb.c  2018-02-14 12:04:00.719262463 +0100
@@ -1716,63 +1716,6 @@ static struct s3c_fb_win_variant s3c_fb_
},
 };
 
-static struct s3c_fb_win_variant s3c_fb_data_s5p_wins[] = {
-   [0] = {
-   .has_osd_c  = 1,
-   .osd_size_off   = 0x8,
-   .palette_sz = 256,
-   .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
-  VALID_BPP(15) | VALID_BPP(16) |
-  VALID_BPP(18) | VALID_BPP(19) |
-  VALID_BPP(24) | VALID_BPP(25) |
-  VALID_BPP(32)),
-   },
-   [1] = {
-   .has_osd_c  = 1,
-   .has_osd_d  = 1,
-   .osd_size_off   = 0xc,
-   .has_osd_alpha  = 1,
-   .palette_sz = 256,
-   .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
-  VALID_BPP(15) | VALID_BPP(16) |
-  VALID_BPP(18) | VALID_BPP(19) |
-  VALID_BPP(24) | VALID_BPP(25) |
-  VALID_BPP(32)),
-   },
-   [2] = {
-   .has_osd_c  = 1,
-   .has_osd_d  = 1,
-   .osd_size_off   = 0xc,
-   .has_osd_alpha  = 1,
-   .palette_sz = 256,
-   .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
-  VALID_BPP(15) | VALID_BPP(16) |
-  VALID_BPP(18) | VALID_BPP(19) |
-  VALID_BPP(24) | VALID_BPP(25) |
-  VALID_BPP(32)),
-   },
-   [3] = {
-   .has_osd_c  = 1,
-   .has_osd_alpha  = 1,
-   .palette_sz = 256,
-   .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
-  VALID_BPP(15) | VALID_BPP(16) |
-  VALID_BPP(18) | VALID_BPP(19) |
-  VALID_BPP(24) | VALID_BPP(25) |
-  VALID_BPP(32)),
-   },
-   [4] = {
-   .has_osd_c  = 1,
-   .has_osd_alpha  = 1,
-   .palette_sz = 256,
-   .valid_bpp  = (VALID_BPP1248 | VALID_BPP(13) |
-  VALID_BPP(15) | VALID_BPP(16) |
-  VALID_BPP(18) | VALID_BPP(19) |
-  VALID_BPP(24) | VALID_BPP(25) |
-  VALID_BPP(32)),
-   },
-};
-
 static struct s3c_fb_driverdata s3c_fb_data_64xx = {
.variant = {
.nr_windows = 5,
@@ -1804,102 +1747,6 @@ static struct s3c_fb_driverdata s3c_fb_d
.win[4] = _fb_data_64xx_wins[4],
 };
 
-static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
-   .variant = {
-   .nr_windows = 5,
-   .vidtcon= VIDTCON0,
-   .wincon = WINCON(0),
-   .winmap = WINxMAP(0),
-   .keycon = WKEYCON,
-   .osd= VIDOSD_BASE,
-   .osd_stride = 16,
-   .buf_start  = VIDW_BUF_START(0),
-   .buf_size   = VIDW_BUF_SIZE(0),
-   .buf_end= VIDW_BUF_END(0),
-
-   .palette = {
-   [0] = 0x2400,
-   [1] = 0x2800,
-   [2] = 0x2c00,
-   [3] = 0x3000,
-   [4] = 0x3400,
-   },
-
-   .has_shadowcon  

Re: [PATCH 1/2] drm/tilcdc: Delete an error message for a failed memory allocation in seven functions

[Jyri Sarha]

On 06/02/18 23:23, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 6 Feb 2018 21:51:15 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Thanks,
picked for the tilcdc next pull request.

Best regards,
Jyri

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 4 +---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 4 +---
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 9 ++---
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 8 ++--
>  4 files changed, 6 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 8bf6bb93dc79..1b278a22c8b7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -994,10 +994,8 @@ int tilcdc_crtc_create(struct drm_device *dev)
>   int ret;
>  
>   tilcdc_crtc = devm_kzalloc(dev->dev, sizeof(*tilcdc_crtc), GFP_KERNEL);
> - if (!tilcdc_crtc) {
> - dev_err(dev->dev, "allocation failed\n");
> + if (!tilcdc_crtc)
>   return -ENOMEM;
> - }
>  
>   init_completion(_crtc->palette_loaded);
>   tilcdc_crtc->palette_base = dmam_alloc_coherent(dev->dev,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 1afde61f1247..b8a5e4ed22e6 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -233,10 +233,8 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
> device *dev)
>   int ret;
>  
>   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> - if (!priv) {
> - dev_err(dev, "failed to allocate private data\n");
> + if (!priv)
>   return -ENOMEM;
> - }
>  
>   ddev = drm_dev_alloc(ddrv, dev);
>   if (IS_ERR(ddev))
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 8eebb5f826a6..0b6aa95aec89 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -101,10 +101,8 @@ static struct drm_encoder *panel_encoder_create(struct 
> drm_device *dev,
>  
>   panel_encoder = devm_kzalloc(dev->dev, sizeof(*panel_encoder),
>GFP_KERNEL);
> - if (!panel_encoder) {
> - dev_err(dev->dev, "allocation failed\n");
> + if (!panel_encoder)
>   return NULL;
> - }
>  
>   panel_encoder->mod = mod;
>  
> @@ -210,10 +208,8 @@ static struct drm_connector 
> *panel_connector_create(struct drm_device *dev,
>  
>   panel_connector = devm_kzalloc(dev->dev, sizeof(*panel_connector),
>  GFP_KERNEL);
> - if (!panel_connector) {
> - dev_err(dev->dev, "allocation failed\n");
> + if (!panel_connector)
>   return NULL;
> - }
>  
>   panel_connector->encoder = encoder;
>   panel_connector->mod = mod;
> @@ -294,7 +290,6 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
> device_node *np)
>  
>   info = kzalloc(sizeof(*info), GFP_KERNEL);
>   if (!info) {
> - pr_err("%s: allocation failed\n", __func__);
>   of_node_put(info_np);
>   return NULL;
>   }
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index 7e3643462a08..c45cabb38db0 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -111,10 +111,8 @@ static struct drm_encoder *tfp410_encoder_create(struct 
> drm_device *dev,
>  
>   tfp410_encoder = devm_kzalloc(dev->dev, sizeof(*tfp410_encoder),
> GFP_KERNEL);
> - if (!tfp410_encoder) {
> - dev_err(dev->dev, "allocation failed\n");
> + if (!tfp410_encoder)
>   return NULL;
> - }
>  
>   tfp410_encoder->dpms = DRM_MODE_DPMS_OFF;
>   tfp410_encoder->mod = mod;
> @@ -224,10 +222,8 @@ static struct drm_connector 
> *tfp410_connector_create(struct drm_device *dev,
>  
>   tfp410_connector = devm_kzalloc(dev->dev, sizeof(*tfp410_connector),
>   GFP_KERNEL);
> - if (!tfp410_connector) {
> - dev_err(dev->dev, "allocation failed\n");
> + if (!tfp410_connector)
>   return NULL;
> - }
>  
>   tfp410_connector->encoder = encoder;
>   tfp410_connector->mod = mod;
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/tilcdc: panel: Use common error handling code in of_get_panel_info()

[Jyri Sarha]

On 06/02/18 23:24, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 6 Feb 2018 22:10:11 +0100
> 
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
> 
> Signed-off-by: Markus Elfring 

Well, it is couple of lines less. If I would just have couple weeks time
to implement proper drm panel support for tilcdc and get rid of this
driver all together...

Picked for the next tilcdc pullrequest.

Thanks,
Jyri


> ---
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 0b6aa95aec89..cf9ca16fee81 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -289,10 +289,8 @@ static struct tilcdc_panel_info 
> *of_get_panel_info(struct device_node *np)
>   }
>  
>   info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info) {
> - of_node_put(info_np);
> - return NULL;
> - }
> + if (!info)
> + goto put_node;
>  
>   ret |= of_property_read_u32(info_np, "ac-bias", >ac_bias);
>   ret |= of_property_read_u32(info_np, "ac-bias-intrpt", 
> >ac_bias_intrpt);
> @@ -311,11 +309,11 @@ static struct tilcdc_panel_info 
> *of_get_panel_info(struct device_node *np)
>   if (ret) {
>   pr_err("%s: error reading panel-info properties\n", __func__);
>   kfree(info);
> - of_node_put(info_np);
> - return NULL;
> + info = NULL;
>   }
> - of_node_put(info_np);
>  
> +put_node:
> + of_node_put(info_np);
>   return info;
>  }
>  
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: sii902x: Fall back to standard modes

[Linus Walleij]

The following happens when connection a DVI output driven
from the SiI9022 using a DVI-to-VGA adapter plug:

i2c i2c-0: sendbytes: NAK bailout.
i2c i2c-0: sendbytes: NAK bailout.

Then no picture. Apparently the I2C engine inside the SiI9022
is not smart enough to try to fall back to DDC I2C. Or the
vendor have not integrated the electronics properly. I don't
know which one it is.

By using standard modes as fallback, the bridge probes nicely
with a minor warning and we get picture.

This code is inspired by similar code in the dumb VGA bridge.

Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/bridge/sii902x.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index b1ab4ab09532..4483095c4013 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -168,8 +168,19 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
return ret;
 
edid = drm_get_edid(connector, sii902x->i2c->adapter);
-   drm_mode_connector_update_edid_property(connector, edid);
-   if (edid) {
+   if (!edid) {
+   /*
+* This happens when using a simple DVI-to-VGA converter
+* dongle for example: the I2C lines are not bridged over
+* to VGA DDC.
+*/
+   DRM_INFO("EDID readout failed, falling back to standard 
modes\n");
+   ret = drm_add_modes_noedid(connector, 1920, 1080);
+   /* Set some standard resolution most monitors can handle */
+   drm_set_preferred_mode(connector, 1024, 768);
+   } else {
+   /* Data from EDID readout */
+   drm_mode_connector_update_edid_property(connector, edid);
num = drm_add_edid_modes(connector, edid);
kfree(edid);
}
-- 
2.14.3

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

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Rob Clark]

On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone  wrote:
> Hi Rob,
>
> On 13 February 2018 at 20:00, Rob Clark  wrote:
>> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:
>>> Qualcomm has been working for the past few weeks on forward porting their
>>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>>> request for review, rather than an attempt at mainlining the code as it
>>> currently stands. The goal is get this driver in shape over the next coming
>>> months.
>>
>> just so others aren't confused, s/sde/dpu/g in the list below (we did
>> our DAL->DC rename before sending first RFC :-P)
>
> Heh, and it is quite a bit of code to dig through. I haven't yet got a
> chance to fully check it out.
>
>>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
>
> We don't really have a good story for pixel-processing API anywhere tbh.
>
>> To add to that, a few things I've noticed (but I've mostly only gotten
>> as far as the front-end of the pipeline, ie. dpu_plane):
>>
>>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>>there are still unequal capabilities for planes (ie. some can do YUV,
>>scaling, etc).
>>
>>But drm-hwc (or weston) isn't going to know about that, so I think we'll
>>need to add support for dynamically assigning dpu_plane::pipe, similar
>>to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>>for drm-hwc ;-))
>
> Formats/modifiers we do at least get per-plane. We won't know about
> scaling, but at least Weston will go through trying each plane in
> sequence until it finds one which accepts the configuration. Could HWC
> do something like that with atomic, or does it rely on coming up with
> a plan first rather than the brute-force testing approach? I haven't
> seen its planner at all recently I'm afraid.
>
>>  - I *think* we also need the same trick for combining mixers under one CRTC
>>for 4k modes too?
>
> This one I guess you can't get around though. Can they still run from
> the one plane, or do you secretly consume two planes?
>

I think it is still the case, like mdp5, that you need two hw pipes..
but actually it gets more crazy, since there are some cases where two
planes could share a hw pipe.  Not sure that weston or drm-hwc is
going to have much hope in being able to deal with that, so I think
virtualizing the planes and crtcs is the better route.

BR,
-R

>>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like 
>> CSC
>>and scaling coefficients need to be annotated w/ __user.  (Except the 
>> should
>>probably be blob properties instead.. and we probably need to strip out 
>> the
>>custom properties and re-introduce them separately with some userspace +
>>review.)
>
> It'd be good to know if the CSC could use the CRTC GAMMA_LUT -> CTM ->
> DEGAMMA_LUT properties, if they were moved over to planes. (And if
> not, why not; if there's any functionality missing from those, what it
> is, etc.)
>
> Cheers,
> Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Tomi Valkeinen]

Hi,

On 13/02/18 14:00, Laurent Pinchart wrote:
> Hello,
> 
> Most of this series has previously been posted as part of "[PATCH 00/48]
> omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> Miscellaneous fixes and cleanups" posted and merged a few days ago, it
> completes the rework of the omapdrm and omapdss drivers to replace most
> global variables with dynamically-allocated objects. The actual merge of
> the omapdrm and omapdss drivers has been left out for now as it still
> suffers from unresolved issues.
> 
> As with the previous series I have other pending patches based on top of this,
> as passing driver objects around explicitly helps not relying on more global
> variables that would hinder the effort to move to the DRM bridge and DRM panel
> APIs.
> 
> Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen
> significant changes and I have thus dropped the Reviewed-by tag from
> Sebastian. All other patches have been rebased and reordered, thus sometimes
> modified to resolve conflicts, but have otherwise seen only minor changes.
> 
> The series is based on top of the omapdrm-next branch from
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git.
> 
> Tomi, as the series has been stripped of its controversial patches, I think
> it's now ready to be merged (pending review of the patches mentioned above of
> course). I have tested it on both a Panda board and an AM57xx EVM without any
> issues (and this time I made sure to try with the drivers compiled as
> modules).

I have to admit I didn't go through every line of the patches, but
overall I think this looks good. The only problem is the support for
DSS6, which I mentioned in the other mail.

We don't have DSS6 support in mainline, but it's a critical thing for TI
to support. If it helps, we can upstream the current DSS6 driver (which
is not very big), so that these can be reworked with DSS6 included. Or
we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
driver working on top of these (which, afaics, is not possible at the
moment).

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_hwcomposer: fix check for valid fence fd for in fences

[Robert Foss]

Hey Rob,

This looks good to me, feel free to add my r-b.
Reviewed-by: Robert Foss 


Rob.

On 02/13/2018 11:11 PM, Rob Herring wrote:

The check for a valid fence fd is inverted, so we're failing to pass
IN_FENCE_FD's to the kernel when we have a valid fence.

Reported-by: Alexandru-Cosmin Gheorghe 
Signed-off-by: Rob Herring 
---
  drmdisplaycompositor.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index 3a20b31dec99..e556e8641d79 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -589,7 +589,7 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition 
*display_comp,
else
  rotation |= DRM_MODE_ROTATE_0;
  
-  if (fence_fd < 0) {

+  if (fence_fd >= 0) {
  int prop_id = plane->in_fence_fd_property().id();
  if (prop_id == 0) {
  ALOGE("Failed to get IN_FENCE_FD property id");


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

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Maarten Lankhorst]

Op 14-02-18 om 09:46 schreef Lukas Wunner:
> Dear drm-misc maintainers,
>
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> This series has been reviewed, consent has been expressed by the most
> interested parties, patch [1/5] which touches files outside drivers/gpu
> has been acked and I've just out a v2 addressing the only objection
> raised.  My plan is thus to wait another two days for comments and,
> barring further objections, push to drm-misc this weekend.
>
> However I'm struggling with the decision whether to push to next or
> fixes.  The series is marked for stable, however the number of
> affected machines is limited and for an issue that's been present
> for 5 years it probably doesn't matter if it soaks another two months
> in linux-next befor it gets backported.  Hence I tend to err on the
> side of caution and push to next, however a case could be made that
> fixes is more appropriate.
>
> I'm lacking experience making such decisions and would be interested
> to learn how you'd handle this.
>
> Thanks,
>
> Lukas

I would say fixes, it doesn't look particularly scary. :)

~Maarten

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

[Bug 105089] radeonsi GPU lockup / crash with wine [The Witcher 3]

[bugzilla-daemon]

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

Bug ID: 105089
   Summary: radeonsi GPU lockup / crash with wine [The Witcher 3]
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: housegregory...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Hi

I have GPU lockup after few minutes of playing The Witcher 3 (the quest is
Ciri's story: The King of the wolves)

I use wine vanilla with patch:
https://raw.githubusercontent.com/wine-compholio/wine-staging/master/patches/wined3d-buffer_create/0001-wined3d-Do-not-pin-large-buffers.patch

I also tried various wine vanilla and wine staging from 2.22 to 3.1.


My specs are:
Radeon R7 350 (02:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] (rev 87))
Xorg 1.19.3
Linux 4.14.12
mesa-17.3.1 (I had same issue with mesa-git)
llvm-5.0

OpenGL renderer string: AMD CAPE VERDE (DRM 3.19.0 / 4.14.12-gentoo, LLVM
5.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.1
OpenGL core profile shading language version string: 4.50

Maybe I should do some tests here, but I don't know which of these.

-- 
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 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #14 from arne_woer...@yahoo.com ---
i forgot to mention:
both kernels (4.15.2-2-MANJARO (60Hz vert freq) and 4.14.16-1-MANJARO (40Hz
vert freq)) work fine,
_but_ they both need at least one of these kernel parameters in the grub.cfg:
amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.audio=0

-arne

-- 
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 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #2 from Vavooon  ---
(In reply to denisgolovan from comment #0)
> Hi
> 
> Upgrading to 4.15.2 with amdgpu dc results in blinking of color temperature
> when redshift application started. Kernel 4.13.13 worked fine.
> 
> See https://github.com/jonls/redshift/issues/221#issuecomment-365376437 for
> details

Did you enable AMDGPU DC by changing kernel boot parameters?

(In reply to Michel Dänzer from comment #1)
> Please attach the output of dmesg captured while the problem is occurring,
> preferably with amdgpu.dc_log=1 .

I tried to capture some dmesg log, but booting with suggested kernel line
amdgpu.dc_log=1 but no output was produced at flickering. Than I realized that
I have to enable amdgpu.dc in order to use it's logging :) and the issue
disappeared. So far after a hour I don't see any flickering anymore.

-- 
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 v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

On Tue, Feb 13, 2018 at 1:05 PM, Bartlomiej Zolnierkiewicz
 wrote:
> On Saturday, February 10, 2018 01:48:55 PM Mathieu Malaterre wrote:
>>  Hi,
>>
>> On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
>>  wrote:
>> > On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
>> >> Bartlomiej,
>> >>
>> >> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>> >>  wrote:
>> >> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
>> >> >> Bartlomiej,
>> >> >>
>> >> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>> >> >>  wrote:
>> >> >> >
>> >> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> >> >> >> When the linux kernel is build with (typical kernel ship with Debian
>> >> >> >> installer):
>> >> >> >>
>> >> >> >> CONFIG_FB_OF=y
>> >> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
>> >> >> >> CONFIG_FB_RADEON=m
>> >> >> >>
>> >> >> >> The offb driver takes precedence over module radeonfb. It is then
>> >> >> >> impossible to load the module, error reported is:
>> >> >> >>
>> >> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> >> >> >> 0x9800-0x9fff pref]
>> >> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> >> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >> >> >>
>> >> >> >> This patch reproduce the behavior of the module radeon, so as to 
>> >> >> >> make it
>> >> >> >> possible to load radeonfb when offb is first loaded.
>> >> >> >>
>> >> >> >> It should be noticed that `offb_destroy` is never called which 
>> >> >> >> explain the
>> >> >> >> need to skip error detection on the radeon side.
>> >> >> >
>> >> >> > This still needs to be explained more, from my last mail:
>> >> >> >
>> >> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
>> >> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
>> >> >> > is calling put_fb_info() so there is some extra reference on
>> >> >> > fb_info somewhere preventing it from going away.
>> >> >> >
>> >> >> > Please look into fixing this."
>> >> >>
>> >> >> I am not familiar with the fb stuff internals but here is what I see:
>> >> >>
>> >> >> # modprobe radeonfb
>> >> >>
>> >> >> leads to:
>> >> >>
>> >> >> [   52.058546] bus: 'pci': add driver radeonfb
>> >> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
>> >> >> :00:10.0 with driver radeonfb
>> >> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
>> >> >> device :00:10.0
>> >> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
>> >> >> [   52.058613] radeonfb_pci_register BEGIN
>> >> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> 
>> >> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 
>> >> >> 800)
>> >> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
>> >> >> [   52.058844] Console: switching to colour dummy device 80x25
>> >> >> [   52.058860] device: 'fb0': device_unregister
>> >> >> [   52.058956] PM: Removing info for No Bus:fb0
>> >> >> [   52.059014] device: 'fb0': device_create_release
>> >> >> 
>> >> >> 
>> >> >> [   52.059048] device: 'vtcon1': device_unregister
>> >> >> [   52.059076] PM: Removing info for No Bus:vtcon1
>> >> >> [   52.059091] device: 'vtcon1': device_create_release
>> >> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> >> >> 0x9800-0x9fff pref]
>> >> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
>> >> >> to: a000
>> >> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
>> >> >> wide videoram
>> >> >>
>> >> >> I can confirm that offb_destroy is never called (not sure exactly
>> >> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
>> >> >> much earlier, at least before the put_fb_info.
>> >> >
>> >> > It is okay, put_fb_info() is called indirectly by 
>> >> > radeon_kick_out_firmware_fb()
>> >> >
>> >> > radeon_kick_out_firmware_fb()
>> >> > remove_conflicting_framebuffers()
>> >> > do_remove_conflicting_framebuffers()
>> >> > do_unregister_framebuffer()
>> >> > put_fb_info()
>> >> >
>> >> > offb_destroy() is not called because there is an extra reference on old
>> >> > fb_info (->count == 2):
>> >> >
>> >> > static void put_fb_info(struct fb_info *fb_info)
>> >> > {
>> >> > if (!atomic_dec_and_test(_info->count))
>> >> > return;
>> >> > if (fb_info->fbops->fb_destroy)
>> >> > fb_info->fbops->fb_destroy(fb_info);
>> >> > }
>> >> >
>> >> > The question is why there is an extra reference, probably user-space
>> >> > is still holding the fb_info reference 

Question about lima kernel MM implementation

[Qiang Yu]

Hi guys,

I'm working on the Lima project for ARM mali400/450 GPU. Now lima
kernel driver uses CMA for all buffers, but mali400/450 GPU has MMU
for each vertex/fragment shader processor, so I want to refine the lima
kernel driver for non-contiguous memory support.

After some investigation on current available MM method used by
several linux kernel DRM driver, I can't find an exactly match one for
lima. So I'd like to hear some advise from you and see if I have some
miss understanding on current MMs and if there's better approach.
If can't use existing MM, I may have to write one for lima.

About Mali400/450 GPU:
1. it has separate vertex and fragment shader processors, 1 vertex
processor and 1~4 fragment processors are grouped to process an
OpenGL draw
2. each processor has an MMU work independently
3. Mali400/450 will work with different display DRM driver, some
display DRM driver support non-contiguous framebuffer and some
not

My requirement:
1. support non-contiguous memory allocation as GPU buffer
2. support contiguous memory allocation too for exporting to some
display DRM driver as framebuffer
3. no GPU page fault for better performance and avoid multi MMU
page fault handling, CPU page fault is OK
4. better have buffer swap to disk feature when memory is full

Current MM:
1. drm_gem_cma_object, only support contiguous memory
2. drm_gem_get_pages
  1) need to combine with cma method for contiguous memory
  2) when shrink is needed, swap some idle buffer to disk and put
  pages, need implement by myself
  3) additional shmem layer introduced
3. TTM TTM_PL_SYSTEM only
  1) no contiguous memory support
  2) too complicated as we don't need other functions of TTM
  3) need GPU page fault to populate memory?
  4) no page pool for cached memory

My plan:
1. for contiguous memory allocation use dma_alloc_*
2. for non-contiguous memory allocation, use a page pool from
alloc_page
3. buffer is not really allocated when GEM_CREATE, but in CPU
page fault handler and task submit buffer validation which make
sure no GPU page fault
4. in shrinker handler, free un-used page in the pool, if still not
enough, swap some idle buffer to disk

3&4 apply to both dma_alloc buffer and alloc_page buffer.

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

Re: [drm-nouveau-mmu] question about potential NULL pointer dereference

[Gustavo A. R. Silva]

Quoting Ben Skeggs :


On Wed, Feb 14, 2018 at 1:40 AM, Gustavo A. R. Silva
 wrote:


Hi all,

While doing some static analysis I ran into the following piece of code at
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:957:

 957#define node(root, dir) ((root)->head.dir == >list) ? NULL :
\
 958list_entry((root)->head.dir, struct nvkm_vma, head)
 959
 960void
 961nvkm_vmm_unmap_region(struct nvkm_vmm *vmm, struct nvkm_vma *vma)
 962{
 963struct nvkm_vma *next;
 964
 965nvkm_memory_tags_put(vma->memory, vmm->mmu->subdev.device,
>tags);
 966nvkm_memory_unref(>memory);
 967
 968if (vma->part) {
 969struct nvkm_vma *prev = node(vma, prev);
 970if (!prev->memory) {
 971prev->size += vma->size;
 972rb_erase(>tree, >root);
 973list_del(>head);
 974kfree(vma);
 975vma = prev;
 976}
 977}
 978
 979next = node(vma, next);
 980if (next && next->part) {
 981if (!next->memory) {
 982vma->size += next->size;
 983rb_erase(>tree, >root);
 984list_del(>head);
 985kfree(next);
 986}
 987}
 988}

The issue here is that in case _node_ returns NULL, _prev_ is not being null
checked, hence there is a potential null pointer dereference at line 970.

Notice that _next_ is being null checked at line 980, so I wonder if _prev_
should be checked the same as _next_.

The fact that both _next_ and next->part are null checked, makes me wonder
if in case _prev_ actually needs to be checked, there is another pointer
contained into _prev_ to be validated as well? I'm sorry, this is not clear
to me at this moment.

It's not checked because it can't happen.  If vma->part is set, there
will be a previous node that it was split from.



I got it.

Thanks, Ben.
--
Gustavo






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

[PATCH v5 1/3] drm/i915: Add intel_bios_cleanup() function

[Hans de Goede]

Add an intel_bios_cleanup() function to act as counterpart of
intel_bios_init() and move the cleanup of vbt related resources there,
putting it in the same file as the allocation.

Changed in v2:
-While touching the code anyways, remove the unnecessary:
 if (dev_priv->vbt.child_dev) done before kfree(dev_priv->vbt.child_dev)

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.c   | 14 +-
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 15 +++
 3 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9380c9f69b0f..a9931b8ec0b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1448,19 +1448,7 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_modeset_cleanup(dev);
 
-   /*
-* free the memory space allocated for the child device
-* config parsed from VBT
-*/
-   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
-   kfree(dev_priv->vbt.child_dev);
-   dev_priv->vbt.child_dev = NULL;
-   dev_priv->vbt.child_dev_num = 0;
-   }
-   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
-   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
-   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
-   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   intel_bios_cleanup(dev_priv);
 
vga_switcheroo_unregister_client(pdev);
vga_client_register(pdev, NULL, NULL, NULL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c06d4126c447..ea71a2a6fc18 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3680,6 +3680,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
 
 /* intel_bios.c */
 void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
 bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
 bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index aa4df6548771..ea1ed84a1e7d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1610,6 +1610,21 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
 }
 
+/**
+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   kfree(dev_priv->vbt.child_dev);
+   dev_priv->vbt.child_dev = NULL;
+   dev_priv->vbt.child_dev_num = 0;
+   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
+   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
+   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+}
+
 /**
  * intel_bios_is_tv_present - is integrated TV present in VBT
  * @dev_priv:  i915 device instance
-- 
2.14.3

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

[drm-nouveau-mmu] question about potential NULL pointer dereference

[Gustavo A. R. Silva]

Hi all,

While doing some static analysis I ran into the following piece of  
code at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:957:


 957#define node(root, dir) ((root)->head.dir == >list) ? NULL :  
 \

 958list_entry((root)->head.dir, struct nvkm_vma, head)
 959
 960void
 961nvkm_vmm_unmap_region(struct nvkm_vmm *vmm, struct nvkm_vma *vma)
 962{
 963struct nvkm_vma *next;
 964
 965nvkm_memory_tags_put(vma->memory,  
vmm->mmu->subdev.device, >tags);

 966nvkm_memory_unref(>memory);
 967
 968if (vma->part) {
 969struct nvkm_vma *prev = node(vma, prev);
 970if (!prev->memory) {
 971prev->size += vma->size;
 972rb_erase(>tree, >root);
 973list_del(>head);
 974kfree(vma);
 975vma = prev;
 976}
 977}
 978
 979next = node(vma, next);
 980if (next && next->part) {
 981if (!next->memory) {
 982vma->size += next->size;
 983rb_erase(>tree, >root);
 984list_del(>head);
 985kfree(next);
 986}
 987}
 988}

The issue here is that in case _node_ returns NULL, _prev_ is not  
being null checked, hence there is a potential null pointer  
dereference at line 970.


Notice that _next_ is being null checked at line 980, so I wonder if  
_prev_ should be checked the same as _next_.


The fact that both _next_ and next->part are null checked, makes me  
wonder if in case _prev_ actually needs to be checked, there is  
another pointer contained into _prev_ to be validated as well? I'm  
sorry, this is not clear to me at this moment.


I appreciate your feedback
Thank you
--
Gustavo






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

Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Vivek Gautam]

On Tue, Feb 13, 2018 at 7:22 PM, Tomasz Figa  wrote:
> On Tue, Feb 13, 2018 at 9:57 PM, Robin Murphy  wrote:
>> On 13/02/18 08:24, Tomasz Figa wrote:
>>>
>>> Hi Vivek,
>>>
>>> Thanks for the patch. Please see my comments inline.
>>>
>>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>>>  wrote:

 From: Sricharan R 

 The smmu device probe/remove and add/remove master device callbacks
 gets called when the smmu is not linked to its master, that is without
 the context of the master device. So calling runtime apis in those places
 separately.

 Signed-off-by: Sricharan R 
 [vivek: Cleanup pm runtime calls]
 Signed-off-by: Vivek Gautam 
 ---
   drivers/iommu/arm-smmu.c | 42
 ++
   1 file changed, 38 insertions(+), 4 deletions(-)

 diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
 index 9e2f917e16c2..c024f69c1682 100644
 --- a/drivers/iommu/arm-smmu.c
 +++ b/drivers/iommu/arm-smmu.c
 @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct
 iommu_domain *domain)
  struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
  struct arm_smmu_device *smmu = smmu_domain->smmu;
  struct arm_smmu_cfg *cfg = _domain->cfg;
 -   int irq;
 +   int ret, irq;

  if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
  return;

 +   ret = pm_runtime_get_sync(smmu->dev);
 +   if (ret)
 +   return;
>>>
>>>
>>> pm_runtime_get_sync() will return 0 if the device was powered off, 1
>>> if it was already/still powered on or runtime PM is not compiled in,
>>> or a negative value on error, so shouldn't the test be (ret < 0)?
>>>
>>> Moreover, I'm actually wondering if it makes any sense to power up the
>>> hardware just to program it and power it down again. In a system where
>>> the IOMMU is located within a power domain, it would cause the IOMMU
>>> block to lose its state anyway.
>>
>>
>> This is generally for the case where the SMMU internal state remains active,
>> but the programming interface needs to be powered up in order to access it.
>
> That's true for Qualcomm SMMU, but I think that would be different for
> existing users of the driver?
>
>>
>>> Actually, reflecting back on "[PATCH v7 2/6] iommu/arm-smmu: Add
>>> pm_runtime/sleep ops", perhaps it would make more sense to just
>>> control the clocks independently of runtime PM? Then, runtime PM could
>>> be used for real power management, e.g. really powering the block up
>>> and down, for further power saving.
>>
>>
>> Unfortunately that ends up pretty much unmanageable, because there are
>> numerous different SMMU microarchitectures with fundamentally different
>> clock/power domain schemes (multiplied by individual SoC integration
>> possibilities). Since this is fundamentally a generic architectural driver,
>> adding explicit clock support would probably make the whole thing about 50%
>> clock code, with complicated decision trees around every hardware access
>> calculating which clocks are necessary for a given operation on a given
>> system. That maintainability aspect is why we've already nacked such a
>> fine-grained approach in the past.
>
> Hmm, I think we are talking about different things here. My suggestion
> would not add much more code to the driver than this patch does, calls
> to arm_smmu_enable_clocks() instead of pm_runtime_get_sync() and
> arm_smmu_disable_clocks() instead of pm_runtime_put(). The
> implementation of both functions would be a simple call to clk_bulk_
> API (possibly even no need to put this into functions, just call
> directly).

Well, things are not so straight on msm. The IP clocks on msm are usually
powered by (or i should rather say, controlled by) the same power domain
that provides the VDD supply to iommu block. This is the behavior on msm8996
atleast that we are testing on right now.
On later SoCs too things don't change drastically.

So, you can't have the block in low power state until you program the
register space
and then power on the block to let it do its magic.
Clocks and power domains are linked, and that's why we add them to the
pm callbacks.

This approach also looks generic to me since the platforms will either have such
a link or they will not have. But, in either case you will have power and clocks
available at the time when you need them.


Thanks & regards
Vivek

>
> Best regards,
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora 

Re: [PATCH v7 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

[Vivek Gautam]

Hi Tomasz,


Please find my response inline below.

On Tue, Feb 13, 2018 at 1:33 PM, Tomasz Figa  wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see some comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>  wrote:
>> From: Sricharan R 
>>
>> The smmu needs to be functional only when the respective
>> master's using it are active. The device_link feature
>> helps to track such functional dependencies, so that the
>> iommu gets powered when the master device enables itself
>> using pm_runtime. So by adapting the smmu driver for
>> runtime pm, above said dependency can be addressed.
>>
>> This patch adds the pm runtime/sleep callbacks to the
>> driver and also the functions to parse the smmu clocks
>> from DT and enable them in resume/suspend.
>>
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Archit Taneja 
>> [vivek: Clock rework to request bulk of clocks]
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/iommu/arm-smmu.c | 56 
>> ++--
>>  1 file changed, 54 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 69e7c60792a8..9e2f917e16c2 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -48,6 +48,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -205,6 +206,8 @@ struct arm_smmu_device {
>> u32 num_global_irqs;
>> u32 num_context_irqs;
>> unsigned int*irqs;
>> +   struct clk_bulk_data*clocks;
>> +   int num_clks;
>
> nit: Perhaps "num_clocks" to be consistent with "clocks"?
>
>>
>> u32 cavium_id_base; /* Specific to 
>> Cavium */
>>
>> @@ -1897,10 +1900,12 @@ static int arm_smmu_device_cfg_probe(struct 
>> arm_smmu_device *smmu)
>>  struct arm_smmu_match_data {
>> enum arm_smmu_arch_version version;
>> enum arm_smmu_implementation model;
>> +   const char * const *clks;
>> +   int num_clks;
>
> nit: Perhaps s/clks/clocks/ here or s/clocks/clks/ in struct arm_smmu_device?

Sure. Will change to s/clocks/clks/ in struct arm_smmu_device.

>
>>  };
>>
>>  #define ARM_SMMU_MATCH_DATA(name, ver, imp)\
>> -static struct arm_smmu_match_data name = { .version = ver, .model = imp }
>> +static const struct arm_smmu_match_data name = { .version = ver, .model = 
>> imp }
>>
>>  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
>>  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
>> @@ -2001,6 +2006,7 @@ static int arm_smmu_device_dt_probe(struct 
>> platform_device *pdev,
>> data = of_device_get_match_data(dev);
>> smmu->version = data->version;
>> smmu->model = data->model;
>> +   smmu->num_clks = data->num_clks;
>>
>> parse_driver_options(smmu);
>>
>> @@ -2039,6 +2045,28 @@ static void arm_smmu_bus_init(void)
>>  #endif
>>  }
>>
>> +static int arm_smmu_init_clks(struct arm_smmu_device *smmu)
>> +{
>> +   int i;
>> +   int num = smmu->num_clks;
>> +   const struct arm_smmu_match_data *data;
>> +
>> +   if (num < 1)
>> +   return 0;
>> +
>> +   smmu->clocks = devm_kcalloc(smmu->dev, num,
>> +   sizeof(*smmu->clocks), GFP_KERNEL);
>> +   if (!smmu->clocks)
>> +   return -ENOMEM;
>> +
>> +   data = of_device_get_match_data(smmu->dev);
>> +
>> +   for (i = 0; i < num; i++)
>> +   smmu->clocks[i].id = data->clks[i];
>
> I'd argue that arm_smmu_device_dt_probe() is a better place for all
> the code above, since this function is called regardless of whether
> the device is probed from DT or not. Going further,
> arm_smmu_device_acpi_probe() could fill smmu->num_clks and ->clocks
> using ACPI-like way (as opposed to OF match data) if necessary.

Right, it's valid to fill the data in arm_smmu_device_dt_probe().
Perhaps we can just keep the devm_clk_bulk_get() in arm_smmu_device_probe()
at the point where we are currently doing arm_smmu_init_clks().

Thanks & regards
Vivek

>
> Best regards,
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: offb: Deallocate the color map

[Mathieu Malaterre]

The function offb_destroy did not deallocate the color map leaving some
memory around after destruction. Call the color map deallocate function to
remove the memory leak.

Handle another case where color map should have been deallocated during an
error code path.

Fix memory leaks reported by kmemleak:

# dmesg
...
[ 1884.719941] kmemleak: 3 new suspected memory leaks (see 
/sys/kernel/debug/kmemleak)
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xde3d9000 (size 512):
  comm "swapper", pid 1, jiffies 4294892827 (age 1906.784s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa  
55 55 55 55 55 55 55 55 ff ff ff ff ff ff ff ff  
  backtrace:
[] fb_alloc_cmap_gfp+0x54/0x15c
[] offb_init_nodriver+0x8e8/0xa3c
[] offb_init+0xd0/0x164
[<322f82a3>] do_one_initcall+0x4c/0x178
[] kernel_init_freeable+0x138/0x1cc
[<2a17fa0e>] kernel_init+0x24/0x118
[<4079749a>] ret_from_kernel_thread+0x5c/0x64
unreferenced object 0xde3d9200 (size 512):
  comm "swapper", pid 1, jiffies 4294892827 (age 1906.784s)
  hex dump (first 32 bytes):
00 00 00 00 aa aa aa aa 00 00 00 00 55 55 aa aa  UU..
55 55 55 55 ff ff ff ff 55 55 55 55 ff ff ff ff  
  backtrace:
[<4bf3594d>] fb_alloc_cmap_gfp+0x6c/0x15c
[] offb_init_nodriver+0x8e8/0xa3c
[] offb_init+0xd0/0x164
[<322f82a3>] do_one_initcall+0x4c/0x178
[] kernel_init_freeable+0x138/0x1cc
[<2a17fa0e>] kernel_init+0x24/0x118
[<4079749a>] ret_from_kernel_thread+0x5c/0x64
unreferenced object 0xde3d9600 (size 512):
  comm "swapper", pid 1, jiffies 4294892827 (age 1906.784s)
  hex dump (first 32 bytes):
00 00 aa aa 00 00 aa aa 00 00 aa aa 00 00 aa aa  
55 55 ff ff 55 55 ff ff 55 55 ff ff 55 55 ff ff  UU..UU..UU..UU..
  backtrace:
[<23a3ea03>] fb_alloc_cmap_gfp+0x84/0x15c
[] offb_init_nodriver+0x8e8/0xa3c
[] offb_init+0xd0/0x164
[<322f82a3>] do_one_initcall+0x4c/0x178
[] kernel_init_freeable+0x138/0x1cc
[<2a17fa0e>] kernel_init+0x24/0x118
[<4079749a>] ret_from_kernel_thread+0x5c/0x64

Signed-off-by: Mathieu Malaterre 
---
 drivers/video/fbdev/offb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 6f65d132eba1..30786445de04 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -282,6 +282,7 @@ static void offb_destroy(struct fb_info *info)
if (info->screen_base)
iounmap(info->screen_base);
release_mem_region(info->apertures->ranges[0].base, 
info->apertures->ranges[0].size);
+   fb_dealloc_cmap(>cmap);
framebuffer_release(info);
 }
 
@@ -520,6 +521,7 @@ static void __init offb_init_fb(const char *name,
return;
 
 out_err:
+   fb_dealloc_cmap(>cmap);
iounmap(info->screen_base);
 out_aper:
iounmap(par->cmap_adr);
-- 
2.11.0

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

[PULL] drm-intel-next

[Joonas Lahtinen]

Hi Dave,

CI has been really effective in catching problems before users have reported
them to us. All Bugzillas closed from this tag are from our CI reports!

Due to FOSDEM prep and travel, there's quite a hunk of patches, I've tried
to highlight the ones with most impact on the top.

Regards, Joonas

The following changes since commit 559f17bec508548850654dd04525fd69d90f6d4e:

  Merge tag 'drm-misc-next-fixes-2018-01-18' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-01-25 11:42:25 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-02-07

for you to fetch changes up to 2f2f2db86d63605b1f57780ead21d4968e9d0bf3:

  drm/i915: Update DRIVER_DATE to 20180207 (2018-02-07 09:26:04 +0200)


UAPI Changes:

- Userspace whitelist register GEN9_SLICE_COMMON_ECO_CHICKEN1 for GLK (Kenneth)
- Non-existent PMU counters are not placed to sysfs (Tvrtko)
- Add a note to deprecate I915_SET_COLORKEY_NONE and ignore it (Ville)
* Intel DDX never ended using it, and implementation was wonky

Core Changes:

- Moved away from struct timeval into ktime_t in prep for 2038 (Arnd)
* Merged the i915 portion through drm-tip, no core dependencies

Driver Changes:

- Base support for Icelake and Icelake PCH (Anusha, Rodrigo, Mahesh, Paulo, 
James, Kelvin)
- Add AUX-F port support for Cannonlake (Rodrigo)
- New DMC firmware for 1.07 Cannonlake (Anusha)
* Go to linux-firmware.git to get it
- Reject non-cursor planes nearly (3 px) out of screen on GLK/CNL (Imre)
- Y/Yf modifiers restored for SKL+ sprites (Ville)
- Compressed framebuffer support for sprites (Ville)
- Tune down overly aggressive shrinking (Chris)
- Shrink kmem caches when GPU is idle (Chris)
- EDID bit-banging fallback for HDMI EDID (Stefan)
- Don't boost the GPU when the waited request is already running (Chris)
- Avoid GLK/BXT CDCLK frequency locking timeouts (Imre)
- Limit DP link rate according to VBT on CNL+ (Jani)
- Skip post-reset request emission if the engine is not idle (Chris)
- Report any link training error on a fixed eDP panel as errors (Manasi)
- DSI panel fixes for Bay Trail (Hans)
- Selftest additions and improvements (Chris, Matt)
- DMA fence test additions and accompanying fixes (Chris)
- Power domain vs. register access fix (Maarten)
- Squelch warnings for people with teensy framebuffers (stride < 512) (Maarten)
- Increase Render/Media power gating hysteresis for Gen9+ (Chris)
- HDMI vswing display workaround for Gen9+ (Ville)
- GuC code cleanup and lockdep fixes (Sagar, Michal Wa.)
- Continuously run hangcheck for simplicity (Chris)
- Execlist debugging improvements (Chris)
- GuC debugging improvements (Sujaritha, Michal Wa., Sagar)
- Command parser boundary checks (Michal Srb)
- Add a workaround for 3DSTATE_SAMPLE_PATTERN on CNL (Rafael)
- Fix PMU enabling race condition (Tvrtko)
- Usual smaller testing and debugging improvements


Abdiel Janulgue (1):
  drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set

Anusha Srivatsa (8):
  drm/i915/glk: Disable Guc and HuC on GLK
  drm/i915/dmc: DMC 1.07 for Cannonlake
  drm/i915/icp: Introduce Ice Lake PCH
  drm/i915/icp: Get/set proper Raw clock frequency on ICP
  drm/i915/icp: Add Panel Power Sequencing Support
  drm/i915/icp: Add backlight Support for ICP
  drm/i915/icp: add ICP gmbus and gpio support
  drm/i915/icp: Add the ID for ICL PCH - ICP

Arnd Bergmann (1):
  drm: i915: remove timeval users

C, Ramalingam (2):
  drm/i915: Runtime disable for eDP DRRS
  i915/drrs/debugfs: psr status info addition

Chris Wilson (51):
  drm/i915/selftests: Tweak igt_ggtt_page to speed it up
  drm/i915/selftests: Allow random array allocation to fail
  drm/i915: Delete defunct i915_gem_request_assign()
  drm/i915/execlists: Clear context-switch interrupt earlier in the reset
  drm/i915/execlists: Record elsp offset during engine setup
  drm/i915/execlists: Tidy enabling execlists
  drm/i915: Hold rpm wakeref for modifying the global seqno
  drm/i915: Assert all signalers we depended on did indeed signal
  drm/i915/execlists: Assert there are no simple cycles in the dependencies
  drm/i915/execlists: Reduce list_for_each_safe+list_safe_reset_next
  drm/i915: Assert we do not try to wait on an invalid seqno
  drm/i915: Pass DMA_ATTR_NO_WARN to dma_map_sg()
  drm/i915: Don't adjust priority on an already signaled fence
  drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep
  drm/i915/pmu: Reconstruct active state on starting busy-stats
  drm/i915: Only defer freeing of fence callback when also using the timer
  drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences
  drm/i915: Lock out execlist tasklet while peeking 

Re: [PATCH v4 1/3] drm/i915: Add intel_bios_cleanup() function

[Hans de Goede]

Hi,

On 12-02-18 20:45, Ville Syrjälä wrote:

On Tue, Feb 06, 2018 at 03:12:37PM +0100, Hans de Goede wrote:

Add an intel_bios_cleanup() function to act as counterpart of
intel_bios_init() and move the cleanup of vbt related resources there,
putting it in the same file as the allocation.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/i915_drv.c   | 14 +-
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_bios.c | 21 +
  3 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9f1daf258fe..7f094bbc2a7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1446,19 +1446,7 @@ void i915_driver_unload(struct drm_device *dev)
  
  	intel_modeset_cleanup(dev);
  
-	/*

-* free the memory space allocated for the child device
-* config parsed from VBT
-*/
-   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
-   kfree(dev_priv->vbt.child_dev);
-   dev_priv->vbt.child_dev = NULL;
-   dev_priv->vbt.child_dev_num = 0;
-   }
-   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
-   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
-   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
-   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   intel_bios_cleanup(dev_priv);
  
  	vga_switcheroo_unregister_client(pdev);

vga_client_register(pdev, NULL, NULL, NULL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6b5ac2a563d..1cccea1b87bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3675,6 +3675,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
  
  /* intel_bios.c */

  void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 4e74aa2f16bc..f9550507bb9f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1610,6 +1610,27 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
  }
  
+/**

+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   /*
+* free the memory space allocated for the child device
+* config parsed from VBT
+*/
+   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {


The comment and if() seem pointless. IMO just drop them.


Ok I will send out a new version of the series with a v2 of
this patch with this fixed (for patchwork / CI) and when CI is
happy with this, push the series.

> With that
> Reviewed-by: Ville Syrjälä 

Thanks & Regards,

Hans






+   kfree(dev_priv->vbt.child_dev);
+   dev_priv->vbt.child_dev = NULL;
+   dev_priv->vbt.child_dev_num = 0;
+   }
+   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
+   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
+   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+}
+
  /**
   * intel_bios_is_tv_present - is integrated TV present in VBT
   * @dev_priv: i915 device instance
--
2.14.3



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

Re: [PULL] drm/i915: Add HDCP support to i915

[Hans Verkuil]

Hi Sean,

On 13/02/18 21:18, Sean Paul wrote:
> 
> Hi Dave,
> Here's the pull request for HDCP. Hopefully no surprises since it's been 
> baking
> in drm-tip for a while now.
> 
> topic/hdcp-2018-02-13:
> Add HDCP support to i915 drm driver.
> 
> Cheers, Sean
> 
> 
> The following changes since commit b0caa1333b6d2d928a00304e9fb6674526c37b79:
> 
>   Merge tag 'imx-drm-next-2018-01-02' of 
> git://git.pengutronix.de/git/pza/linux into drm-next (2018-01-05 11:33:24 
> +1000)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13
> 
> for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289:
> 
>   drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 -0500)
> 
> 
> Add HDCP support to i915 drm driver.
> 
> 
> Chris Wilson (1):
>   drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
> 
> Ramalingam C (12):
>   drm/i915: Extending HDCP for HSW, BDW and BXT+
>   drm/i915: II stage HDCP auth for repeater only
>   drm/i915: Start repeater auth on READY/CP_IRQ
>   drm/i915: Check for downstream topology errors
>   drm/i915: Handle failure from 2nd stage HDCP auth
>   drm/i915: Stop encryption for repeater with no sink
>   drm/i915: Connector info in HDCP debug msgs
>   drm/i915: Retry HDCP bksv read
>   drm/i915: Optimize HDCP key load
>   drm/i915: Detect panel's hdcp capability
>   drm/i915: Reauthenticate HDCP on failure
>   drm/i915: fix misalignment in HDCP register def

Were these ever posted to dri-devel? I can't find them there.

Do these patches from Ramalingam C add repeater support to the i915?
If so, then I am certainly interested in seeing these since we (Cisco)
are working on HDCP (including repeater support) for HDMI receivers.

Nothing public yet, it's too early for that. But it would be nice to
test with the i915 driver.

Regards,

Hans

> 
> Sean Paul (13):
>   drm: Fix link-status kerneldoc line lengths
>   drm/i915: Add more control to wait_for routines
>   drm: Add Content Protection property
>   drm: Add some HDCP related #defines
>   drm/i915: Add HDCP framework + base implementation
>   drm/i915: Make use of indexed write GMBUS feature
>   drm/i915: Add function to output Aksv over GMBUS
>   drm/i915: Implement HDCP for HDMI
>   drm/i915: Implement HDCP for DisplayPort
>   drm/i915: Don't allow HDCP on PORT E/F
>   drm/i915: Only disable HDCP when it's active
>   drm/i915: Restore HDCP DRM_INFO when with no downstream
>   drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS
> 
>  drivers/gpu/drm/drm_atomic.c |   8 +
>  drivers/gpu/drm/drm_connector.c  |  87 +++-
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  86 
>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
>  drivers/gpu/drm/i915/intel_ddi.c |  36 ++
>  drivers/gpu/drm/i915/intel_display.c |   4 +
>  drivers/gpu/drm/i915/intel_dp.c  | 277 +++-
>  drivers/gpu/drm/i915/intel_drv.h | 109 -
>  drivers/gpu/drm/i915/intel_hdcp.c| 807 
> +++
>  drivers/gpu/drm/i915/intel_hdmi.c| 250 +++
>  drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
>  drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
>  drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
>  include/drm/drm_connector.h  |  16 +
>  include/drm/drm_dp_helper.h  |  17 +
>  include/drm/drm_hdcp.h   |  41 ++
>  include/uapi/drm/drm_mode.h  |   4 +
>  19 files changed, 1821 insertions(+), 43 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>  create mode 100644 include/drm/drm_hdcp.h
> 

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

[Bug 105089] radeonsi GPU lockup / crash with wine [The Witcher 3]

[bugzilla-daemon]

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

--- Comment #1 from galym  ---
Created attachment 137350
  --> https://bugs.freedesktop.org/attachment.cgi?id=137350=edit
dmesg log

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

[PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

[Anusha Srivatsa]

Forward Error Correction is supported on DP 1.4.
This patch adds corresponding DPCD register definitions.

v2: Add dri-devel mailing list to the CC list(Jani)

v3: Change names, add missing masks (Manasi)

v4: Add missing shifts to mask (Manasi)

v5: Arrange the definitions in ascending order
of the address (Jani)

Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 include/drm/drm_dp_helper.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c239e6e..a19d6fb 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -329,6 +329,13 @@
 # define DP_DS_12BPC   2
 # define DP_DS_16BPC   3
 
+/* DP Forward error Correction Registers */
+#define DP_FEC_CAPABILITY  (0x090)
+# define DP_FEC_CAPABLE(1 << 0)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
+# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */
@@ -445,6 +452,18 @@
 #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118   /* 1.2 */
 # define DP_PWR_NOT_NEEDED (1 << 0)
 
+#define DP_FEC_CONFIGURATION   0x120
+# define DP_FEC_READY  (1 << 0)
+# define DP_FEC_ERR_COUNT_DIS  (0 << 1)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT   (2 << 1)
+# define DP_FEC_BIT_ERROR_COUNT(3 << 1)
+# define DP_FEC_ERR_COUNT_SEL_MASK (0xff << 4)
+# define DP_FEC_LANE_0_SELECT  (0 << 4)
+# define DP_FEC_LANE_1_SELECT  (1 << 4)
+# define DP_FEC_LANE_2_SELECT  (2 << 4)
+# define DP_FEC_LANE_3_SELECT  (3 << 4)
+
 #define DP_AUX_FRAME_SYNC_VALUE0x15c   /* eDP 1.4 */
 # define DP_AUX_FRAME_SYNC_VALID   (1 << 0)
 
@@ -620,6 +639,17 @@
 #define DP_TEST_SINK   0x270
 # define DP_TEST_SINK_START(1 << 0)
 
+#define DP_FEC_STATUS  0x280
+# define DP_FEC_DECODE_EN_DETECTED (1 << 0)
+# define DP_FEC_DECODE_DIS_DETECTED(1 << 1)
+
+#define DP_FEC_ERROR_COUNT_LSB 0x0281
+
+#define DP_FEC_ERROR_COUNT_MSB 0x0282
+# define DP_FEC_ERROR_COUNT_MASK   0x7F
+# define DP_FEC_ERR_COUNT_SHIFT8
+# define DP_FEC_ERR_COUNT_VALID(1 << 7)
+
 #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
 # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
 # define DP_PAYLOAD_ACT_HANDLED (1 << 1)
-- 
2.7.4

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

Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Vivek Gautam]

Hi Tomasz,


On Tue, Feb 13, 2018 at 1:54 PM, Tomasz Figa  wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>  wrote:
>> From: Sricharan R 
>>
>> The smmu device probe/remove and add/remove master device callbacks
>> gets called when the smmu is not linked to its master, that is without
>> the context of the master device. So calling runtime apis in those places
>> separately.
>>
>> Signed-off-by: Sricharan R 
>> [vivek: Cleanup pm runtime calls]
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/iommu/arm-smmu.c | 42 ++
>>  1 file changed, 38 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 9e2f917e16c2..c024f69c1682 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct 
>> iommu_domain *domain)
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> struct arm_smmu_device *smmu = smmu_domain->smmu;
>> struct arm_smmu_cfg *cfg = _domain->cfg;
>> -   int irq;
>> +   int ret, irq;
>>
>> if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
>> return;
>>
>> +   ret = pm_runtime_get_sync(smmu->dev);
>> +   if (ret)
>> +   return;
>
> pm_runtime_get_sync() will return 0 if the device was powered off, 1
> if it was already/still powered on or runtime PM is not compiled in,
> or a negative value on error, so shouldn't the test be (ret < 0)?

Yes, I too noticed it while i was testing on a different platform, and
was hitting
a failure case. Will update at all places.

>
> Moreover, I'm actually wondering if it makes any sense to power up the
> hardware just to program it and power it down again. In a system where
> the IOMMU is located within a power domain, it would cause the IOMMU
> block to lose its state anyway.
>
> Actually, reflecting back on "[PATCH v7 2/6] iommu/arm-smmu: Add
> pm_runtime/sleep ops", perhaps it would make more sense to just
> control the clocks independently of runtime PM? Then, runtime PM could
> be used for real power management, e.g. really powering the block up
> and down, for further power saving.
>
> +Generally similar comments for other places in this patch.
>
>> +
>> /*
>>  * Disable the context bank and free the page tables before freeing
>>  * it.
>> @@ -932,6 +936,8 @@ static void arm_smmu_destroy_domain_context(struct 
>> iommu_domain *domain)
>>
>> free_io_pgtable_ops(smmu_domain->pgtbl_ops);
>> __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
>> +
>> +   pm_runtime_put_sync(smmu->dev);
>
> Is there any point in the put being sync here?

No, I don't think. Can manage with just a 'put' here. Will modify.

best regards
Vivek

>
> [snip]
>
>> @@ -2131,6 +2152,14 @@ static int arm_smmu_device_probe(struct 
>> platform_device *pdev)
>> if (err)
>> return err;
>>
>> +   platform_set_drvdata(pdev, smmu);
>> +
>> +   pm_runtime_enable(dev);
>
> I suspect this may be a disaster for systems where IOMMUs are located
> inside power domains, because the driver doesn't take care of the
> IOMMU block losing its state on physical power down, as I mentioned in
> my comments above.
>
> Best regards,
> Tomasz



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: fbdev: kconfig: Add help text to FB_I810_I2C

[Ulf Magnusson]

The FB_I810_I2C symbol previously had a blank help text, which was
removed in e9829ac4e5fd ("video: fbdev: kconfig: Remove blank help
text").

Give it a proper help text, derived from commit 74f6ae84b23 ("[PATCH]
i810fb: Add > i2c/DDC support").

Signed-off-by: Ulf Magnusson 
---
Note: The removal of the blank help text is already in Linus' tree.

 drivers/video/fbdev/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 11e699f1062b..c691f1489bb7 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1156,6 +1156,11 @@ config FB_I810_I2C
bool "Enable DDC Support"
depends on FB_I810 && FB_I810_GTF
select FB_DDC
+   help
+ Add DDC/I2C support for i810fb.  This will allow the driver to get
+ display information, especially for monitors with fickle timings.
+
+ If unsure, say Y.
 
 config FB_LE80578
tristate "Intel LE80578 (Vermilion) support"
-- 
2.14.1

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

[PATCH v5 3/3] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

[Hans de Goede]

So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.

The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.

Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().

This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.

Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
 OTP sequence, instead of calling it earlier and then having the first
 mipi_exec_send_packet() call call intel_dsi_device_ready().

Changes in v3:
-Move the whole shebang to intel_bios.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82880
References: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer 
Reported-by: Jan-Michael Brummer 
Tested-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 84 +++
 2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea71a2a6fc18..c7e17e20fceb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1359,6 +1359,7 @@ struct intel_vbt_data {
u32 size;
u8 *data;
const u8 *sequence[MIPI_SEQ_MAX];
+   u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
} dsi;
 
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 92e52bb65c41..c5c7530ba157 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -947,6 +947,86 @@ static int goto_next_sequence_v3(const u8 *data, int 
index, int total)
return 0;
 }
 
+/*
+ * Get len of pre-fixed deassert fragment from a v1 init OTP sequence,
+ * skip all delay + gpio operands and stop at the first DSI packet op.
+ */
+static int get_init_otp_deassert_fragment_len(struct drm_i915_private 
*dev_priv)
+{
+   const u8 *data = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
+   int index, len;
+
+   if (WARN_ON(!data || dev_priv->vbt.dsi.seq_version != 1))
+   return 0;
+
+   /* index = 1 to skip sequence byte */
+   for (index = 1; data[index] != MIPI_SEQ_ELEM_END; index += len) {
+   switch (data[index]) {
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   return index == 1 ? 0 : index;
+   case MIPI_SEQ_ELEM_DELAY:
+   len = 5; /* 1 byte for operand + uint32 */
+   break;
+   case MIPI_SEQ_ELEM_GPIO:
+   len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
+   break;
+   default:
+   return 0;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
+ * The deassert must be done before calling intel_dsi_device_ready, so for
+ * these devices we split the init OTP sequence into a deassert sequence and
+ * the actual init OTP part.
+ */
+static void fixup_mipi_sequences(struct drm_i915_private *dev_priv)
+{
+   u8 *init_otp;
+   int len;
+
+   /* Limit this to VLV for now. */
+   if (!IS_VALLEYVIEW(dev_priv))
+   return;
+
+   /* Limit this to v1 vid-mode sequences */
+   if (dev_priv->vbt.dsi.config->is_cmd_mode ||
+   dev_priv->vbt.dsi.seq_version != 1)
+   return;
+
+   /* Only do this if there are otp and assert seqs and no deassert seq */
+   if (!dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP] ||
+   !dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] ||
+   dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET])
+   return;
+
+   /* The deassert-sequence ends at the first DSI packet */
+   len = get_init_otp_deassert_fragment_len(dev_priv);
+   if (!len)
+   return;
+
+   DRM_DEBUG_KMS("Using init OTP fragment to deassert reset\n");
+
+   /* Copy the fragment, update seq byte and terminate it */
+   init_otp = (u8 

[PATCH v5 2/3] drm/i915: Free memdup-ed DSI VBT data structures on driver_unload

[Hans de Goede]

Make intel_bios_cleanup function free the DSI VBT data structures which
are memdup-ed by parse_mipi_config() and parse_mipi_sequence().

Reviewed-by: Ville Syrjälä 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_bios.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index ea1ed84a1e7d..92e52bb65c41 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1623,6 +1623,12 @@ void intel_bios_cleanup(struct drm_i915_private 
*dev_priv)
dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.dsi.data);
+   dev_priv->vbt.dsi.data = NULL;
+   kfree(dev_priv->vbt.dsi.pps);
+   dev_priv->vbt.dsi.pps = NULL;
+   kfree(dev_priv->vbt.dsi.config);
+   dev_priv->vbt.dsi.config = NULL;
 }
 
 /**
-- 
2.14.3

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

Re: [PATCH v7 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

[Vivek Gautam]

Hi Tomasz,


On Tue, Feb 13, 2018 at 2:01 PM, Tomasz Figa  wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.

Thanks for reviewing the patch series.

>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>  wrote:
>> From: Sricharan R 
>>
>> Finally add the device link between the master device and
>> smmu, so that the smmu gets runtime enabled/disabled only when the
>> master needs it. This is done from add_device callback which gets
>> called once when the master is added to the smmu.
>>
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/iommu/arm-smmu.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c024f69c1682..c7e924d553bd 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -215,6 +215,9 @@ struct arm_smmu_device {
>>
>> /* IOMMU core code handle */
>> struct iommu_device iommu;
>> +
>> +   /* runtime PM link to master */
>> +   struct device_link *link;
>>  };
>>
>>  enum arm_smmu_context_fmt {
>> @@ -1425,6 +1428,17 @@ static int arm_smmu_add_device(struct device *dev)
>>
>> pm_runtime_put_sync(smmu->dev);
>>
>> +   /*
>> +* Establish the link between smmu and master, so that the
>> +* smmu gets runtime enabled/disabled as per the master's
>> +* needs.
>> +*/
>> +   smmu->link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
>> +   if (!smmu->link)
>> +   dev_warn(smmu->dev,
>> +"Unable to create device link between %s and %s\n",
>> +dev_name(smmu->dev), dev_name(dev));
>
> How likely it is that the master can work normally even if the link
> add fails? Perhaps we should just return an error here?

Right. We are assuming that the power is handled for most of the
smmu operations, after we add the master with smmu, based on the fact
that the device link is successful.
We should return error code here. Will make the necessary change.

>
>> +
>> return 0;
>>
>>  out_rpm_put:
>> @@ -1449,6 +1463,8 @@ static void arm_smmu_remove_device(struct device *dev)
>> cfg  = fwspec->iommu_priv;
>> smmu = cfg->smmu;
>>
>> +   device_link_del(smmu->link);
>
> We allowed smmu->link in arm_smmu_add_device(), but here we don't
> check it. Looking at the code, device_link_del() doesn't seem to check
> either.
>
> Note that this problem would go away if we fail add_device on
> device_link_add() failure, as I suggested above, so no change would be
> necessary.

Sure. After making the above change, this should also be handled.

Best regards
Vivek

>
> Best regards,
> Tomasz



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFT PATCH] drm/msm: Trigger fence completion from GPU

[Bjorn Andersson]

Interrupt commands causes the CP to trigger an interrupt as the command
is processed, regardless of the GPU being done processing previous
commands. This is seen by the interrupt being delivered before the
fence is written on 8974 and is likely the cause of the additional
CP_WAIT_FOR_IDLE workaround found for a306, which would cause the CP to
wait for the GPU to go idle before triggering the interrupt.

Instead we can set the (undocumented) BIT(31) of the CACHE_FLUSH_TS
which will cause a special CACHE_FLUSH_TS interrupt to be triggered from
the GPU as the write event is processed.

Add CACHE_FLUSH_TS to the IRQ masks of A3xx and A4xx and remove the
workaround for A306.

Suggested-by: Jordan Crouse 
Signed-off-by: Bjorn Andersson 
---

This is only tested on 8974.

 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 ++
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4baef2738178..a3a43be920d0 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -35,6 +35,7 @@
 A3XX_INT0_CP_RB_INT | \
 A3XX_INT0_CP_REG_PROTECT_FAULT |  \
 A3XX_INT0_CP_AHB_ERROR_HALT | \
+A3XX_INT0_CACHE_FLUSH_TS |\
 A3XX_INT0_UCHE_OOB_ACCESS)
 
 extern bool hang_debug;
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 8199a4b9f2fa..b44cd0d90621 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -27,6 +27,7 @@
 A4XX_INT0_CP_RB_INT | \
 A4XX_INT0_CP_REG_PROTECT_FAULT |  \
 A4XX_INT0_CP_AHB_ERROR_HALT | \
+A4XX_INT0_CACHE_FLUSH_TS |\
 A4XX_INT0_UCHE_OOB_ACCESS)
 
 extern bool hang_debug;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index de63ff26a062..5806f9942514 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -293,26 +293,12 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
OUT_RING(ring, 0x);
}
 
+   /* BIT(31) of CACHE_FLUSH_TS triggers CACHE_FLUSH_TS IRQ from GPU */
OUT_PKT3(ring, CP_EVENT_WRITE, 3);
-   OUT_RING(ring, CACHE_FLUSH_TS);
+   OUT_RING(ring, CACHE_FLUSH_TS | BIT(31));
OUT_RING(ring, rbmemptr(ring, fence));
OUT_RING(ring, submit->seqno);
 
-   /* we could maybe be clever and only CP_COND_EXEC the interrupt: */
-   OUT_PKT3(ring, CP_INTERRUPT, 1);
-   OUT_RING(ring, 0x8000);
-
-   /* Workaround for missing irq issue on 8x16/a306.  Unsure if the
-* root cause is a platform issue or some a306 quirk, but this
-* keeps things humming along:
-*/
-   if (adreno_is_a306(adreno_gpu)) {
-   OUT_PKT3(ring, CP_WAIT_FOR_IDLE, 1);
-   OUT_RING(ring, 0x);
-   OUT_PKT3(ring, CP_INTERRUPT, 1);
-   OUT_RING(ring, 0x8000);
-   }
-
 #if 0
if (adreno_is_a3xx(adreno_gpu)) {
/* Dummy set-constant to trigger context rollover */
-- 
2.15.0

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

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Vivek Gautam]

Hi Tomasz,

On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:
> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:
>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:
>>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:
 On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>  wrote:
>> While handling the concerned iommu, there should not be a
>> need to power control the drm devices from iommu interface.
>> If these drm devices need to be powered around this time,
>> the respective drivers should take care of this.
>>
>> Replace the pm_runtime_get/put_sync() with
>> pm_runtime_get/put_suppliers() calls, to power-up
>> the connected iommu through the device link interface.
>> In case the device link is not setup these get/put_suppliers()
>> calls will be a no-op, and the iommu driver should take care of
>> powering on its devices accordingly.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/gpu/drm/msm/msm_iommu.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
>> b/drivers/gpu/drm/msm/msm_iommu.c
>> index b23d33622f37..1ab629bbee69 100644
>> --- a/drivers/gpu/drm/msm/msm_iommu.c
>> +++ b/drivers/gpu/drm/msm/msm_iommu.c
>> @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const 
>> char * const *names,
>> struct msm_iommu *iommu = to_msm_iommu(mmu);
>> int ret;
>>
>> -   pm_runtime_get_sync(mmu->dev);
>> +   pm_runtime_get_suppliers(mmu->dev);
>> ret = iommu_attach_device(iommu->domain, mmu->dev);
>> -   pm_runtime_put_sync(mmu->dev);
>> +   pm_runtime_put_suppliers(mmu->dev);
>
> For me, it looks like a wrong place to handle runtime PM of IOMMU
> here. iommu_attach_device() calls into IOMMU driver's attach_device()
> callback and that's where necessary runtime PM gets should happen, if
> any. In other words, driver A (MSM DRM driver) shouldn't be dealing
> with power state of device controlled by driver B (ARM SMMU).

 Note that we end up having to do the same, because of iommu_unmap()
 while DRM driver is powered off..  it might be cleaner if it was all
 self contained in the iommu driver, but that would make it so other
 drivers couldn't call iommu_unmap() from an irq handler, which is
 apparently something that some of them want to do..
>>>
>>> I'd assume that runtime PM status is already guaranteed to be active
>>> when the IRQ handler is running, by some other means (e.g.
>>> pm_runtime_get_sync() called earlier, when queuing some work to the
>>> hardware). Otherwise, I'm not sure how a powered down device could
>>> trigger an IRQ.
>>>
>>> So, if the master device power is already on, suppliers should be
>>> powered on as well, thanks to device links.
>>>
>>
>> umm, that is kindof the inverse of the problem..  the problem is
>> things like gpu driver (and v4l2 drivers that import dma-buf's,
>> afaict).. they will potentially call iommu->unmap() when device is not
>> active (due to userspace or things beyond the control of the driver)..
>> so *they* would want iommu to do pm get/put calls.
>
> Which is fine and which is actually already done by one of the patches
> in this series, not for map/unmap, but probe, add_device,
> remove_device. Having parts of the API doing it inside the callback
> and other parts outside sounds at least inconsistent.
>
>> But other drivers
>> trying to unmap from irq ctx would not.  Which is the contradictory
>> requirement that lead to the idea of iommu user powering up iommu for
>> unmap.
>
> Sorry, maybe I wasn't clear. My last message was supposed to show that
> it's not contradictory at all, because "other drivers trying to unmap
> from irq ctx" would already have called pm_runtime_get_*() earlier
> from a non-irq ctx, which would have also done the same on all the
> linked suppliers, including the IOMMU. The ultimate result would be
> that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync()
> would do nothing besides incrementing the reference count.

The entire point was to avoid the slowpath that pm_runtime_get/put_sync()
would add in map/unmap. It would not be correct to add a slowpath in irq_ctx
for taking care of non-irq_ctx and for the situations where master is already
powered-off.

>
>>
>> There has already been some discussion about this on various earlier
>> permutations of this patchset.  I think we have exhausted all other
>> options.
>
> I guess I should have read those. Let me do that now.
Yea, i point to the thread in 

[PATCH v5] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

When the linux kernel is build with (typical kernel ship with Debian
installer):

CONFIG_FB=y
CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m

The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:

[   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
0x9800-0x9fff pref]
[   96.551531] radeonfb (:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of :00:10.0 failed with error -16

This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded, see
commit a56f7428d753 ("drm/radeon: Add early unregister of firmware fb's").

Signed-off-by: Mathieu Malaterre 
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
the conflicts in region is due to OFfb explicitly refers to it.
v4: Use drm_fb_helper_remove_conflicting_framebuffers from drm_fb_helper
v5: do not use drm_fb_helper_remove_conflicting_framebuffers from drm_fb_helper
remove ifdef hacks since not needed once framebuffer is properly decremented

 drivers/video/fbdev/aty/radeon_base.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 87608c0b2351..e8594bbaea60 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2255,6 +2255,23 @@ static const struct bin_attribute edid2_attr = {
.read   = radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+   struct apertures_struct *ap;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
+   ap->ranges[0].base = pci_resource_start(pdev, 0);
+   ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+   remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+
+   kfree(ap);
+
+   return 0;
+}
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
 const struct pci_device_id *ent)
@@ -2308,6 +2325,10 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+   ret = radeon_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
-- 
2.11.0

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

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
 wrote:
> Hi Tomasz,
>
> On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa  wrote:
>> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>>  wrote:
>>> Hi Tomasz,
>>>
>>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:
 On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:
> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:
>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:
>>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  wrote:
 Hi Vivek,

 Thanks for the patch. Please see my comments inline.

 On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
  wrote:
> While handling the concerned iommu, there should not be a
> need to power control the drm devices from iommu interface.
> If these drm devices need to be powered around this time,
> the respective drivers should take care of this.
>
> Replace the pm_runtime_get/put_sync() with
> pm_runtime_get/put_suppliers() calls, to power-up
> the connected iommu through the device link interface.
> In case the device link is not setup these get/put_suppliers()
> calls will be a no-op, and the iommu driver should take care of
> powering on its devices accordingly.
>
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/gpu/drm/msm/msm_iommu.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
> b/drivers/gpu/drm/msm/msm_iommu.c
> index b23d33622f37..1ab629bbee69 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, 
> const char * const *names,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> int ret;
>
> -   pm_runtime_get_sync(mmu->dev);
> +   pm_runtime_get_suppliers(mmu->dev);
> ret = iommu_attach_device(iommu->domain, mmu->dev);
> -   pm_runtime_put_sync(mmu->dev);
> +   pm_runtime_put_suppliers(mmu->dev);

 For me, it looks like a wrong place to handle runtime PM of IOMMU
 here. iommu_attach_device() calls into IOMMU driver's attach_device()
 callback and that's where necessary runtime PM gets should happen, if
 any. In other words, driver A (MSM DRM driver) shouldn't be dealing
 with power state of device controlled by driver B (ARM SMMU).
>>>
>>> Note that we end up having to do the same, because of iommu_unmap()
>>> while DRM driver is powered off..  it might be cleaner if it was all
>>> self contained in the iommu driver, but that would make it so other
>>> drivers couldn't call iommu_unmap() from an irq handler, which is
>>> apparently something that some of them want to do..
>>
>> I'd assume that runtime PM status is already guaranteed to be active
>> when the IRQ handler is running, by some other means (e.g.
>> pm_runtime_get_sync() called earlier, when queuing some work to the
>> hardware). Otherwise, I'm not sure how a powered down device could
>> trigger an IRQ.
>>
>> So, if the master device power is already on, suppliers should be
>> powered on as well, thanks to device links.
>>
>
> umm, that is kindof the inverse of the problem..  the problem is
> things like gpu driver (and v4l2 drivers that import dma-buf's,
> afaict).. they will potentially call iommu->unmap() when device is not
> active (due to userspace or things beyond the control of the driver)..
> so *they* would want iommu to do pm get/put calls.

 Which is fine and which is actually already done by one of the patches
 in this series, not for map/unmap, but probe, add_device,
 remove_device. Having parts of the API doing it inside the callback
 and other parts outside sounds at least inconsistent.

> But other drivers
> trying to unmap from irq ctx would not.  Which is the contradictory
> requirement that lead to the idea of iommu user powering up iommu for
> unmap.

 Sorry, maybe I wasn't clear. My last message was supposed to show that
 it's not contradictory at all, because "other drivers trying to unmap
 from irq ctx" would already have called pm_runtime_get_*() earlier
 from a non-irq ctx, which would have also done the same on all the
 linked suppliers, including the IOMMU. The ultimate result would be
 that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync()
 would do 

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Ilia Mirkin]

On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos  wrote:
>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>
> NV5 in another PC (secondary card in x86-64) made the systrem crash on
> boot, in nvkm_therm_clkgate_fini.

Mind booting with nouveau.debug=trace? That should hopefully tell us
more exactly which thing is dying. If you have a cross-compile/distcc
setup handy, a bisect may be even more useful.

It's funny, I had a NV5 plugged into my desktop for testing, and
*just* took it out (because the box wouldn't even get to BIOS anymore
... although it was unrelated to the NV5, probably just something
mis-seated.)

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

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Vivek Gautam]

Hi Tomasz,

On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa  wrote:
> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>  wrote:
>> Hi Tomasz,
>>
>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:
>>> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:
 On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:
> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:
>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  wrote:
>>> Hi Vivek,
>>>
>>> Thanks for the patch. Please see my comments inline.
>>>
>>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>>>  wrote:
 While handling the concerned iommu, there should not be a
 need to power control the drm devices from iommu interface.
 If these drm devices need to be powered around this time,
 the respective drivers should take care of this.

 Replace the pm_runtime_get/put_sync() with
 pm_runtime_get/put_suppliers() calls, to power-up
 the connected iommu through the device link interface.
 In case the device link is not setup these get/put_suppliers()
 calls will be a no-op, and the iommu driver should take care of
 powering on its devices accordingly.

 Signed-off-by: Vivek Gautam 
 ---
  drivers/gpu/drm/msm/msm_iommu.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
 b/drivers/gpu/drm/msm/msm_iommu.c
 index b23d33622f37..1ab629bbee69 100644
 --- a/drivers/gpu/drm/msm/msm_iommu.c
 +++ b/drivers/gpu/drm/msm/msm_iommu.c
 @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, 
 const char * const *names,
 struct msm_iommu *iommu = to_msm_iommu(mmu);
 int ret;

 -   pm_runtime_get_sync(mmu->dev);
 +   pm_runtime_get_suppliers(mmu->dev);
 ret = iommu_attach_device(iommu->domain, mmu->dev);
 -   pm_runtime_put_sync(mmu->dev);
 +   pm_runtime_put_suppliers(mmu->dev);
>>>
>>> For me, it looks like a wrong place to handle runtime PM of IOMMU
>>> here. iommu_attach_device() calls into IOMMU driver's attach_device()
>>> callback and that's where necessary runtime PM gets should happen, if
>>> any. In other words, driver A (MSM DRM driver) shouldn't be dealing
>>> with power state of device controlled by driver B (ARM SMMU).
>>
>> Note that we end up having to do the same, because of iommu_unmap()
>> while DRM driver is powered off..  it might be cleaner if it was all
>> self contained in the iommu driver, but that would make it so other
>> drivers couldn't call iommu_unmap() from an irq handler, which is
>> apparently something that some of them want to do..
>
> I'd assume that runtime PM status is already guaranteed to be active
> when the IRQ handler is running, by some other means (e.g.
> pm_runtime_get_sync() called earlier, when queuing some work to the
> hardware). Otherwise, I'm not sure how a powered down device could
> trigger an IRQ.
>
> So, if the master device power is already on, suppliers should be
> powered on as well, thanks to device links.
>

 umm, that is kindof the inverse of the problem..  the problem is
 things like gpu driver (and v4l2 drivers that import dma-buf's,
 afaict).. they will potentially call iommu->unmap() when device is not
 active (due to userspace or things beyond the control of the driver)..
 so *they* would want iommu to do pm get/put calls.
>>>
>>> Which is fine and which is actually already done by one of the patches
>>> in this series, not for map/unmap, but probe, add_device,
>>> remove_device. Having parts of the API doing it inside the callback
>>> and other parts outside sounds at least inconsistent.
>>>
 But other drivers
 trying to unmap from irq ctx would not.  Which is the contradictory
 requirement that lead to the idea of iommu user powering up iommu for
 unmap.
>>>
>>> Sorry, maybe I wasn't clear. My last message was supposed to show that
>>> it's not contradictory at all, because "other drivers trying to unmap
>>> from irq ctx" would already have called pm_runtime_get_*() earlier
>>> from a non-irq ctx, which would have also done the same on all the
>>> linked suppliers, including the IOMMU. The ultimate result would be
>>> that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync()
>>> would do nothing besides incrementing the reference count.
>>
>> The entire point was to avoid the slowpath that pm_runtime_get/put_sync()
>> would add in map/unmap. It would not be correct to 

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Vivek Gautam]

On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa  wrote:

Adding Jordan to this thread as well.

> On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
>  wrote:
>> Hi Tomasz,
>>
>> On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa  wrote:
>>> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>>>  wrote:
 Hi Tomasz,

 On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:
> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:
>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:
>>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:
 On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  
 wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>  wrote:
>> While handling the concerned iommu, there should not be a
>> need to power control the drm devices from iommu interface.
>> If these drm devices need to be powered around this time,
>> the respective drivers should take care of this.
>>
>> Replace the pm_runtime_get/put_sync() with
>> pm_runtime_get/put_suppliers() calls, to power-up
>> the connected iommu through the device link interface.
>> In case the device link is not setup these get/put_suppliers()
>> calls will be a no-op, and the iommu driver should take care of
>> powering on its devices accordingly.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/gpu/drm/msm/msm_iommu.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
>> b/drivers/gpu/drm/msm/msm_iommu.c
>> index b23d33622f37..1ab629bbee69 100644
>> --- a/drivers/gpu/drm/msm/msm_iommu.c
>> +++ b/drivers/gpu/drm/msm/msm_iommu.c
>> @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, 
>> const char * const *names,
>> struct msm_iommu *iommu = to_msm_iommu(mmu);
>> int ret;
>>
>> -   pm_runtime_get_sync(mmu->dev);
>> +   pm_runtime_get_suppliers(mmu->dev);
>> ret = iommu_attach_device(iommu->domain, mmu->dev);
>> -   pm_runtime_put_sync(mmu->dev);
>> +   pm_runtime_put_suppliers(mmu->dev);
>
> For me, it looks like a wrong place to handle runtime PM of IOMMU
> here. iommu_attach_device() calls into IOMMU driver's attach_device()
> callback and that's where necessary runtime PM gets should happen, if
> any. In other words, driver A (MSM DRM driver) shouldn't be dealing
> with power state of device controlled by driver B (ARM SMMU).

 Note that we end up having to do the same, because of iommu_unmap()
 while DRM driver is powered off..  it might be cleaner if it was all
 self contained in the iommu driver, but that would make it so other
 drivers couldn't call iommu_unmap() from an irq handler, which is
 apparently something that some of them want to do..
>>>
>>> I'd assume that runtime PM status is already guaranteed to be active
>>> when the IRQ handler is running, by some other means (e.g.
>>> pm_runtime_get_sync() called earlier, when queuing some work to the
>>> hardware). Otherwise, I'm not sure how a powered down device could
>>> trigger an IRQ.
>>>
>>> So, if the master device power is already on, suppliers should be
>>> powered on as well, thanks to device links.
>>>
>>
>> umm, that is kindof the inverse of the problem..  the problem is
>> things like gpu driver (and v4l2 drivers that import dma-buf's,
>> afaict).. they will potentially call iommu->unmap() when device is not
>> active (due to userspace or things beyond the control of the driver)..
>> so *they* would want iommu to do pm get/put calls.
>
> Which is fine and which is actually already done by one of the patches
> in this series, not for map/unmap, but probe, add_device,
> remove_device. Having parts of the API doing it inside the callback
> and other parts outside sounds at least inconsistent.
>
>> But other drivers
>> trying to unmap from irq ctx would not.  Which is the contradictory
>> requirement that lead to the idea of iommu user powering up iommu for
>> unmap.
>
> Sorry, maybe I wasn't clear. My last message was supposed to show that
> it's not contradictory at all, because "other drivers trying to unmap
> from irq ctx" would already have called pm_runtime_get_*() earlier
> from a non-irq 

[PATCH v3 08/13] drm/amd/include: remove unused asic_reg/uvd headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |  795 -
 .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h| 1211 
 .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h| 1081 -
 3 files changed, 3087 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
deleted file mode 100644
index 8ee3149df5b7..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h
deleted file mode 100644
index 981086f8ee4e..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h
deleted file mode 100644
index ecf47ba55c2d..
-- 
2.13.6

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

Re: [PATCH] drm: rcar-du: Enable VSP compositor by default on Gen3

[Kieran Bingham]

Hi Laurent,

Thankyou for the patch.

On 12/01/18 03:20, Laurent Pinchart wrote:
> On Gen3 hardware the VSP compositor is required for display. Enable it
> by default in the kernel configuration. The option is kept
> user-configurable for testing purpose on Gen2 platforms.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 


> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 1d6f1b849287..2b104daf56eb 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -27,7 +27,8 @@ config DRM_RCAR_LVDS
> Enable support for the R-Car Display Unit embedded LVDS encoders.
>  
>  config DRM_RCAR_VSP
> - bool "R-Car DU VSP Compositor Support"
> + bool "R-Car DU VSP Compositor Support" if ARM
> + default y if ARM64
>   depends on DRM_RCAR_DU
>   depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
>   help
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Ilia Mirkin]

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin  wrote:
> On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos  wrote:
>>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>>
>> NV5 in another PC (secondary card in x86-64) made the systrem crash on
>> boot, in nvkm_therm_clkgate_fini.
>
> Mind booting with nouveau.debug=trace? That should hopefully tell us
> more exactly which thing is dying. If you have a cross-compile/distcc
> setup handy, a bisect may be even more useful.

Erm, sorry, nevermind. You even said it -- nvkm_therm_clkgate_fini is
somehow mis-hooked up for NV5 now. A bisect result would still make
the culprit a lot more obvious.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi,

On 14 February 2018 at 13:50, Sean Paul  wrote:
> On Wed, Feb 14, 2018 at 07:22:53AM -0500, Rob Clark wrote:
>> On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone  wrote:
>> > This one I guess you can't get around though. Can they still run from
>> > the one plane, or do you secretly consume two planes?
>>
>> I think it is still the case, like mdp5, that you need two hw pipes..
>> but actually it gets more crazy, since there are some cases where two
>> planes could share a hw pipe.
>
> Right. Large fbs might require 2 pipes, and multiple overlapping or adjacent 
> small fbs
> can be serviced with 1 pipe.

I didn't know about using a single pipe for multiple framebuffers.
That's quite special indeed.

I think virtualising probably makes sense in that case: rather than
just getting around limitations, it's seeming like more of a VC4
situation where they just really aren't actually planes in the first
place.

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

[PATCH v3 13/13] drm/amd/powerplay: remove unused headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h| 412 -
 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |  67 
 2 files changed, 479 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h
 delete mode 100644 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h

diff --git a/drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h 
b/drivers/gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h
deleted file mode 100644
index b8f4b73c322e..
diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_feature.h 
b/drivers/gpu/drm/amd/powerplay/inc/pp_feature.h
deleted file mode 100644
index 0faf6a25c18b..
-- 
2.13.6

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

[PATCH v3 09/13] drm/amd/include: remove unused asic_reg/vce headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   | 64 --
 .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 99 --
 2 files changed, 163 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h
deleted file mode 100644
index 2176548e9203..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h
deleted file mode 100644
index ea5b26b11cb1..
-- 
2.13.6

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

[PATCH v3 10/13] drm/amd/include: remove unused asic_reg/sdma headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h | 286 -
 .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h | 282 
 2 files changed, 568 deletions(-)
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
deleted file mode 100644
index 4be3cb5c4556..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h
deleted file mode 100644
index 934733762ddf..
-- 
2.13.6

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

[PATCH v3 03/13] drm/amd/include: remove unused asic_reg/dce headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   | 6813 
 .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h| 1117 
 2 files changed, 7930 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
deleted file mode 100644
index b2ea4202d7bd..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
deleted file mode 100644
index 6bea30ef3df5..
-- 
2.13.6

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

[PATCH v3 04/13] drm/amd/include: remove unused asic_reg/gca headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
 .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
 .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368 ---
 3 files changed, 30967 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
deleted file mode 100644
index 2d672b3d2fed..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
deleted file mode 100644
index f9022097fbe9..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
deleted file mode 100644
index 397705a6b3a2..
-- 
2.13.6

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

[PATCH v3 11/13] drm/amd/include: remove unused asic_reg/nbif headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 ---
 1 file changed, 10281 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
deleted file mode 100644
index c7518b84f559..
-- 
2.13.6

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

[PATCH v3 01/13] drm/amd/include: remove unused asic_reg/oss headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h| 1340 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  | 1464 ---
 .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h| 1497 
 3 files changed, 4301 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
deleted file mode 100644
index 37adf0df0fd3..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
deleted file mode 100644
index 627cff10fcce..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h
deleted file mode 100644
index 09338d82afba..
-- 
2.13.6

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

[PATCH v3 07/13] drm/amd/include: remove unused asic_reg/umc headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/umc/umc_6_0_default.h | 31 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  | 52 --
 2 files changed, 83 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h 
b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_default.h
deleted file mode 100644
index 128a18f1e362..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h 
b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_0_offset.h
deleted file mode 100644
index 6985dbba39f5..
-- 
2.13.6

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

[PATCH v3 12/13] drm/amd/include: remove unused displayobject.h header

[Corentin Labbe]

displayobject.h is not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 drivers/gpu/drm/amd/include/displayobject.h | 249 
 1 file changed, 249 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/displayobject.h

diff --git a/drivers/gpu/drm/amd/include/displayobject.h 
b/drivers/gpu/drm/amd/include/displayobject.h
deleted file mode 100644
index 67e23ff9cbd4..
-- 
2.13.6

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

[PATCH v3 02/13] drm/amd/include: remove unused asic_reg/bif headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h| 1198 
 .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h| 1068 -
 2 files changed, 2266 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
deleted file mode 100644
index 46b75f4bbc36..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
deleted file mode 100644
index d8d5ae0b341f..
-- 
2.13.6

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

[PATCH v3 06/13] drm/amd/include: remove unused asic_reg/smu headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |  148 -
 .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |  715 ---
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h | 1344 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  | 1191 -
 .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   | 5648 
 .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  | 1205 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  | 1246 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  | 1282 -
 .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h| 1072 
 9 files changed, 13851 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
deleted file mode 100644
index 6b10be61efc3..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
deleted file mode 100644
index 7d3925b7266e..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
deleted file mode 100644
index 57588b11ff1a..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
deleted file mode 100644
index 61face1d0d8d..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
deleted file mode 100644
index cd7893065a4b..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
deleted file mode 100644
index c1a7aba19223..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
deleted file mode 100644
index 73bbf506b1c9..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
deleted file mode 100644
index f19c4208d963..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h
deleted file mode 100644
index e1540c181bf8..
-- 
2.13.6

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

Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote:
> Hi,
> 
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > Hello,
> > 
> > Most of this series has previously been posted as part of "[PATCH 00/48]
> > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> > Miscellaneous fixes and cleanups" posted and merged a few days ago, it
> > completes the rework of the omapdrm and omapdss drivers to replace most
> > global variables with dynamically-allocated objects. The actual merge of
> > the omapdrm and omapdss drivers has been left out for now as it still
> > suffers from unresolved issues.
> > 
> > As with the previous series I have other pending patches based on top of
> > this, as passing driver objects around explicitly helps not relying on
> > more global variables that would hinder the effort to move to the DRM
> > bridge and DRM panel APIs.
> > 
> > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen
> > significant changes and I have thus dropped the Reviewed-by tag from
> > Sebastian. All other patches have been rebased and reordered, thus
> > sometimes modified to resolve conflicts, but have otherwise seen only
> > minor changes.
> > 
> > The series is based on top of the omapdrm-next branch from
> > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git.
> > 
> > Tomi, as the series has been stripped of its controversial patches, I
> > think it's now ready to be merged (pending review of the patches mentioned
> > above of course). I have tested it on both a Panda board and an AM57xx EVM
> > without any issues (and this time I made sure to try with the drivers
> > compiled as modules).
> 
> I have to admit I didn't go through every line of the patches, but
> overall I think this looks good. The only problem is the support for
> DSS6, which I mentioned in the other mail.
> 
> We don't have DSS6 support in mainline, but it's a critical thing for TI
> to support. If it helps, we can upstream the current DSS6 driver (which
> is not very big), so that these can be reworked with DSS6 included. Or
> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
> driver working on top of these (which, afaics, is not possible at the
> moment).

Following up our discussion in reply to another e-mail in this thread, would 
switching to struct device pointers for DSS and DISPC objects in the public 
API help ? Is there anything else preventing DSS6 from working on top of this 
series ? I would personally prefer getting the cleanups and reworks (including 
the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in 
mainline, as the problem is already complex enough.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Tomi Valkeinen]

On 14/02/18 17:39, Laurent Pinchart wrote:

>> I have to admit I didn't go through every line of the patches, but
>> overall I think this looks good. The only problem is the support for
>> DSS6, which I mentioned in the other mail.
>>
>> We don't have DSS6 support in mainline, but it's a critical thing for TI
>> to support. If it helps, we can upstream the current DSS6 driver (which
>> is not very big), so that these can be reworked with DSS6 included. Or
>> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
>> driver working on top of these (which, afaics, is not possible at the
>> moment).
> 
> Following up our discussion in reply to another e-mail in this thread, would 
> switching to struct device pointers for DSS and DISPC objects in the public 
> API help ? Is there anything else preventing DSS6 from working on top of this 

I think using struct device pointers should be enough to get DSS6
working, but we need to try it out. And, as you pointed out, the structs
are opaque to omapdrm, so if we're sure they don't leak to omapdrm and
don't mix up between dss2-5 and dss6 drivers, we could even use the same
struct. But I think that's rather messy, so if we do that it should be
just a temporary measure.

> series ? I would personally prefer getting the cleanups and reworks 
> (including 
> the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in 
> mainline, as the problem is already complex enough.

I agree, but then, I've been pushing the upstreaming of DSS6 driver
forward for a very long time already. And, it does create these kind of
issue, making it very laborious to carry in TI's tree. So, I'm fine with
waiting still a bit longer, but if the bridge/panel work gets delayed,
I'd rather push DSS6.

I made a quick branch on top of drm-next which contains the DSS6:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
4.17/omapdrm-dss6-test

The first three patches have already been posted for review, and the
last three and not that relevant here.

It's essentially a simplified version of the old DSS, with slightly
different registers.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

[Jordan Crouse]

On Tue, Feb 13, 2018 at 10:46:58PM -0800, Bjorn Andersson wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on 8974 and is likely the cause of the additional
> CP_WAIT_FOR_IDLE workaround found for a306, which would cause the CP to
> wait for the GPU to go idle before triggering the interrupt.
> 
> Instead we can set the (undocumented) BIT(31) of the CACHE_FLUSH_TS
> which will cause a special CACHE_FLUSH_TS interrupt to be triggered from
> the GPU as the write event is processed.
> 
> Add CACHE_FLUSH_TS to the IRQ masks of A3xx and A4xx and remove the
> workaround for A306.
> 
> Suggested-by: Jordan Crouse 
> Signed-off-by: Bjorn Andersson 

LGTM. This should help your races.

> ---
> 
> This is only tested on 8974.
> 
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 ++
>  3 files changed, 4 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 4baef2738178..a3a43be920d0 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -35,6 +35,7 @@
>A3XX_INT0_CP_RB_INT | \
>A3XX_INT0_CP_REG_PROTECT_FAULT |  \
>A3XX_INT0_CP_AHB_ERROR_HALT | \
> +  A3XX_INT0_CACHE_FLUSH_TS |\
>A3XX_INT0_UCHE_OOB_ACCESS)
>  
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index 8199a4b9f2fa..b44cd0d90621 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -27,6 +27,7 @@
>A4XX_INT0_CP_RB_INT | \
>A4XX_INT0_CP_REG_PROTECT_FAULT |  \
>A4XX_INT0_CP_AHB_ERROR_HALT | \
> +  A4XX_INT0_CACHE_FLUSH_TS |\
>A4XX_INT0_UCHE_OOB_ACCESS)
>  
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index de63ff26a062..5806f9942514 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -293,26 +293,12 @@ void adreno_submit(struct msm_gpu *gpu, struct 
> msm_gem_submit *submit,
>   OUT_RING(ring, 0x);
>   }
>  
> + /* BIT(31) of CACHE_FLUSH_TS triggers CACHE_FLUSH_TS IRQ from GPU */
>   OUT_PKT3(ring, CP_EVENT_WRITE, 3);
> - OUT_RING(ring, CACHE_FLUSH_TS);
> + OUT_RING(ring, CACHE_FLUSH_TS | BIT(31));
>   OUT_RING(ring, rbmemptr(ring, fence));
>   OUT_RING(ring, submit->seqno);
>  
> - /* we could maybe be clever and only CP_COND_EXEC the interrupt: */
> - OUT_PKT3(ring, CP_INTERRUPT, 1);
> - OUT_RING(ring, 0x8000);
> -
> - /* Workaround for missing irq issue on 8x16/a306.  Unsure if the
> -  * root cause is a platform issue or some a306 quirk, but this
> -  * keeps things humming along:
> -  */
> - if (adreno_is_a306(adreno_gpu)) {
> - OUT_PKT3(ring, CP_WAIT_FOR_IDLE, 1);
> - OUT_RING(ring, 0x);
> - OUT_PKT3(ring, CP_INTERRUPT, 1);
> - OUT_RING(ring, 0x8000);
> - }
> -
>  #if 0
>   if (adreno_is_a3xx(adreno_gpu)) {
>   /* Dummy set-constant to trigger context rollover */
> -- 
> 2.15.0
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of 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: [PULL] drm/i915: Add HDCP support to i915

[Jani Nikula]

On Wed, 14 Feb 2018, Sean Paul  wrote:
> On Wed, Feb 14, 2018 at 02:48:29PM +0100, Hans Verkuil wrote:
>> Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen.
>> At least not on dri-devel. It's a bit weird.
>
> Ahh, I'm sorry I misunderstood. I think Ram may have sent those to intel-gfx
> exclusively.

We rarely post i915 specific patches to dri-devel, just intel-gfx, but
in cases where they warrant changes in drm core it may be warranted to
add a wider audience. Sorry about failing to do that here.

All the commits have Link: tags back to the patches posted publicly,
with message-ids.


BR,
Jani.

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

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Sean Paul]

On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> On 2018-02-14 03:08 PM, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> >>> Dear drm-misc maintainers,
> >>>
> >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>  Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> >>> This series has been reviewed, consent has been expressed by the most
> >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> >>> has been acked and I've just out a v2 addressing the only objection
> >>> raised.  My plan is thus to wait another two days for comments and,
> >>> barring further objections, push to drm-misc this weekend.
> >>>
> >>> However I'm struggling with the decision whether to push to next or
> >>> fixes.  The series is marked for stable, however the number of
> >>> affected machines is limited and for an issue that's been present
> >>> for 5 years it probably doesn't matter if it soaks another two months
> >>> in linux-next befor it gets backported.  Hence I tend to err on the
> >>> side of caution and push to next, however a case could be made that
> >>> fixes is more appropriate.
> >>>
> >>> I'm lacking experience making such decisions and would be interested
> >>> to learn how you'd handle this.
> >>>
> >>> Thanks,
> >>>
> >>> Lukas
> >>
> >> I would say fixes, it doesn't look particularly scary. :)
> > 
> > Agreed. If it's good enough for stable, it's good enough for -fixes!
> 
> It's not that simple, is it? Fast-tracking patches (some of which appear
> to be untested) to stable without an immediate cause for urgency seems
> risky to me.
> 

/me should be more careful what he says

Given where we are in the release cycle, it's barely a fast track. If these go
in -fixes, they'll get in -rc2 and will have plenty of time to bake. If we were
at rc5, it might be a different story.

Sean

> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer

-- 
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: [RFC PULL] Add Display Support for Qualcomm SDM845

[Rob Clark]

On Tue, Feb 13, 2018 at 3:00 PM, Rob Clark  wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:
>> Hi dri-devel,
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, rather than an attempt at mainlining the code as it
>> currently stands. The goal is get this driver in shape over the next coming
>> months.
>>
>> In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
>> will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things 
>> look
>> good, I'll send another pull 4realz.
>>
>> To get the ball rolling, I've done some review on the new connector code, my
>> comments are below.
>>
>> Thanks in advance for your constructive feedback :)
>>
>> Sean
>>
>> [1]- git://people.freedesktop.org/~seanpaul/dpu-staging
>>
>> Review feedback:
>> 
>
> just so others aren't confused, s/sde/dpu/g in the list below (we did
> our DAL->DC rename before sending first RFC :-P)
>
>> - Solve the splash screen handling (or remove it)
>> - Simplify devicetree binding (remove register offsets)
>> feedback from reviewing sde_connector.c:
>> - Rationalize backlight implementation in sde_connector (display_count 
>> static)
>> - Sort out the dsi event passing between dsi/encoder/connector (move to 
>> encoder)
>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
>> - connector->state access violations reading/writing mode_info
>> - s/sde_rect/drm_rect/
>> - sde_kms_info usage needs to be replaced with formal data structures (not
>>   stringified keypairs)
>> - sde_connector_ops needs to be trimmed, duplicates connector helpers, info
>>   hooks circumvent state, and other hooks should be stored in state or
>>   prepopulated (get_dst_format)
>> - sde_connector_get_dpms unused
>> - esd status check should migrate to encoder from connector
>> - backlight should be handled in panel drivers, not in the generic 
>> connector/dsi
>>   encoder
>> - sde_connector_helper_bridge_disable is called from encoder and calls back 
>> into
>>   set_power encoder function. if backlight, and esd status are removed,
>>   pre_kickoff can probably go away
>> - sde_connector_clk_ctrl is another example of encoder->connector->encoder 
>> call
>> - RETIRE_FENCE connector property should be removed, opting for the native
>>   atomic fences
>> - ROI (regions of interest) should be expressed per-plane instead of 
>> connector.
>>   there is work ongoing to support dirty_rects per-plane by Deepak Singh 
>> Rawat
>>    and Lukasz Spintzyk 
>> - Uma Shankar  has proposed HDR source metadata
>>   properties on the list, we should pivot to those instead of hand-rolling 
>> them
>>   in the sde driver
>> - Convert HDCP implementation to upstream Content Protection property
>> - Merge dsi and dsi_staging into one driver
>> - Writeback connector has been proposed by ARM (Liviu Dudau and Brian 
>> Starkey),
>>   we should work with their proposal instead of rolling OUT_FB ourselves
>> - sde_connector_set_property should be replaced with atomic helper
>> - dsi hotplug can probably be punted to the panel driver
>> - dpms should switch to enable/disable (or at least use the atomic helpers)
>> - dsi mode handling should also defer to the panel driver
>> - SDE_WB_CONFIG ioctl should be removed in favor of the existing ioctl to add
>>   user-defined modes
>> - dp implementation should use the existing dp helpers wherever possible
>> - lots of duplicated structures in dsi_defs.h that can be replaced with 
>> existing
>>   drm structs
>> - mode_valid should be split up and implemented directly in 
>> connector/encoder as
>>   appropriate
>> - sde_connector->aspace seems like it's unused?
>>
>
> To add to that, a few things I've noticed (but I've mostly only gotten
> as far as the front-end of the pipeline, ie. dpu_plane):
>
>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>there are still unequal capabilities for planes (ie. some can do YUV,
>scaling, etc).
>
>But drm-hwc (or weston) isn't going to know about that, so I think we'll
>need to add support for dynamically assigning dpu_plane::pipe, similar
>to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>for drm-hwc ;-))
>
>  - I *think* we also need the same trick for combining mixers under one CRTC
>for 4k modes too?
>
>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like CSC
>and scaling coefficients need to be annotated w/ __user.  (Except the 
> should
>probably be blob properties instead.. and we probably need to strip out the
>custom properties and re-introduce them separately with some userspace +
>review.)
>
>  - dpu_formats.c looks mostly like a superset of mdp_format.c, ie there is 

[Bug 105095] piglit arb_vertex_type_2_10_10_10_rev-array_types failed for BARTS

[bugzilla-daemon]

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

Bug ID: 105095
   Summary: piglit arb_vertex_type_2_10_10_10_rev-array_types
failed for BARTS
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: benau2...@yahoo.com.hk
QA Contact: dri-devel@lists.freedesktop.org

Output of arb_vertex_type_2_10_10_10_rev-array_types from piglit tests:

testing: RGBA SINT
testing: RGBA SNORM
Probe color at (25,5)
  Expected: 0.50 0.25 0.00 1.00
  Observed: 0.501961 0.250980 0.00 0.33
testing: RGBA UINT
testing: RGBA UNORM
testing: BGRA SNORM
Probe color at (85,5)
  Expected: 0.00 0.25 0.50 1.00
  Observed: 0.00 0.250980 0.501961 0.33
testing: BGRA UNORM
Mesa version 17.3.3
AMD/ATI Barts PRO Radeon HD 6850

Detail in https://github.com/supertuxkart/stk-code/issues/3097, this bug cause
wrong animation in stk.

And i think 2.2 / 2.3 equation isn't causing this bug, because from what i see
zero is represented correctly in stk, also some amd devs told me barts switched
to use the new formula long time ago.

Any idea?

-- 
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: 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Meelis Roos]

> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:

NV5 in another PC (secondary card in x86-64) made the systrem crash on 
boot, in nvkm_therm_clkgate_fini.

-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Michel Dänzer]

On 2018-02-14 03:08 PM, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
>> Op 14-02-18 om 09:46 schreef Lukas Wunner:
>>> Dear drm-misc maintainers,
>>>
>>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
 Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>>> This series has been reviewed, consent has been expressed by the most
>>> interested parties, patch [1/5] which touches files outside drivers/gpu
>>> has been acked and I've just out a v2 addressing the only objection
>>> raised.  My plan is thus to wait another two days for comments and,
>>> barring further objections, push to drm-misc this weekend.
>>>
>>> However I'm struggling with the decision whether to push to next or
>>> fixes.  The series is marked for stable, however the number of
>>> affected machines is limited and for an issue that's been present
>>> for 5 years it probably doesn't matter if it soaks another two months
>>> in linux-next befor it gets backported.  Hence I tend to err on the
>>> side of caution and push to next, however a case could be made that
>>> fixes is more appropriate.
>>>
>>> I'm lacking experience making such decisions and would be interested
>>> to learn how you'd handle this.
>>>
>>> Thanks,
>>>
>>> Lukas
>>
>> I would say fixes, it doesn't look particularly scary. :)
> 
> Agreed. If it's good enough for stable, it's good enough for -fixes!

It's not that simple, is it? Fast-tracking patches (some of which appear
to be untested) to stable without an immediate cause for urgency seems
risky to me.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 05/13] drm/amd/include: remove unused asic_reg/gmc headers

[Corentin Labbe]

All thoses headers are not used by any source files.
Lets just remove them.

Signed-off-by: Corentin Labbe 
---
 .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h| 1198 
 .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h| 1068 -
 2 files changed, 2266 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
deleted file mode 100644
index 05b80f2bb147..
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h 
b/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
deleted file mode 100644
index bc18e4d1f20e..
-- 
2.13.6

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

[PATCH v3 00/13] gpu: drm: amd: remove unused headers

[Corentin Labbe]

Hello

This patchset remove several headers which are not used by any source
file.

Regards

Change since v1:
- splited in multiple patchs

Change since v2
- Use --irreversible-delete for format-patch

Corentin Labbe (13):
  drm/amd/include: remove unused asic_reg/oss headers
  drm/amd/include: remove unused asic_reg/bif headers
  drm/amd/include: remove unused asic_reg/dce headers
  drm/amd/include: remove unused asic_reg/gca headers
  drm/amd/include: remove unused asic_reg/gmc headers
  drm/amd/include: remove unused asic_reg/smu headers
  drm/amd/include: remove unused asic_reg/umc headers
  drm/amd/include: remove unused asic_reg/uvd headers
  drm/amd/include: remove unused asic_reg/vce headers
  drm/amd/include: remove unused asic_reg/sdma headers
  drm/amd/include: remove unused asic_reg/nbif headers
  drm/amd/include: remove unused displayobject.h header
  drm/amd/powerplay: remove unused headers

 .../drm/amd/include/asic_reg/bif/bif_5_0_enum.h|  1198 --
 .../drm/amd/include/asic_reg/bif/bif_5_1_enum.h|  1068 -
 .../drm/amd/include/asic_reg/dce/dce_11_2_enum.h   |  6813 --
 .../drm/amd/include/asic_reg/dce/dce_8_0_enum.h|  1117 -
 .../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h   |  2791 ---
 .../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h|  6808 --
 .../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21368 ---
 .../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h|  1198 --
 .../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h|  1068 -
 .../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h   | 10281 -
 .../drm/amd/include/asic_reg/oss/oss_2_4_enum.h|  1340 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h  |  1464 --
 .../drm/amd/include/asic_reg/oss/oss_3_0_enum.h|  1497 --
 .../amd/include/asic_reg/sdma0/sdma0_4_0_default.h |   286 -
 .../amd/include/asic_reg/sdma1/sdma1_4_0_default.h |   282 -
 .../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h   |   148 -
 .../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h |   715 -
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h |  1344 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h  |  1191 --
 .../amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h   |  5648 -
 .../drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h  |  1205 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h  |  1246 --
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  |  1282 --
 .../drm/amd/include/asic_reg/smu/smu_8_0_enum.h|  1072 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_default.h |31 -
 .../drm/amd/include/asic_reg/umc/umc_6_0_offset.h  |52 -
 .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   795 -
 .../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h|  1211 --
 .../drm/amd/include/asic_reg/uvd/uvd_6_0_enum.h|  1081 -
 .../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h   |64 -
 .../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h |99 -
 drivers/gpu/drm/amd/include/displayobject.h|   249 -
 .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h|   412 -
 drivers/gpu/drm/amd/powerplay/inc/pp_feature.h |67 -
 34 files changed, 76491 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_2_4_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/oss/oss_3_0_enum.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma0/sdma0_4_0_default.h
 delete mode 100644 
drivers/gpu/drm/amd/include/asic_reg/sdma1/sdma1_4_0_default.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_8_0_enum.h
 delete mode 100644 

Re: [PATCH v2 22/30] drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 14 February 2018 10:31:17 EET Tomi Valkeinen wrote:
> Hi,
> 
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > The dss_device is the top-level component in the omapdss driver. Give
> > the omapdrm driver access to the dss_device pointer in order to obtain
> > pointers to all other components from it. This requires a new global
> > variable in the omapdss driver that will be removed when merging the
> > omapdrm and omapdss drivers, but will already allow removal of several
> > other global variables.
> 
> How can we support different DSS versions with this change? So far the
> DSS functions used from omapdrm have been designed to be free of DSS
> specific parameters, and in the TI kernel we have a separate DSS driver
> for the DSS6, and omapdrm "just works" with either DSS2-5 and DSS6.
> 
> We could have the "struct dss_device *dss" and "struct dispc_device
> *dispc" in omap_drv.h as "struct device" pointers instead.

From an omapdrm point of view the dss_device and dispc_device structures are 
opaque. We're free to do anything we want with them, from switching to struct 
device pointers to allow completely separate implementations of the DSS and 
DISPC on DSS2-5 and DSS6, or storing common data in struct dss_device and 
struct dispc_device, that we can then subclass with version-specific 
structures internally. I don't have a strong opinion at the moment as I 
haven't seen the DSS6 code and thus can't judge whether there's a need to 
share data and code. At this point what matters to me is making sure we always 
pass objects around explicitly to avoid global variables. We could go for 
struct device now and switch to something else later, or the other way around, 
or anything else that works for you.

> Alternatively, we could just create a totally new DRM driver for DSS6,
> having nothing in common with the current omapdrm. From naming
> perspective that would not be so bad, as OMAP is dead =). But if we ever
> get DSS7, perhaps that's again different enough that we don't want a
> single DSS driver for DSS6 and DSS7.

Again I haven't stupid the differences between DSS2-5 and DSS6 so I can't 
really comment, but being able to start from scratch without carrying device 
mistakes over is tempting. Of course that means we would just make different 
design mistakes :-)

-- 
Regards,

Laurent Pinchart

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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

--- Comment #18 from Ainola  ---
I applied the patch to 4.15.3 on archlinux and have tested with xset dpms force
{standby,suspend} with success.

-- 
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 v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Jordan Crouse]

On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
> Hi Jordan,
> 
> On Wed, Feb 14, 2018 at 1:42 AM, Jordan Crouse  wrote:
> > On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
> >> Hi Vivek,
> >>
> >> Thanks for the patch. Please see my comments inline.
> >>
> >> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> >>  wrote:
> >> > While handling the concerned iommu, there should not be a
> >> > need to power control the drm devices from iommu interface.
> >> > If these drm devices need to be powered around this time,
> >> > the respective drivers should take care of this.
> >> >
> >> > Replace the pm_runtime_get/put_sync() with
> >> > pm_runtime_get/put_suppliers() calls, to power-up
> >> > the connected iommu through the device link interface.
> >> > In case the device link is not setup these get/put_suppliers()
> >> > calls will be a no-op, and the iommu driver should take care of
> >> > powering on its devices accordingly.
> >> >
> >> > Signed-off-by: Vivek Gautam 
> >> > ---
> >> >  drivers/gpu/drm/msm/msm_iommu.c | 16 
> >> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c 
> >> > b/drivers/gpu/drm/msm/msm_iommu.c
> >> > index b23d33622f37..1ab629bbee69 100644
> >> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> >> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> >> > @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const 
> >> > char * const *names,
> >> > struct msm_iommu *iommu = to_msm_iommu(mmu);
> >> > int ret;
> >> >
> >> > -   pm_runtime_get_sync(mmu->dev);
> >> > +   pm_runtime_get_suppliers(mmu->dev);
> >> > ret = iommu_attach_device(iommu->domain, mmu->dev);
> >> > -   pm_runtime_put_sync(mmu->dev);
> >> > +   pm_runtime_put_suppliers(mmu->dev);
> >>
> >> For me, it looks like a wrong place to handle runtime PM of IOMMU
> >> here. iommu_attach_device() calls into IOMMU driver's attach_device()
> >> callback and that's where necessary runtime PM gets should happen, if
> >> any. In other words, driver A (MSM DRM driver) shouldn't be dealing
> >> with power state of device controlled by driver B (ARM SMMU).
> >
> > This whole thing is confused by the fact that on MSM the GPU and the GPU 
> > IOMMU
> > share some of the same clocks and power rail so turning on the GPU also
> > turned on the IOMMU register banks by extension.
> 
> This is surprisingly not a very surprising case. Exactly the same can
> be seen on Rockchip SoCs and we're solving the problem using the
> solution I suggested. In fact, my suggestions to this thread are based
> on the design we chose for Rockchip, due to the high level of
> similarity (+/- the GPU directly programming IOMMU registers, which is
> not present there, but AFAICT it doesn't pose a problem here).
> 
> >
> > But if we put that aside the question is who should be responsible for
> > controlling the power in this relationship and there are several good 
> > reasons to
> > leave it up to the client device. The most important reason is when we move 
> > to
> > the per-instance model where the GPU self-programmings the SMMU registers. 
> > In
> > that case, the driver will need to make sure that the SMMU is powered up 
> > before
> > submitting the command and then removing the power vote when the commands
> > are done to save energy.
> 
> I might need more insight on what's going on in your hardware, but
> with my current understanding I'd argue that that is not right,
> because:
> 
> - When submitting commands to the GPU, the GPU driver will
> pm_runtime_get_sync() on the GPU device, which will automatically do
> the same on all the linked suppliers, which would also include the
> SMMU itself. The role of device links here is exactly that the GPU
> driver doesn't have to care which other devices need to be brought up.

This is true.  Assuming that the device link works correctly we would not need
to explicitly power the SMMU which makes my point entirely moot.

> - When the GPU is operating, the SMMU power must be supplied anyway,
> because it needs to be doing the translations, right? Note that by
> "power" I really mean the physical power supply in the SoC, e.g. as
> for a power domain. The runtime PM API in its current form (e.g.
> binary off or on operation) is unsuitable for managing other things,
> such as clocks (and there is ongoing work on improving it, e.g. by
> adding support for multiple power states).

As others have pointed out, the register banks and the translation unit are
powered separately (or at least, clocked separately).

>^^ The above would be actually guaranteed by your hardware design,
> where SMMU and GPU share the power domain and clocks. (We used to rely
> on this in old downstream implementation of Rockchip IOMMU and master
> drivers in Chromium OS kernel, before we moved to handling the clocks
> explicitly in 

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Robin Murphy]

On 14/02/18 10:33, Vivek Gautam wrote:

On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa  wrote:

Adding Jordan to this thread as well.


On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
 wrote:

Hi Tomasz,

On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
 wrote:

Hi Tomasz,

On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark  wrote:

On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa  wrote:

On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark  wrote:

On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa  wrote:

Hi Vivek,

Thanks for the patch. Please see my comments inline.

On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
 wrote:

While handling the concerned iommu, there should not be a
need to power control the drm devices from iommu interface.
If these drm devices need to be powered around this time,
the respective drivers should take care of this.

Replace the pm_runtime_get/put_sync() with
pm_runtime_get/put_suppliers() calls, to power-up
the connected iommu through the device link interface.
In case the device link is not setup these get/put_suppliers()
calls will be a no-op, and the iommu driver should take care of
powering on its devices accordingly.

Signed-off-by: Vivek Gautam 
---
  drivers/gpu/drm/msm/msm_iommu.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..1ab629bbee69 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char * 
const *names,
 struct msm_iommu *iommu = to_msm_iommu(mmu);
 int ret;

-   pm_runtime_get_sync(mmu->dev);
+   pm_runtime_get_suppliers(mmu->dev);
 ret = iommu_attach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
+   pm_runtime_put_suppliers(mmu->dev);


For me, it looks like a wrong place to handle runtime PM of IOMMU
here. iommu_attach_device() calls into IOMMU driver's attach_device()
callback and that's where necessary runtime PM gets should happen, if
any. In other words, driver A (MSM DRM driver) shouldn't be dealing
with power state of device controlled by driver B (ARM SMMU).


Note that we end up having to do the same, because of iommu_unmap()
while DRM driver is powered off..  it might be cleaner if it was all
self contained in the iommu driver, but that would make it so other
drivers couldn't call iommu_unmap() from an irq handler, which is
apparently something that some of them want to do..


I'd assume that runtime PM status is already guaranteed to be active
when the IRQ handler is running, by some other means (e.g.
pm_runtime_get_sync() called earlier, when queuing some work to the
hardware). Otherwise, I'm not sure how a powered down device could
trigger an IRQ.

So, if the master device power is already on, suppliers should be
powered on as well, thanks to device links.



umm, that is kindof the inverse of the problem..  the problem is
things like gpu driver (and v4l2 drivers that import dma-buf's,
afaict).. they will potentially call iommu->unmap() when device is not
active (due to userspace or things beyond the control of the driver)..
so *they* would want iommu to do pm get/put calls.


Which is fine and which is actually already done by one of the patches
in this series, not for map/unmap, but probe, add_device,
remove_device. Having parts of the API doing it inside the callback
and other parts outside sounds at least inconsistent.


But other drivers
trying to unmap from irq ctx would not.  Which is the contradictory
requirement that lead to the idea of iommu user powering up iommu for
unmap.


Sorry, maybe I wasn't clear. My last message was supposed to show that
it's not contradictory at all, because "other drivers trying to unmap
from irq ctx" would already have called pm_runtime_get_*() earlier
from a non-irq ctx, which would have also done the same on all the
linked suppliers, including the IOMMU. The ultimate result would be
that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync()
would do nothing besides incrementing the reference count.


The entire point was to avoid the slowpath that pm_runtime_get/put_sync()
would add in map/unmap. It would not be correct to add a slowpath in irq_ctx
for taking care of non-irq_ctx and for the situations where master is already
powered-off.


Correct me if I'm wrong, but I believe that with what I'm proposing
there wouldn't be any slow path.


Yea, but only when the power domain is irq-safe? And not all platforms
enable irq-safe power domains. For instance, msm doesn't enable its

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Rob Clark]

On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse  wrote:
> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>
>> - When submitting commands to the GPU, the GPU driver will
>> pm_runtime_get_sync() on the GPU device, which will automatically do
>> the same on all the linked suppliers, which would also include the
>> SMMU itself. The role of device links here is exactly that the GPU
>> driver doesn't have to care which other devices need to be brought up.
>
> This is true.  Assuming that the device link works correctly we would not need
> to explicitly power the SMMU which makes my point entirely moot.

Just to point out what motivated this patchset, the biggest problem is
iommu_unmap() because that can happen when GPU is not powered on (or
in the v4l2 case, because some other device dropped it's reference to
the dma-buf allowing it to be free'd).  Currently we pm get/put the
GPU device around unmap, but it is kinda silly to boot up the GPU just
to unmap a buffer.

(Semi-related, I would also like to batch map/unmap's, I just haven't
gotten around to implementing it yet.. but that would be another case
where a single get_supplier()/put_supplier() outside of the iommu
would make sense instead of pm_get/put() inside the iommu driver's
->unmap().)

If you really dislike the get/put_supplier() approach, then perhaps we
need iommu_pm_get()/iommu_pm_put() operations that the iommu user
could use to accomplish the same thing?

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

Re: [PATCH 2/3] DT: display: renesas, lvds: document R8A77970 bindings

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 19 January 2018 20:29:20 EET Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car LVDS bindings.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
>  1 file changed, 1 insertion(+)
> 
> Index:
> linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> === ---
> linux.orig/Documentation/devicetree/bindings/display/bridge/renesas,lvds.tx
> t +++
> linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@
> -13,6 +13,7 @@ Required properties:
>- "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS
> encoders - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS
> encoders - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS
> encoders +  - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible
> LVDS encoders
> 
>  - reg: Base address and length for the memory-mapped registers
>  - clocks: A phandle + clock-specifier pair for the functional clock

-- 
Regards,

Laurent Pinchart

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

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
(In reply to arne_woerner from comment #17)
> yup:
> i mean: i did not test, which one is necessary...
> so i cannot say, if all three r necessary, or if just one/two of them
> suffice...
> 
> tomorrow i will test "amdgpu.audio=0 amdgpu.msi=0"...
> with the stable linux-firmware package... right?
> 
> or do u mean just "amdgpu.msi=0"?
> maybe hdmi audio works already, if amdgpu.msi is 0?

I doubt the audio parameter would affect anything in this regard, but you said
it was required for the board to work properly?  Is that the case or am I
misinterpreting you?  For audio on your board, you need to enable DC which is
only available on kernel 4.15 and newer.  You can boot with amdgpu.dc=1 to
enable DC.  The msi option may help narrow down the interrupt issue.  If it
helps, it seems MSIs are not working properly on your system after resume. 
This would probably be something outside of the driver if it's a regression.

-- 
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 v2 0/3] R-Car DU: Fix and refactor LVDS to prepare for V3M support

[Laurent Pinchart]

Hello, 

This patch series fixes the LVDS startup sequence for Gen2 and Gen3
SoCs, and then proceeds to refactoring the code to merge the Gen2 and
Gen3 implementations in preparation for V3M support.

The patches have been previously posted as part of the following series.

[PATCH 0/2] Fix LVDS startup sequences in the R-Car DU driver...
[PATCH 0/3] Add R-Car V3M (R8A77970) support to the R-Car LVDS driver

They have since been rebased on top of the latest DU driver and the
current DRM -next branch.

For convenience the patches can be found at

git://linuxtv.org/pinchartl/media.git drm/next/du

They have been tested on H2 (Lager), H3 ES1.1 (Salvator-X) and H3 ES2.0
(Salvator-XS) without any issue.

The patches that add V3M support have been left out as they depend on
the LVDS encoder move to the DRM bridge API that is not ready for
upstream yet.

Sergei Shtylyov (3):
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
  drm: rcar-du: lvds: Refactor LVDS startup

 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 128 --
 1 file changed, 51 insertions(+), 77 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH v2 1/3] drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2

[Laurent Pinchart]

From: Sergei Shtylyov 

According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index abbb7b25129a..dcffd3b59b69 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
-   /*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
-*/
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
+   /* Select the input and set the LVDS mode. */
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
@@ -73,6 +70,10 @@ static void rcar_du_lvdsenc_start_gen2(struct 
rcar_du_lvdsenc *lvds,
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
 
+   /* Enable LVDS operation and turn bias circuitry on. */
+   lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/*
 * Turn the PLL on, wait for the startup delay, and turn the output
 * on.
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm: rcar-du: lvds: Fix LVDS clock frequency range

[Sergei Shtylyov]

On 01/13/2018 12:40 AM, Laurent Pinchart wrote:

> According to the latest versions of both the Gen2 and Gen3 datasheets,
> the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all

   Not quite so with R-Car D3/E3 (which have the low boundary of 5 MHz) But we 
don't
support them yet anyway...

> SoCs. Update the driver accordingly.
> 
> Signed-off-by: Laurent Pinchart 
[...]

Acked-by: Sergei Shtylyov 

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

Re: [PATCH 3/3] drm: rcar-du: lvds: add R8A77970 support

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 19 January 2018 20:29:21 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the LVDS encoder driver.
> Note that there are some differences with the other R-Car gen3 SoCs, e.g.
> LVDPLLCR has the same layout as in the R-Car gen2 SoCs...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/gpu/drm/rcar-du/rcar_lvds.c |   21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -32,6 +32,10 @@ enum rcar_lvds_mode {
>  };
> 
>  #define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3 
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1)  /* LVDPLLCR has gen2-like */
> + /* layout on R8A77970 */
> +#define RCAR_LVDS_QUIRK_PHY  (1 << 2)/* LVDS has PHY on R8A77970 */
> + /* and  R8A7799{0|5} */

I'm not sure if that's the right explanation for this quirk. I assume the LVDS 
encoder to always have a PHY. The difference here is that it needs to be 
explicitly enabled. Note that the LVEN bit also exists in Gen2.

>  struct rcar_lvds_device_info {
>   unsigned int gen;
> @@ -162,6 +166,7 @@ static void rcar_lvds_enable(struct drm_
>*/
>   struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
>   const struct drm_display_mode *mode = >display_mode;
> + unsigned int quirks = lvds->info->quirks;
>   unsigned int gen = lvds->info->gen;
>   u32 lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
>   u32 lvdpllcr;
> @@ -186,7 +191,7 @@ static void rcar_lvds_enable(struct drm_
>   LVDCTRCR_CTR2SEL_DISP | LVDCTRCR_CTR1SEL_VSYNC |
>   LVDCTRCR_CTR0SEL_HSYNC);
> 
> - if (lvds->info->quirks & RCAR_LVDS_QUIRK_LANES)
> + if (quirks & RCAR_LVDS_QUIRK_LANES)
>   lvdhcr = LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CHSEL_CH(1, 3)
> 
>  | LVDCHCR_CHSEL_CH(2, 2) | LVDCHCR_CHSEL_CH(3, 1);
> 
>   else
> @@ -195,7 +200,7 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> 
>   /* PLL clock configuration */
> - if (gen < 3)
> + if (gen < 3 || quirks & RCAR_LVDS_QUIRK_GEN2_PLLCR)

I'd set the RCAR_LVDS_QUIRK_GEN2_PLLCR flag in all the Gen2 
rcar_lvds_device_info instances, and remove the gen check here.

>   lvdpllcr = rcar_lvds_lvdpllcr_gen2(mode->clock);
>   else
>   lvdpllcr = rcar_lvds_lvdpllcr_gen3(mode->clock);
> @@ -227,6 +232,12 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
>   }
> 
> + if (quirks & RCAR_LVDS_QUIRK_PHY) {
> + /* Turn on the LVDS PHY. */
> + lvdcr0 |= LVDCR0_LVEN;
> + rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + }
> +
>   /* Wait for the startup delay. */
>   usleep_range(100, 150);
> 
> @@ -499,6 +510,11 @@ static const struct rcar_lvds_device_inf
>   .gen = 3,
>  };
> 
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77970_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_PHY,
> +};
> +
>  static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
> },
> @@ -506,6 +522,7 @@ static const struct of_device_id rcar_lv
>   { .compatible = "renesas,r8a7793-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
>   { .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
> + { .compatible = "renesas,r8a77970-lvds", .data = 
> _lvds_r8a77970_info
> }, { }
>  };

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

[Sylwester Nawrocki]

Hi Inki,

On 02/14/2018 06:57 AM, Inki Dae wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a4b75a46f946..abd84cbcf1c2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1068,10 +1068,13 @@ static void hdmi_audio_config(struct hdmi_context 
>> *hdata)
>>  /* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
>>  hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
>>  | HDMI_I2S_SEL_LRCK(6));
>> -hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
>> -| HDMI_I2S_SEL_SDATA2(4));
>> +
>> +hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(3)
>
> Seems you fixed pin_sel_3 field value of I2S_PIN_SEL_1 register. According 
> to datasheet, 0x3 should be set to this field to select SDATA_1 not 0x1.
> So could you update the description of this patch?

Indeed, I finally missed that when I was writing the commit message. 
I've posted v2 already.

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

[PATCH v2] drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

[Sylwester Nawrocki]

Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
constant and adds missing HDMI_I2S_SEL_DATA0.
The value of bit field selecting SDATA_1 (pin_sel_3) is also changed,
so it is 3 as suggested in the Exynos TRMs.

Signed-off-by: Sylwester Nawrocki 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
 drivers/gpu/drm/exynos/regs-hdmi.h   | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a4b75a46f946..abd84cbcf1c2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1068,10 +1068,13 @@ static void hdmi_audio_config(struct hdmi_context 
*hdata)
/* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
| HDMI_I2S_SEL_LRCK(6));
-   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
-   | HDMI_I2S_SEL_SDATA2(4));
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(3)
+   | HDMI_I2S_SEL_SDATA0(4));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_2, HDMI_I2S_SEL_SDATA3(1)
| HDMI_I2S_SEL_SDATA2(2));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_3, HDMI_I2S_SEL_DSD(0));
 
/* I2S_CON_1 & 2 */
diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index 04be0f7e8193..4420c203ac85 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -464,7 +464,7 @@
 
 /* I2S_PIN_SEL_1 */
 #define HDMI_I2S_SEL_SDATA1(x) (((x) & 0x7) << 4)
-#define HDMI_I2S_SEL_SDATA2(x) ((x) & 0x7)
+#define HDMI_I2S_SEL_SDATA0(x) ((x) & 0x7)
 
 /* I2S_PIN_SEL_2 */
 #define HDMI_I2S_SEL_SDATA3(x) (((x) & 0x7) << 4)
-- 
2.14.2

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

Re: [RFC PULL] Add Display Support for Qualcomm SDM845

[jsanka]

On 2/13/2018 12:00 PM, Rob Clark wrote:

On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul  wrote:

Hi dri-devel,
Qualcomm has been working for the past few weeks on forward porting their
downstream drm driver from 4.14 to mainline. Please consider this PR as a
request for review, rather than an attempt at mainlining the code as it
currently stands. The goal is get this driver in shape over the next coming
months.

In the meantime, I'll be hosting a tree here [1] to stage the fixes. Patches
will be posted and reviewed on linux-arm-...@vger.kernel.org. Once things look
good, I'll send another pull 4realz.

To get the ball rolling, I've done some review on the new connector code, my
comments are below.

Thanks in advance for your constructive feedback :)

Sean

[1]- git://people.freedesktop.org/~seanpaul/dpu-staging

Review feedback:


just so others aren't confused, s/sde/dpu/g in the list below (we did
our DAL->DC rename before sending first RFC :-P)


- Solve the splash screen handling (or remove it)
- Simplify devicetree binding (remove register offsets)
feedback from reviewing sde_connector.c:
- Rationalize backlight implementation in sde_connector (display_count static)
- Sort out the dsi event passing between dsi/encoder/connector (move to encoder)
- include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)
- connector->state access violations reading/writing mode_info
- s/sde_rect/drm_rect/
- sde_kms_info usage needs to be replaced with formal data structures (not
   stringified keypairs)
- sde_connector_ops needs to be trimmed, duplicates connector helpers, info
   hooks circumvent state, and other hooks should be stored in state or
   prepopulated (get_dst_format)
- sde_connector_get_dpms unused
- esd status check should migrate to encoder from connector
- backlight should be handled in panel drivers, not in the generic connector/dsi
   encoder
- sde_connector_helper_bridge_disable is called from encoder and calls back into
   set_power encoder function. if backlight, and esd status are removed,
   pre_kickoff can probably go away
- sde_connector_clk_ctrl is another example of encoder->connector->encoder call
- RETIRE_FENCE connector property should be removed, opting for the native
   atomic fences
- ROI (regions of interest) should be expressed per-plane instead of connector.
   there is work ongoing to support dirty_rects per-plane by Deepak Singh Rawat
    and Lukasz Spintzyk 
- Uma Shankar  has proposed HDR source metadata
   properties on the list, we should pivot to those instead of hand-rolling them
   in the sde driver
- Convert HDCP implementation to upstream Content Protection property
- Merge dsi and dsi_staging into one driver
- Writeback connector has been proposed by ARM (Liviu Dudau and Brian Starkey),
   we should work with their proposal instead of rolling OUT_FB ourselves
- sde_connector_set_property should be replaced with atomic helper
- dsi hotplug can probably be punted to the panel driver
- dpms should switch to enable/disable (or at least use the atomic helpers)
- dsi mode handling should also defer to the panel driver
- SDE_WB_CONFIG ioctl should be removed in favor of the existing ioctl to add
   user-defined modes
- dp implementation should use the existing dp helpers wherever possible
- lots of duplicated structures in dsi_defs.h that can be replaced with existing
   drm structs
- mode_valid should be split up and implemented directly in connector/encoder as
   appropriate
- sde_connector->aspace seems like it's unused?


To add to that, a few things I've noticed (but I've mostly only gotten
as far as the front-end of the pipeline, ie. dpu_plane):

  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
there are still unequal capabilities for planes (ie. some can do YUV,
scaling, etc).

But drm-hwc (or weston) isn't going to know about that, so I think we'll
need to add support for dynamically assigning dpu_plane::pipe, similar
to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
for drm-hwc ;-))
We are working on plane virtualization focused primarily to support 4K / 
wider displays which cannot
be catered by one hwpipe. The plan is to gang up two *fixed* hwpipes of 
similar capabilities (in terms of formats,
sub hw blocks like scalar, post processing ) and expose them as a single 
plane so that user space
compositor ( drm-hwc or weston) need not worry about max pixel width 
supported by the planes. But mapping
planes <-> hwpipe dynamically may need more than just virtualization. 
Kernel need to keep track of hwpipes
especially when dealing with multiple displays. And it get complicated 
when planes start moving around CRTC's

for different sized buffers.

Given that DRM exposes planes with its own list of format/modifiers, I 
think its not that big of a deal for a

compositor to 

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

[Rob Clark]

On Wed, Feb 14, 2018 at 1:46 AM, Bjorn Andersson
 wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on 8974 and is likely the cause of the additional
> CP_WAIT_FOR_IDLE workaround found for a306, which would cause the CP to
> wait for the GPU to go idle before triggering the interrupt.
>
> Instead we can set the (undocumented) BIT(31) of the CACHE_FLUSH_TS
> which will cause a special CACHE_FLUSH_TS interrupt to be triggered from
> the GPU as the write event is processed.
>
> Add CACHE_FLUSH_TS to the IRQ masks of A3xx and A4xx and remove the
> workaround for A306.
>
> Suggested-by: Jordan Crouse 
> Signed-off-by: Bjorn Andersson 
> ---
>
> This is only tested on 8974.

Tested on db410c (8016).. thanks

BR,
-R

>
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 ++
>  3 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 4baef2738178..a3a43be920d0 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -35,6 +35,7 @@
>  A3XX_INT0_CP_RB_INT | \
>  A3XX_INT0_CP_REG_PROTECT_FAULT |  \
>  A3XX_INT0_CP_AHB_ERROR_HALT | \
> +A3XX_INT0_CACHE_FLUSH_TS |\
>  A3XX_INT0_UCHE_OOB_ACCESS)
>
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index 8199a4b9f2fa..b44cd0d90621 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -27,6 +27,7 @@
>  A4XX_INT0_CP_RB_INT | \
>  A4XX_INT0_CP_REG_PROTECT_FAULT |  \
>  A4XX_INT0_CP_AHB_ERROR_HALT | \
> +A4XX_INT0_CACHE_FLUSH_TS |\
>  A4XX_INT0_UCHE_OOB_ACCESS)
>
>  extern bool hang_debug;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index de63ff26a062..5806f9942514 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -293,26 +293,12 @@ void adreno_submit(struct msm_gpu *gpu, struct 
> msm_gem_submit *submit,
> OUT_RING(ring, 0x);
> }
>
> +   /* BIT(31) of CACHE_FLUSH_TS triggers CACHE_FLUSH_TS IRQ from GPU */
> OUT_PKT3(ring, CP_EVENT_WRITE, 3);
> -   OUT_RING(ring, CACHE_FLUSH_TS);
> +   OUT_RING(ring, CACHE_FLUSH_TS | BIT(31));
> OUT_RING(ring, rbmemptr(ring, fence));
> OUT_RING(ring, submit->seqno);
>
> -   /* we could maybe be clever and only CP_COND_EXEC the interrupt: */
> -   OUT_PKT3(ring, CP_INTERRUPT, 1);
> -   OUT_RING(ring, 0x8000);
> -
> -   /* Workaround for missing irq issue on 8x16/a306.  Unsure if the
> -* root cause is a platform issue or some a306 quirk, but this
> -* keeps things humming along:
> -*/
> -   if (adreno_is_a306(adreno_gpu)) {
> -   OUT_PKT3(ring, CP_WAIT_FOR_IDLE, 1);
> -   OUT_RING(ring, 0x);
> -   OUT_PKT3(ring, CP_INTERRUPT, 1);
> -   OUT_RING(ring, 0x8000);
> -   }
> -
>  #if 0
> if (adreno_is_a3xx(adreno_gpu)) {
> /* Dummy set-constant to trigger context rollover */
> --
> 2.15.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3

[Laurent Pinchart]

From: Sergei Shtylyov 

According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
[Updated comment in rcar_du_lvdsenc_start_gen3()]
[Moved Gen2 startup comment update to separate commit]
[Fixed =| typo]
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index dcffd3b59b69..01ef0f728e94 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -95,7 +95,7 @@ static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc 
*lvds,
u32 lvdcr0;
u32 pllcr;
 
-   /* PLL clock configuration */
+   /* Set the PLL clock configuration and LVDS mode. */
if (freq < 42000)
pllcr = LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
@@ -107,6 +107,9 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/* Turn all the channels on. */
rcar_lvds_write(lvds, LVDCR1,
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
@@ -116,7 +119,7 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
+   lvdcr0 |= LVDCR0_PLLON;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
 
lvdcr0 |= LVDCR0_PWD;
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 3/3] drm: rcar-du: lvds: Refactor LVDS startup

[Laurent Pinchart]

From: Sergei Shtylyov 

After the recent corrections to the R-Car gen2/3 LVDS startup code, already
similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
a merge and it's becoming actually necessary with the addition of the R-Car
V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.

Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 132 --
 1 file changed, 51 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index 01ef0f728e94..4defa8123eb2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -39,102 +39,37 @@ static void rcar_lvds_write(struct rcar_du_lvdsenc *lvds, 
u32 reg, u32 data)
iowrite32(data, lvds->mmio + reg);
 }
 
-static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
-
-   /* PLL clock configuration */
if (freq < 39000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
else if (freq < 61000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
else if (freq < 121000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | 
LVDPLLCR_PLLDLYCNT_121M;
+   return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
else
-   pllcr = LVDPLLCR_PLLDLYCNT_150M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   /* Select the input and set the LVDS mode. */
-   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
-   if (rcrtc->index == 2)
-   lvdcr0 |= LVDCR0_DUSEL;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /* Enable LVDS operation and turn bias circuitry on. */
-   lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /*
-* Turn the PLL on, wait for the startup delay, and turn the output
-* on.
-*/
-   lvdcr0 |= LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDLYCNT_150M;
 }
 
-static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
-
-   /* Set the PLL clock configuration and LVDS mode. */
if (freq < 42000)
-   pllcr = LVDPLLCR_PLLDIVCNT_42M;
+   return LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
-   pllcr = LVDPLLCR_PLLDIVCNT_85M;
+   return LVDPLLCR_PLLDIVCNT_85M;
else if (freq < 128000)
-   pllcr = LVDPLLCR_PLLDIVCNT_128M;
+   return LVDPLLCR_PLLDIVCNT_128M;
else
-   pllcr = LVDPLLCR_PLLDIVCNT_148M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /*
-* Turn the PLL on, set it to LVDS normal mode, wait for the startup
-* delay and turn the output on.
-*/
-   lvdcr0 |= LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   lvdcr0 |= LVDCR0_PWD;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDIVCNT_148M;
 }
 
 static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
 struct rcar_du_crtc *rcrtc)
 {
+   

Re: [PULL] drm/i915: Add HDCP support to i915

[Sean Paul]

On Wed, Feb 14, 2018 at 02:48:29PM +0100, Hans Verkuil wrote:
> On 14/02/18 14:44, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 3:33 AM, Hans Verkuil  wrote:
> >> Hi Sean,
> >>
> >> On 13/02/18 21:18, Sean Paul wrote:
> >>>
> >>> Hi Dave,
> >>> Here's the pull request for HDCP. Hopefully no surprises since it's been 
> >>> baking
> >>> in drm-tip for a while now.
> >>>
> >>> topic/hdcp-2018-02-13:
> >>> Add HDCP support to i915 drm driver.
> >>>
> >>> Cheers, Sean
> >>>
> >>>
> >>> The following changes since commit 
> >>> b0caa1333b6d2d928a00304e9fb6674526c37b79:
> >>>
> >>>   Merge tag 'imx-drm-next-2018-01-02' of 
> >>> git://git.pengutronix.de/git/pza/linux into drm-next (2018-01-05 11:33:24 
> >>> +1000)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13
> >>>
> >>> for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289:
> >>>
> >>>   drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 
> >>> -0500)
> >>>
> >>> 
> >>> Add HDCP support to i915 drm driver.
> >>>
> >>> 
> >>> Chris Wilson (1):
> >>>   drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
> >>>
> >>> Ramalingam C (12):
> >>>   drm/i915: Extending HDCP for HSW, BDW and BXT+
> >>>   drm/i915: II stage HDCP auth for repeater only
> >>>   drm/i915: Start repeater auth on READY/CP_IRQ
> >>>   drm/i915: Check for downstream topology errors
> >>>   drm/i915: Handle failure from 2nd stage HDCP auth
> >>>   drm/i915: Stop encryption for repeater with no sink
> >>>   drm/i915: Connector info in HDCP debug msgs
> >>>   drm/i915: Retry HDCP bksv read
> >>>   drm/i915: Optimize HDCP key load
> >>>   drm/i915: Detect panel's hdcp capability
> >>>   drm/i915: Reauthenticate HDCP on failure
> >>>   drm/i915: fix misalignment in HDCP register def
> >>
> >> Were these ever posted to dri-devel? I can't find them there.
> >>
> >> Do these patches from Ramalingam C add repeater support to the i915?
> >> If so, then I am certainly interested in seeing these since we (Cisco)
> >> are working on HDCP (including repeater support) for HDMI receivers.
> >>
> > 
> > Hi Hans!
> > We had a conversation on these patches and repeater support when I
> > initially posted them :-)
> > https://lists.freedesktop.org/archives/intel-gfx/2017-December/149112.html
> 
> Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen.
> At least not on dri-devel. It's a bit weird.

Ahh, I'm sorry I misunderstood. I think Ram may have sent those to intel-gfx
exclusively.

Repeater support was introduced in the initial post. Ram's changes mainly focus
on HDCP compliance.

Sean

> 
> Regards,
> 
>   Hans
> 
> > 
> > It'd be great if you could try it out and report back.
> > 
> > Cheers,
> > 
> > Sean
> > 
> >> Nothing public yet, it's too early for that. But it would be nice to
> >> test with the i915 driver.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>>
> >>> Sean Paul (13):
> >>>   drm: Fix link-status kerneldoc line lengths
> >>>   drm/i915: Add more control to wait_for routines
> >>>   drm: Add Content Protection property
> >>>   drm: Add some HDCP related #defines
> >>>   drm/i915: Add HDCP framework + base implementation
> >>>   drm/i915: Make use of indexed write GMBUS feature
> >>>   drm/i915: Add function to output Aksv over GMBUS
> >>>   drm/i915: Implement HDCP for HDMI
> >>>   drm/i915: Implement HDCP for DisplayPort
> >>>   drm/i915: Don't allow HDCP on PORT E/F
> >>>   drm/i915: Only disable HDCP when it's active
> >>>   drm/i915: Restore HDCP DRM_INFO when with no downstream
> >>>   drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS
> >>>
> >>>  drivers/gpu/drm/drm_atomic.c |   8 +
> >>>  drivers/gpu/drm/drm_connector.c  |  87 +++-
> >>>  drivers/gpu/drm/i915/Makefile|   1 +
> >>>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
> >>>  drivers/gpu/drm/i915/i915_reg.h  |  86 
> >>>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
> >>>  drivers/gpu/drm/i915/intel_ddi.c |  36 ++
> >>>  drivers/gpu/drm/i915/intel_display.c |   4 +
> >>>  drivers/gpu/drm/i915/intel_dp.c  | 277 +++-
> >>>  drivers/gpu/drm/i915/intel_drv.h | 109 -
> >>>  drivers/gpu/drm/i915/intel_hdcp.c| 807 
> >>> +++
> >>>  drivers/gpu/drm/i915/intel_hdmi.c| 250 +++
> >>>  drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
> >>>  drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
> >>>  drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
> >>>  include/drm/drm_connector.h  |  16 +
> >>>  include/drm/drm_dp_helper.h  |  17 +
> >>>  include/drm/drm_hdcp.h   |  41 ++
> >>>  include/uapi/drm/drm_mode.h  |   

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #5 from Francesco Turco  ---
I just finished trying kernel 4.15.3 with the QupZilla web browser (instead of
Qutebrowser). Unfortunately it still crashes.

-- 
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: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

[Meelis Roos]

> Actually this was brought up to me already, there's a fix on the mailing list
> for this I reviewed a little while ago from nvidia that we should pull in:
> 
> https://patchwork.freedesktop.org/patch/203205/
> 
> Would you guys mind confirming that this patch fixes your issues?

It works on my amd64, P4 is still compiling.

[1.124987] nouveau :04:05.0: NVIDIA NV05 (20154000)
[1.161464] nouveau :04:05.0: bios: version 03.05.00.10.00
[1.161475] nouveau :04:05.0: bios: DCB table not found
[1.161535] nouveau :04:05.0: bios: DCB table not found
[1.161577] nouveau :04:05.0: bios: DCB table not found
[1.161586] nouveau :04:05.0: bios: DCB table not found
[1.344008] tsc: Refined TSC clocksource calibration: 2200.078 MHz
[1.344024] clocksource: tsc: mask: 0x max_cycles: 
0x1fb67c69f81, max_idle_ns: 440795210317 ns
[1.344037] clocksource: Switched to clocksource tsc
[1.408102] nouveau :04:05.0: tmr: unknown input clock freq
[1.409471] nouveau :04:05.0: fb: 32 MiB SDRAM
[1.414459] nouveau :04:05.0: DRM: VRAM: 31 MiB
[1.414467] nouveau :04:05.0: DRM: GART: 128 MiB
[1.414476] nouveau :04:05.0: DRM: BMP version 5.17
[1.414484] nouveau :04:05.0: DRM: No DCB data found in VBIOS
[1.415629] nouveau :04:05.0: DRM: Adaptor not initialised, running 
VBIOS init tables.
[1.415829] nouveau :04:05.0: bios: DCB table not found
[1.416125] nouveau :04:05.0: DRM: Saving VGA fonts
[1.477526] nouveau :04:05.0: DRM: No DCB data found in VBIOS
[1.478428] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.478438] [drm] Driver supports precise vblank timestamp query.
[1.479618] nouveau :04:05.0: DRM: MM: using M2MF for buffer copies
[1.517930] nouveau :04:05.0: DRM: allocated 1024x768 fb: 0x4000, bo 
a09f4d1f
[1.519294] nouveau :04:05.0: fb1: nouveaufb frame buffer device
[1.519313] [drm] Initialized nouveau 1.3.1 20120801 for :04:05.0 on 
minor 1


-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Laurent Pinchart]

Hi Sergei,

On Tuesday, 16 January 2018 17:42:41 EET Laurent Pinchart wrote:
> On Saturday, 13 January 2018 11:25:31 EET Sergei Shtylyov wrote:
> > On 1/13/2018 1:15 AM, Laurent Pinchart wrote:
>  According to the latest revisions of the R-Car gen3 manual, the LVDS
>  mode must be set before the LVDS I/O pins are enabled, not after -- 
>  fix the gen3 LVDS startup sequence accordingly...
>  
>  While  at it,  also fix the comment  preceding the first LVDCR0 write
>  in the R-Car gen2 startup code that still talks about hardcoding the
>  LVDS mode 0...
> >>> 
> >>> How about fixing that in patch 2/2 that touches the Gen2 initialization
> >>> sequence ? I think I'd even go as far as squashing both patches, I
> >>> don't think there's a need to split them.
> >>> 
>  Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode
>  selection")
>  Signed-off-by: Sergei Shtylyov 
> >>> 
> >>> Is this really needed ? Does it fix a problem you've experienced, or is
> >>> it theoretical only ? The mode shouldn't matter before the LVDS
> >>> internal logic is turned on. Unless there's a real issue I'm not sure we
> >>> should make the code more complex.
> >> 
> >> Furthermore the datasheet states
> >> 
> >> "3. This refers to settings other than those that are concerned with
> >> LVDS-IF startup. These items may be set while waiting for the conditions
> >> of step 6 to be met."
> > 
> > Ah, I hadn't paid much attention to this note. Howeve, it seems quite
> > vague to me... and there's no condition in step 6. ;-)
> 
> Lots of bits and pieces are lost in translation yes :-)
> 
> >> Doesn't this mean that the mode and input selector don't have to be set
> >> as the very first step, but can be programmed at any point before
> >> starting the LVDS encoder through the PWD bit (on Gen3) or the PLLON bit
> >> (on Gen2) ?
> > 
> > Frankly speaking, I don't know how to interpret that note...
> 
> My understanding is that the parameters can be programmed at any time before
> step 6. The fact that the current code works seems to confirm that
> interpretation. We could ask Renesas for a confirmation if you want.

I've received feedback, and while it wasn't clear what the not really means, 
Renesas recommends following the documented startup sequence (I'm still not 
sure it's really needed, but that's a different story). I'll thus rebase this 
patch and repost it, and take it in my tree if you're fine with the result.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/2] drm/msm/adreno: Add A6XX device support

[Jordan Crouse]

On Thu, Feb 01, 2018 at 11:32:25AM +0100, Lucas Stach wrote:
> Hi Jordan,
> 
> just some drive-by comments:

Drive by comments are the best.

> Am Mittwoch, den 31.01.2018, 11:25 -0700 schrieb Jordan Crouse:
> > Add support for the A6XX family of Adreno GPUs. The biggest addition
> > is the GMU (Graphics Management Unit) which takes over most of the
> > power management of the GPU itself but in a ironic twist of fate
> > needs a goodly amount of management itself. Add support for the
> > A6XX core code, the GMU and the HFI (hardware firmware interface)
> > queue that the CPU uses to communicate with the GMU.
> > 
> > > Signed-off-by: Jordan Crouse 
> > ---
> [...]
> > +static int a6xx_hfi_queue_read(struct a6xx_hfi_queue *queue, u32 *data,
> > > + u32 dwords)
> > +{
> > > + struct a6xx_hfi_queue_header *header = queue->header;
> > > + u32 i, hdr, index = header->read_index;
> > +
> > > + if (header->read_index == header->write_index) {
> > > + header->rx_request = 1;
> > > + return 0;
> > > + }
> > +
> > > + hdr = queue->data[index];
> > +
> > > + /*
> > > +  * If we are to assume that the GMU firmware is in fact a rational actor
> > > +  * and is programmed to not send us a larger response than we expect
> > > +  * then we can also assume that if the header size is unexpectedly large
> > > +  * that it is due to memory corruption and/or hardware failure. In this
> > > +  * case the only reasonable course of action is to BUG() to help harden
> > > +  * the failure.
> > > +  */
> > +
> > +   BUG_ON(HFI_HEADER_SIZE(hdr) > dwords);
> 
> Don't ever BUG the kernel due to a peripheral acting up, until you are
> really certain that it has corrupted memory it doesn't own, which would
> be written back to persistent storage. That's the only valid
> justification for a BUG.

Acknowledged. In the final version we'll try to zap the hardware and recover
cleanly but I don't have that coded up yet.  Don't worry, I wouldn't let it
merge with a BUG().

> > +
> > > + for (i = 0; i < HFI_HEADER_SIZE(hdr); i++) {
> > > + data[i] = queue->data[index];
> > > + index = (index + 1) % header->size;
> > > + }
> > +
> > > + header->read_index = index;
> > > + return HFI_HEADER_SIZE(hdr);
> > +}
> > +
> > +static int a6xx_hfi_queue_write(struct a6xx_gmu *gmu,
> > > + struct a6xx_hfi_queue *queue, u32 *data, u32 dwords)
> > +{
> > > + struct a6xx_hfi_queue_header *header = queue->header;
> > > + u32 i, space, index = header->write_index;
> > +
> > > + spin_lock(>lock);
> > +
> > > + space = CIRC_SPACE(header->write_index, header->read_index,
> > > + header->size);
> > > + if (space < dwords) {
> > > + header->dropped++;
> > > + spin_unlock(>lock);
> > > + return -ENOSPC;
> > > + }
> > +
> > > + for (i = 0; i < dwords; i++) {
> > > + queue->data[index] = data[i];
> > > + index = (index + 1) % header->size;
> > > + }
> > +
> > > + header->write_index = index;
> > > + spin_unlock(>lock);
> > +
> > > + /* Make sure the command is written to the queue */
> > > + wmb();
> 
> The above memory barrier is unnecessary. The gmu_write below is a
> wrapper around writel, which already includes the write barrier.

Thanks.  I got this one and a few others I found too.

> > +   gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET, 0x01);
> > > + return 0;
> > +}
> 
> [...]
> > +static int a6xx_hfi_send_msg(struct a6xx_gmu *gmu, int id,
> > > + void *data, u32 size, u32 *payload, u32 payload_size)
> > +{
> > > + struct a6xx_hfi_queue *queue = >queues[HFI_COMMAND_QUEUE];
> > > + struct a6xx_hfi_response resp = { 0 };
> > > + int ret, dwords = size >> 2;
> > > + u32 seqnum;
> > +
> > > + seqnum = atomic_inc_return(>seqnum) % 0xfff;
> > +
> > > + /* First dword of the message is the message header - fill it in */
> > > + *((u32 *) data) = (seqnum << 20) | (HFI_MSG_CMD << 16) |
> > > + (dwords << 8) | id;
> > +
> > > + init_completion();
> > > + resp.id = id;
> > > + resp.seqnum = seqnum;
> > +
> > > + spin_lock_bh(_ack_lock);
> > > + list_add_tail(, _ack_list);
> > > + spin_unlock_bh(_ack_lock);
> 
> What are you protecting against here by using the _bh spinlock
> variants?

We use a tasklet from the interrupt to process responses. The
commands are entirely serialized right now so this is mostly wasted
cycles but we are planning for a brave future where the commands
may be asynchronous.

> Regards,
> Lucas

Thanks,
Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of 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

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #17 from arne_woer...@yahoo.com ---
(In reply to Alex Deucher from comment #15)
> (In reply to arne_woerner from comment #14)
> > _but_ they both need at least one of these kernel parameters in the 
> > grub.cfg:
> > amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.audio=0
> 
> Can you clarify this last statement?  The first two options are irrelevant
> for your board since it's not SI or CIK.
>
yup:
i mean: i did not test, which one is necessary...
so i cannot say, if all three r necessary, or if just one/two of them
suffice...

tomorrow i will test "amdgpu.audio=0 amdgpu.msi=0"...
with the stable linux-firmware package... right?

or do u mean just "amdgpu.msi=0"?
maybe hdmi audio works already, if amdgpu.msi is 0?

-arne

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

[PATCH 2/2] drm/msm: Add A6XX device support

[Jordan Crouse]

Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself.  Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1210 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 11 files changed, 2824 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+   adreno/a6xx_gpu.o \
+   adreno/a6xx_gmu.o \
+   adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..a031c2eaf18c
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1210 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+   dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   if (status &  A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+   dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+   dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+   gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+   tasklet_schedule(>hfi_tasklet);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+   dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+   u32 val  = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+   return !(val &
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF |
+   A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+#define GX_OFF_MASK \
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF | \
+A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF)
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+   u32 val;
+   int local = gmu->idle_level;
+
+   /* SPTP and IFPC both report as IFPC */
+   if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+   local = GMU_IDLE_STATE_IFPC;
+
+   val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+   if (val == local) {
+   if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+   !a6xx_gmu_gx_is_on(gmu))
+   return true;
+   }
+
+   return false;
+}
+
+/* Wait for the GMU to get to its most idle 

[PATCH 1/2] drm/msm: Add generated headers for A6XX

[Jordan Crouse]

From: Sharat Masetty 

Add initial register headers for A6XX targets.

Signed-off-by: Sharat Masetty 
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h |  382 +++
 2 files changed, 1982 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..17d12414f347
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1600 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- /local3/projects/drm/envytools/rnndb//adreno.xml   (501 
bytes, from 2017-11-20 17:36:01)
+- /local3/projects/drm/envytools/rnndb//freedreno_copyright.xml  (   1572 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/a2xx.xml  (  32901 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_common.xml (  11792 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_pm4.xml(  17205 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a3xx.xml  (  83693 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a4xx.xml  ( 110372 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a5xx.xml  (  66793 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx.xml  (  44551 
bytes, from 2017-11-20 19:30:19)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx_gmu.xml  (  10431 
bytes, from 2017-11-20 17:59:44)
+- /local3/projects/drm/envytools/rnndb//adreno/ocmem.xml (   1773 
bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2017 by the following authors:
+- Rob Clark  (robclark)
+- Ilia Mirkin  (imirkin)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+   PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+   PC_CCU_INVALIDATE_DEPTH = 24,
+   PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR  0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW   0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR   0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT  0x0080
+#define 

[RFC v2 0/2] drm/msm: Add support for Adreno a6xx

[Jordan Crouse]

Brief refresh of the a6xx GPU support for drm/msm
(v1 found here https://patchwork.freedesktop.org/series/37428/)

Thanks to Lucas for his comments, more comments gladly welcomed. I know it is
hard when you are reviewing code that won't be immediately coming to a device
near you but any feedback will make things even better in the end.

Heads up that this code depends on these two stacks to compile:

https://patchwork.freedesktop.org/series/36252/
https://patchwork.codeaurora.org/patch/446409/

Hopefully soon we'll have a git tree somewhere in the world that has everything
built in, but for the meantime some assembly will be required.

[v2: Addressed comments from Lucas Stach, added pm_runtime_get_supplier calls
for accesses to the GMU IOMMU, moved to SPDX headers for the new files]

Jordan Crouse (1):
  drm/msm: Add A6XX device support

Sharat Masetty (1):
  drm/msm: Add generated headers for A6XX

 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  | 1600 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1210 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h  |  382 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  809 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 13 files changed, 4806 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

-- 
2.16.1

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