[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Dennis Schridde  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=104831

-- 
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 104831] CAYMAN:KDE applications SIGSEGV

[bugzilla-daemon]

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

Dennis Schridde  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=104806

-- 
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] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[Michal Hocko]

On Tue 30-01-18 02:56:51, He, Roger wrote:
> Hi Michal:
> 
> We need a API to tell TTM module the system totally has how many swap
> cache.  Then TTM module can use it to restrict how many the swap cache
> it can use to prevent triggering OOM.  For Now we set the threshold of
> swap size TTM used as 1/2 * total size and leave the rest for others
> use.

Why do you so much memory? Are you going to use TB of memory on large
systems? What about memory hotplug when the memory is added/released?
 
> But get_nr_swap_pages is the only API we can accessed from other
> module now.  It can't cover the case of the dynamic swap size
> increment.  I mean: user can use "swapon" to enable new swap file or
> swap disk dynamically or "swapoff" to disable swap space.

Exactly. Your scaling configuration based on get_nr_swap_pages or the
available memory simply sounds wrong.
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/6] drm: Add drm_mode_config->normalize_zpos boolean

[Peter Ujfalusi]

Ville,

On 2018-01-26 18:43, Ville Syrjälä wrote:
>> I'm not sure if I understand the problem. This series does the following
>> in essence:
>>
>> drm_atomic_helper_check(...)
>> {
>>  /* does A */
>> }
>>
>> driver_hand_rolled_atomic_helper_check(...)
>> {
>>  /* does A */
>> }
>>
>> - .atomic_check = driver_hand_rolled_atomic_helper_check,
>> + .atomic_check = drm_atomic_helper_check,
>>
>> I'm most likely missing something, but not sure what.
> 
> The 
> 
> if (state->legacy_cursor_update)
>   state->async_update = !drm_atomic_helper_async_check(drm, state);
> 
> part.

Yes, you are right. this part is missing from the hand rolled
atomic_check function in the drivers I'm touching in this series.

The reason for that is that they all got their atomic_check function
copied from the core before the legacy_cursor_update check and async
check is added. Drivers just 'left behind' by not getting the same change.

Which might or might not cause issues for them, but it is still better
to use common code as much as possible to have consistent way of working
among the DRM drivers.

> The helper has it, as does tegra, but sti does not. Would be nice to
> have something in the comment message documenting why it's safe to add
> it to sti and other drivers that didn't already have it.

I purposefully created separate patches for the drivers so the change
can be reverted easier.

I can add to the commit message for the drivers something like:

Note: the drm_atomic_helper_check() now includes

if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(drm, state);

which was added after the driver moved away from using it
(38d868e41c4b9250d5a115c049dc2d48f4909581 drm: Don't force all planes to
be added to the state due to zpos)

- Péter

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 v5 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]

On 29/01/18 18:38, Boris Brezillon wrote:

> Note that the TX byte clk should be configured to match the DPI pixel
> clock, which means we should refuse any config where the variation is
> too big to be recovered. Anyway, we still don't have a way to configure
> the PLL rate (which is driving the TX byte clk), so there's not much I
> can do about that right now.

We could have the code to check the allowed difference in place.

>> Another thing is that the mode->crtc_clock is in kHz, I wonder if that
>> rounding can cause miscalculations in the above code.
> 
> Do we really have modes exposing pixel clks not aligned on a Khz? I

Well, I think the clocks in the logical video modes are aligned, but the
actual clock from the display controller or the PHY most likely is not
aligned.

> know the display controller can adjust the timings, but then, the
> variation caused by the Khz approx should not be that big (999Khz /
> 10+MHz < 1/1), and anyway, that's what the DRM framework
> manipulates...

Depends on how strict the HW is about the allowed difference between the
crtc and the DSI IP. It maybe that that 1 Hz is one too many... But that
can be avoided by just making sure that the check rounds the values
properly, or maybe just reduces the allowed range by 1kHz on both ends.

So I don't think it's an issue, but it is something to keep in mind.

 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][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

On Mon, Jan 29, 2018 at 12:02 PM, Sean Paul  wrote:
> On Thu, Jan 25, 2018 at 09:23:45PM -0800, John Stultz wrote:
>> On Wed, Jan 24, 2018 at 7:46 AM, Sean Paul  wrote:
>> > On Tue, Jan 23, 2018 at 03:16:37PM -0800, John Stultz wrote:
>> >> +}
>> >> +#else /* HIKEY960 case*/
>> >> +uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
>> >> +  switch (hal_format) {
>> >> +case HAL_PIXEL_FORMAT_RGB_888:
>> >> +  return DRM_FORMAT_BGR888;
>> >> +case HAL_PIXEL_FORMAT_BGRA_:
>> >> +  return DRM_FORMAT_XBGR;
>> >> +case HAL_PIXEL_FORMAT_RGBX_:
>> >> +  return DRM_FORMAT_XBGR;
>> >> +case HAL_PIXEL_FORMAT_RGBA_:
>> >> +  return DRM_FORMAT_XBGR;
>> >> +case HAL_PIXEL_FORMAT_RGB_565:
>> >> +  return DRM_FORMAT_BGR565;
>> >> +case HAL_PIXEL_FORMAT_YV12:
>> >> +  return DRM_FORMAT_YVU420;
>> >> +default:
>> >> +  ALOGE("Cannot convert hal format to drm format %u", hal_format);
>> >> +  return -EINVAL;
>> >> +  }
>> >
>> > So it seems like we're smashing a whole bunch of formats into XBGR 
>> > here, and
>> > I'm not sure how it'll work. If you look above, the primary difference 
>> > between
>> > the HAL and drm formats is that the subpixels are reversed (ie: RGBA 
>> > becomes
>> > ABGR). In this snippet, you've got BGRA->XBGR, does this actually work?
>>
>> Honestly the above is some sort of dyslexia nightmare for me, so I may
>> have gotten it slightly wrong. :)
>>
>
> I can certainly sympathize with this. It took me longer than I'd like to admit
> to write the above. This seems like a good reason to change things up!
>
>
>> So my understanding is that for the HiKey960/bifrost the As need to be
>> Xs (and I've verified that we don't get anything if we try to leave
>> the X's), and we have to switch the R/Bs to get the colors right.  It
>> may be the R/B switching is due to other quirks in gralloc and the drm
>> driver, I'm not sure.
>
> It'd be nice to figure out. I suspect there's a bug somewhere that's re-
> reversing things.

Yea, I've been digging in and it looks like we can get rid of the
special case conversion by adding DRM_FORMAT_ARGB entries to the
kirin960 drm driver.

So that part seems to be easy to simplify out. I'll continue trying to
sort out the rest of your feedback.

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

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86

[John Stultz]

On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov  wrote:
> Hi all,
>
> Couple of ideas/notes,
>
> On 10 January 2018 at 20:36, Rob Herring  wrote:
>> On Wed, Jan 10, 2018 at 1:09 PM, John Stultz  wrote:
>>> On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring  wrote:
 On Tue, Jan 9, 2018 at 11:25 PM, John Stultz  
 wrote:
> When building AOSP after updating libdrm project to the
> freedesktop/master branch, I've seen the following build errors:
>
> external/libdrm/intel/Android.mk: error: libdrm_intel

 This is only needed for i915 (not i965) now BTW. I'm not sure at what
 point we stop caring about i915.
> If you're using any other Intel components - say Beignet or the va
> driver, I think those still use libdrm_intel.
>
> An alternative solution IMHO, is to drop/tweak the API to not bother
> libpciaccess.
> I have some ancient cleanup/rework branch
>
> https://github.com/evelikov/libdrm/commits/intel-remove-legacy

I'm not opposed to this, but I'm really not familiar with intel use
cases and what would be ok or not there.


> (SHARED_LIBRARIES android-arm64) missing libpciaccess
> (SHARED_LIBRARIES android-arm64) You can set
> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
> intentional, but that may defer real problems until later in the
> build.
>
> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
> things to function properly, but is not ideal.
>
> So basically, while I'm not including the libdrm_intel package
> into the build, just the fact that the Android.mk file references
> libpciaccess which isn't a repo included in AOSP causes the build
> failure.
>
> So it seems we need some sort of conditional filter in the
> Android.mk to skip over it if we're not building for intel.
>
> This is my initial attempt at solving this.
>
> Feedback would be greatly appreciated!
>
> I note that in the AOSP version of libdrm, the reference to
> libpciaccess has been removed. See:
>  
> https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/
> So I wonder if it make sense to instead remove this upstream as
> well?

 Only if we drop i915.
>>>
>>> To be more precise, drop i915 for Android builds (I'm not suggesting
>>> dropping it elsewhere, just for the Android.mk). I'm really not sure
>>> which devices might be affected. Anyone able to point me to someone in
>>> Intel who would know?
>>
>> The android-x86 folks would be the ones to ask. I added Chih-Wei.
>>
> A really silly question - how are you triggering any of this if you're
> building on !x86?
> Is that because the GPU driver is not selected thus you we fall-back
> to "build all"?

I think its mostly due the fact we're using the toplevel Android.mk
which includes all Android.mk files in subdirectories.

> If so, it might be better to change things to:
>  - error out if none selected
>  - allow one to select "all", "x86", "arm" and similar groups thus
> only the things that can build are build
> eg. RobH had fun with x86 intrinsics while building the intel Vulkan
> driver on ARM

I'm not sure quite how to select a gpu driver with the Android build
system, other then specifying it via a build variable, which is in
effect what I'm trying to do with this patch.

Other ideas?

Thanks so much for the feedback!
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[He, Roger]

get_nr_swap_pages is the only API we can accessed from other module now.
It can't cover the case of the dynamic swap size increment.
I mean: user can use "swapon" to enable new swap file or swap disk 
dynamically or "swapoff" to disable swap space.

Above is why we always to get swap cache size rather than getting it once at 
module initialization time.
That is internal in TTM. Please ignore that.

And why TTM needs get_total_swap_pages instead of using get_nr_swap_pages 
directly. That because
even though the TTM buffer has been swapped out, at the start they also stay in 
system memory by shmem. Later at some point when
Under high memory pressure, Those buffers all are flushed into swap disk and 
used more swap disk size or even use up all swap size. That is not what we want 
and still has random OOM. So we need a API to get total swap size and control 
the swap size used by TTM very accurately.

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
He, Roger
Sent: Tuesday, January 30, 2018 10:57 AM
To: Michal Hocko 
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; Koenig, Christian 
Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to expose 
total_swap_pages

Hi Michal:

We need a API to tell TTM module the system totally has how many swap cache.
Then TTM module can use it to restrict how many the swap cache it can use to 
prevent triggering OOM.
For Now we set the threshold of swap size TTM used as 1/2 * total size and 
leave the rest for others use.


get_nr_swap_pages is the only API we can accessed from other module now.
It can't cover the case of the dynamic swap size increment.
I mean: user can use "swapon" to enable new swap file or swap disk 
dynamically or "swapoff" to disable swap space.

Thanks
Roger(Hongbo.He)

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Michal Hocko
Sent: Tuesday, January 30, 2018 12:31 AM
To: He, Roger 
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; Koenig, Christian 
Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose 
total_swap_pages

On Mon 29-01-18 16:29:42, Roger He wrote:
> ttm module needs it to determine its internal parameter setting.

Could you be more specific why?

> Signed-off-by: Roger He 
> ---
>  include/linux/swap.h |  6 ++
>  mm/swapfile.c| 15 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h index 
> c2b8128..708d66f 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *); struct 
> backing_dev_info;  extern int init_swap_address_space(unsigned int 
> type, unsigned long nr_pages);  extern void 
> exit_swap_address_space(unsigned int type);
> +extern long get_total_swap_pages(void);
>  
>  #else /* CONFIG_SWAP */
>  
> @@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)  { 
> }
>  
> +long get_total_swap_pages(void)
> +{
> + return 0;
> +}
> +
>  #define free_swap_and_cache(e) ({(is_migration_entry(e) ||
> is_device_private_entry(e));})  #define swapcache_prepare(e)
> ({(is_migration_entry(e) || is_device_private_entry(e));})
>  
> diff --git a/mm/swapfile.c b/mm/swapfile.c index 3074b02..a0062eb
> 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
>  
>  atomic_t nr_rotate_swap = ATOMIC_INIT(0);
>  
> +/*
> + * expose this value for others use
> + */
> +long get_total_swap_pages(void)
> +{
> + long ret;
> +
> + spin_lock(_lock);
> + ret = total_swap_pages;
> + spin_unlock(_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(get_total_swap_pages);
> +
>  static inline unsigned char swap_count(unsigned char ent)  {
>   return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */
> --
> 2.7.4

--
Michal Hocko
SUSE Labs
___
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/pl111: Use max memory bandwidth for resolution

[Eric Anholt]

Linus Walleij  writes:

> On Thu, Jan 25, 2018 at 4:46 AM, Eric Anholt  wrote:
>
>>> + pl111_choose_max_resolution(dev, priv->memory_bw,
>>> + _config->max_width,
>>> + _config->max_height, );
>>> + dev_info(dev->dev, "cap resolution at %u x %u, %u BPP\n",
>>> +  mode_config->max_width, mode_config->max_height, bpp);
>>
>> I think this is the wrong place in the pipeline to be doing this, but I
>> don't have a complete solution so I'm not necessarily saying no.
>
> So currently the driver does this:
>
> mode_config->max_width = 1024;
> mode_config->max_height = 768;
>
> And that is because it cannot really handle anything. I guess ideally
> the DRM driver should set these to -1 or something so that any widths
> and heights negotiated will work.

The PPL field only gets you up to 1024 width.  Looks like LPP lets you
get up to 1024 height, though, even if the top level of the PL111 docs
say 1024x768 is the max.

>>  Things I think we should do for bandwidth limits:
>>
>> A new pl111_mode_valid() rejects modes with width*height*2 > bandwidth
>> (if we can't scan it out with our smallest format, don't advertise it).
>>
>> pl111_display_check() rejects modes with width*height*bpp > bandwidth
>> (if we can't scan out this particular configuration, let them know we
>> can't set the mode).
>>
>> Ideally given those two things, fbdev and X11 would notice that the
>> preferred mode fails at 24bpp and fall back to 16bpp.  I don't think
>> either of those does so today, though.
>>
>> Interested in tackling any of these?
>
> I tried the pl111_display_check() version. It just made the driver
> fail to initialize anything, at least when using the dumb VGA
> bridge.
>
> There are .mode_valid() callbacks on the bridges we use
> (panel and dumb VGA) but neither uses it at the moment, hm.
> I could just assign my own .mode_valid() callback to the bridge,
> but it seems a bit fragile. But it's worth a hack, I'll try it.
>
> I sent a sent of lesser controversial patches in the meantime,
> and rebased this on top of those so we can deal with the
> memory BW issue separately.

The memory-bandwidth field is in the pl111 binding, so I do think we
should handle it there.


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

Re: [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD

[Eric Anholt]

Linus Walleij  writes:

> The Versatile PL110 implementations use multiple endpoints:
> from the PL111 port, the lines are routed through a PLD,
> and from there forked so the same lines go to a VGA DAC and
> an external TFT panel connector. This is discrete wireing
> so there is no way to turn of one output, i.e. this is
> really two endpoints, not two ports.
>
> We model this with multiple endpoints, so we need to loop
> over the available endpoints, check for panel or bridge on
> each and accumulate the result before continuing.
>
> The code already will give the panel preference over the
> bridge, if present, so the output will be sent to the panel
> if both a panel and a bridge is present on two endpoints
> of the same port.
>
> If they all return -EPROBE_DEFER we return -EPROBE_DEFER
> as well.
>
> If just one endpoint is present on the port, the behaviour
> is the same as before.
>
> Signed-off-by: Linus Walleij 

Huh, from the binding I would have thought that we were describing
things to the point of the pins coming out of the PLD, not past whatever
splitting comes after that.

I'm also confused how this would work.  You're talking about the DT
looking like:

clcd@1002 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1002 0x1000>;
interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <>, <>;
clock-names = "clcdclk", "apb_pclk";
max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */

port {
dac_pads: endpoint1 {
remote-endpoint = <>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
tft_pads: endpoint2 {
remote-endpoint = <>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};

};


Are you anticipating that a DT would actually connect up to two
endpoints on the CLCD?  How should we resolve the pads property, in that
case?  Is there much point in supporting this, if we don't actually
support panels or bridges on both of the endpoints at once (since we
pick only one to do panel/bridge setup/teardown on)?


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

Re: [PATCH 2/4] drm/pl111: Properly detect the PL110+ variant

[Eric Anholt]

Linus Walleij  writes:

> With a bit of refactoring we can contain the variant data for
> the "PL110+" version that is somewhere inbetween PL110 and PL111.
> This is used on the ARM Versatile AB and Versatile PB.

Patch 2-3 are:

Reviewed-by: Eric Anholt 


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

Re: [PATCH 1/4] drm/pl111: Error handling for CMA framebuffer

[Eric Anholt]

Linus Walleij  writes:

> When attaching the CMA framebuffer we need to check for
> returned error pointers.

This doesn't seem to be necessary on drm-misc-next.


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

RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[He, Roger]

Hi Michal:

We need a API to tell TTM module the system totally has how many swap cache.
Then TTM module can use it to restrict how many the swap cache it can use to 
prevent triggering OOM.
For Now we set the threshold of swap size TTM used as 1/2 * total size and 
leave the rest for others use.

But get_nr_swap_pages is the only API we can accessed from other module now.
It can't cover the case of the dynamic swap size increment.
I mean: user can use "swapon" to enable new swap file or swap disk dynamically 
or "swapoff" to disable swap space.

Thanks
Roger(Hongbo.He)

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Michal Hocko
Sent: Tuesday, January 30, 2018 12:31 AM
To: He, Roger 
Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; Koenig, Christian 
Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose 
total_swap_pages

On Mon 29-01-18 16:29:42, Roger He wrote:
> ttm module needs it to determine its internal parameter setting.

Could you be more specific why?

> Signed-off-by: Roger He 
> ---
>  include/linux/swap.h |  6 ++
>  mm/swapfile.c| 15 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h index 
> c2b8128..708d66f 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);  
> struct backing_dev_info;  extern int init_swap_address_space(unsigned 
> int type, unsigned long nr_pages);  extern void 
> exit_swap_address_space(unsigned int type);
> +extern long get_total_swap_pages(void);
>  
>  #else /* CONFIG_SWAP */
>  
> @@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)  {  
> }
>  
> +long get_total_swap_pages(void)
> +{
> + return 0;
> +}
> +
>  #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
> is_device_private_entry(e));})  #define swapcache_prepare(e) 
> ({(is_migration_entry(e) || is_device_private_entry(e));})
>  
> diff --git a/mm/swapfile.c b/mm/swapfile.c index 3074b02..a0062eb 
> 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
>  
>  atomic_t nr_rotate_swap = ATOMIC_INIT(0);
>  
> +/*
> + * expose this value for others use
> + */
> +long get_total_swap_pages(void)
> +{
> + long ret;
> +
> + spin_lock(_lock);
> + ret = total_swap_pages;
> + spin_unlock(_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(get_total_swap_pages);
> +
>  static inline unsigned char swap_count(unsigned char ent)  {
>   return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */
> --
> 2.7.4

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

Re: [PATCH v2 10/43] drm/rockchip: add mutex vop lock

[Sandy Huang]

在 2018/1/26 21:16, Thierry Escande 写道:

From: zain wang 

Add a lock to vop to avoid disabling the crtc while waiting for a line
flag while enabling psr. If we disable in the middle of waiting for the
line flag, we'll end up timing out or worse.

Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 +++--
  1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 31304434847a..bf4b1a2f3fa4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -117,6 +117,8 @@ struct vop {
spinlock_t reg_lock;
/* lock vop irq reg */
spinlock_t irq_lock;
+   /* protects crtc enable/disable */
+   struct mutex vop_lock;
  
  	unsigned int irq;
  
@@ -577,6 +579,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
  
  	WARN_ON(vop->event);
  
+	mutex_lock(>vop_lock);

drm_crtc_vblank_off(crtc);
  
  	/*

@@ -612,6 +615,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
clk_disable(vop->aclk);
clk_disable(vop->hclk);
pm_runtime_put(vop->dev);
+   mutex_unlock(>vop_lock);
  
  	if (crtc->state->event && !crtc->state->active) {

spin_lock_irq(>dev->event_lock);
@@ -882,10 +886,13 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
uint32_t pin_pol, val;
int ret;
  
+	mutex_lock(>vop_lock);

+
WARN_ON(vop->event);
  
  	ret = vop_enable(crtc);

if (ret) {
+   mutex_unlock(>vop_lock);
DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n", ret);
return;
}
@@ -949,6 +956,7 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
  
  	VOP_REG_SET(vop, common, standby, 0);

+   mutex_unlock(>vop_lock);
  }
  
  static bool vop_fs_irq_is_pending(struct vop *vop)

@@ -1487,15 +1495,21 @@ int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, 
unsigned int mstimeout)
  {
struct vop *vop = to_vop(crtc);
unsigned long jiffies_left;
+   int ret = 0;
  
  	if (!crtc || !vop->is_enabled)

return -ENODEV;
  
-	if (mstimeout <= 0)

-   return -EINVAL;
+   mutex_lock(>vop_lock);
+   if (mstimeout <= 0) {
+   ret = -EINVAL;
+   goto out;
+   }
  
-	if (vop_line_flag_irq_is_enabled(vop))

-   return -EBUSY;
+   if (vop_line_flag_irq_is_enabled(vop)) {
+   ret = -EBUSY;
+   goto out;
+   }
  
  	reinit_completion(>line_flag_completion);

vop_line_flag_irq_enable(vop);
@@ -1506,10 +1520,13 @@ int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, 
unsigned int mstimeout)
  
  	if (jiffies_left == 0) {

DRM_DEV_ERROR(vop->dev, "Timeout waiting for IRQ\n");
-   return -ETIMEDOUT;
+   ret = -ETIMEDOUT;
+   goto out;
}
  
-	return 0;

+out:
+   mutex_unlock(>vop_lock);
+   return ret;
  }
  EXPORT_SYMBOL(rockchip_drm_wait_vact_end);
  
@@ -1559,6 +1576,7 @@ static int vop_bind(struct device *dev, struct device *master, void *data)
  
  	spin_lock_init(>reg_lock);

spin_lock_init(>irq_lock);
+   mutex_init(>vop_lock);
  
  	ret = devm_request_irq(dev, vop->irq, vop_isr,

   IRQF_SHARED, dev_name(dev), vop);




Reviewed-by: Sandy huang 

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

Re: [PATCH v2 03/43] drm/rockchip: Respect page offset for PRIME mmap calls

[Sandy Huang]

在 2018/1/26 21:16, Thierry Escande 写道:

From: Ørjan Eide 

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

Cc: Daniel Kurtz 
Signed-off-by: Ørjan Eide 
Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Tested-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 5d52020deca1..074db7a92809 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -264,7 +264,6 @@ static int rockchip_drm_gem_object_mmap(struct 
drm_gem_object *obj,
 * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
 */
vma->vm_flags &= ~VM_PFNMAP;
-   vma->vm_pgoff = 0;
  
  	if (rk_obj->pages)

ret = rockchip_drm_gem_object_mmap_iommu(obj, vma);
@@ -299,6 +298,12 @@ int rockchip_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
if (ret)
return ret;
  
+	/*

+* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
+* whole buffer from the start.
+*/
+   vma->vm_pgoff = 0;
+
obj = vma->vm_private_data;
  
  	return rockchip_drm_gem_object_mmap(obj, vma);




Reviewed-by: Sandy huang 

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

Re: [PATCH v2 02/43] drm/rockchip: support prime import sg table

[Sandy Huang]

在 2018/1/26 21:16, Thierry Escande 写道:

From: Haixia Shi 

The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).

Signed-off-by: Haixia Shi 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Tested-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 118 ++--
  drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   5 +-
  3 files changed, 115 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d85431400a0d..88084ca15115 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -230,6 +230,7 @@ static struct drm_driver rockchip_drm_driver = {
.gem_prime_import   = drm_gem_prime_import,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
+   .gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
.gem_prime_vunmap   = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1d9655576b6e..5d52020deca1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,6 +16,8 @@
  #include 
  #include 
  #include 
+
+#include 
  #include 
  
  #include "rockchip_drm_drv.h"

@@ -309,12 +311,10 @@ static void rockchip_gem_release_object(struct 
rockchip_gem_object *rk_obj)
  }
  
  struct rockchip_gem_object *

-   rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
-  bool alloc_kmap)
+   rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
  {
struct rockchip_gem_object *rk_obj;
struct drm_gem_object *obj;
-   int ret;
  
  	size = round_up(size, PAGE_SIZE);
  
@@ -326,6 +326,20 @@ struct rockchip_gem_object *
  
  	drm_gem_object_init(drm, obj, size);
  
+	return rk_obj;

+}
+
+struct rockchip_gem_object *
+rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
+  bool alloc_kmap)
+{
+   struct rockchip_gem_object *rk_obj;
+   int ret;
+
+   rk_obj = rockchip_gem_alloc_object(drm, size);
+   if (IS_ERR(rk_obj))
+   return rk_obj;
+
ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
if (ret)
goto err_free_rk_obj;
@@ -343,11 +357,21 @@ struct rockchip_gem_object *
   */
  void rockchip_gem_free_object(struct drm_gem_object *obj)
  {
-   struct rockchip_gem_object *rk_obj;
-
-   rk_obj = to_rockchip_obj(obj);
+   struct drm_device *drm = obj->dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
  
-	rockchip_gem_free_buf(rk_obj);

+   if (obj->import_attach) {
+   if (private->domain) {
+   rockchip_gem_iommu_unmap(rk_obj);
+   } else {
+   dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
+rk_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   }
+   drm_prime_gem_destroy(obj, rk_obj->sgt);
+   } else {
+   rockchip_gem_free_buf(rk_obj);
+   }
  
  	rockchip_gem_release_object(rk_obj);

  }
@@ -451,6 +475,86 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
return sgt;
  }
  
+static unsigned long rockchip_sg_get_contiguous_size(struct sg_table *sgt,

+int count)
+{
+   struct scatterlist *s;
+   dma_addr_t expected = sg_dma_address(sgt->sgl);
+   unsigned int i;
+   unsigned long size = 0;
+
+   for_each_sg(sgt->sgl, s, count, i) {
+   if (sg_dma_address(s) != expected)
+   break;
+   expected = sg_dma_address(s) + sg_dma_len(s);
+   size += sg_dma_len(s);
+   }
+   return size;
+}
+
+static int
+rockchip_gem_iommu_map_sg(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sg,
+ struct rockchip_gem_object *rk_obj)
+{
+   rk_obj->sgt = sg;
+   return rockchip_gem_iommu_map(rk_obj);
+}
+
+static int
+rockchip_gem_dma_map_sg(struct drm_device *drm,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sg,
+   struct 

Re: [PATCH v2 01/43] drm/rockchip: Get rid of unnecessary struct fields

[Sandy Huang]

在 2018/1/26 21:16, Thierry Escande 写道:

From: Tomasz Figa 

This patch removes unused fields from vop structure.

Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba7505292b78..7a137bc5708c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -95,9 +95,6 @@ struct vop {
struct drm_device *drm_dev;
bool is_enabled;
  
-	/* mutex vsync_ work */

-   struct mutex vsync_mutex;
-   bool vsync_work_pending;
struct completion dsp_hold_completion;
  
  	/* protected by dev->event_lock */

@@ -1567,8 +1564,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
spin_lock_init(>reg_lock);
spin_lock_init(>irq_lock);
  
-	mutex_init(>vsync_mutex);

-
ret = devm_request_irq(dev, vop->irq, vop_isr,
   IRQF_SHARED, dev_name(dev), vop);
if (ret)


Reviewed-by: Sandy huang 

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

[Bug 37474] Segmentation Fault in glCopyTexSubImage2D

[bugzilla-daemon]

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

Ben Crocker  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Ben Crocker  ---
In light of the patch noted in comment 1, can we close this as
RESOLVED/FIXED?

Did that patch make it upstream before R128 support was dropped
in Mesa 8.0 in 2012?

-- 
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 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #6 from Andy Furniss  ---
Working with latest agd5f kernels

-- 
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 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

 Blocks||104757


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=104757
[Bug 104757] [TRACKER] Mesa 18.0 release tracker
-- 
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] dt-bindings: display: stm32: correct clock-names in dsi panel example

[Rob Herring]

On Mon, Jan 22, 2018 at 04:35:47PM +0100, Philippe Cornu wrote:
> In the dsi panel example, clock names in the "clock-names"
> field have been swapped:
> * "pclk" (peripheral clock) is < 1 CLK_F469_DSI> on stm32f4
> * "ref" (dsi phy pll ref clock) is <_hse> on stm32f4
> 
> Signed-off-by: Philippe Cornu 
> ---
>  Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rob Herring 

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

Re: [AMDGPU][TAHITI XT] new display code

[Alex Deucher]

On Mon, Jan 29, 2018 at 5:35 PM,   wrote:
> On Mon, Jan 29, 2018 at 03:40:34PM -0500, Alex Deucher wrote:
>> On Mon, Jan 29, 2018 at 3:34 PM,   wrote:
>> > As far as I can remember, not for the new features ofc, DCE programming 
>> > for GCN1
>> > is very similar if not mostly the same than DCE programming for GCN1.1/2 
>> > which
>> > is supported by the new DC code.
>> >
>> > Is this planned?
>>
>> Right, as I said, you could definitely leverage the support for DCE8
>> in DC.  The blocks are very similar.  At the moment, we have no plans
>> to implement DC support for DCE6.
>
> Ok.
>
> Which git repo/branch has the most up-to-date DCE code?

https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

>
> Is there a fine granularity selection system for supported DCE features? That
> to expose the available/implemented DCE features to userland DRM (I can test 
> only discret
> tahiti XT code paths).
>
> I'll try to get something working.

amdgpu only supports SI and newer parts so you don't have to worry
about DCE6-based APUs in this case.  The current DCE8, 10, and 11
implementations share a lot of code.  Your best bet would be to follow
a similar model for DCE6.

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

[RFC v4 4/5] drm/nouveau: Add support for SLCG for Kepler2

[Lyude Paul]

That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating.  The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before taking affect. As with the previous series, this
results in another noticeable drop in power consumption and is
programmed in the same manner.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index a528894231d0..4da916a9fc73 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -187,6 +187,87 @@ gk110_clkgate_blcg_init_gpc_mp_0[] = {
{}
 };
 
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_main_0[] = {
+   { 0x4041f4, 1, 0x },
+   { 0x409894, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_unk_0[] = {
+   { 0x406004, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_sked_0[] = {
+   { 0x407004, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ctxctl_0[] = {
+   { 0x41a894, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_0[] = {
+   { 0x418504, 1, 0x },
+   { 0x41860c, 1, 0x },
+   { 0x41868c, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_esetup_0[] = {
+   { 0x41882c, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_zcull_0[] = {
+   { 0x418974, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_l1c_0[] = {
+   { 0x419cd8, 2, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_1[] = {
+   { 0x419c74, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_mp_0[] = {
+   { 0x419fd4, 1, 0x4a4a },
+   { 0x419fdc, 1, 0x0014 },
+   { 0x419fe4, 1, 0x },
+   { 0x419ff4, 1, 0x1724 },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ppc_0[] = {
+   { 0x41be2c, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_pcounter_0[] = {
+   { 0x1be018, 1, 0x01ff },
+   { 0x1bc018, 1, 0x01ff },
+   { 0x1b8018, 1, 0x01ff },
+   { 0x1b4124, 1, 0x },
+   {}
+};
+
 static const struct nvkm_therm_clkgate_pack
 gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_main_0 },
@@ -214,6 +295,18 @@ gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_rop_0 },
{ gk104_clkgate_blcg_init_rop_crop_0 },
{ gk104_clkgate_blcg_init_pxbar_0 },
+   { gk110_clkgate_slcg_init_main_0 },
+   { gk110_clkgate_slcg_init_unk_0 },
+   { gk110_clkgate_slcg_init_sked_0 },
+   { gk110_clkgate_slcg_init_gpc_ctxctl_0 },
+   { gk110_clkgate_slcg_init_gpc_unk_0 },
+   { gk110_clkgate_slcg_init_gpc_esetup_0 },
+   { gk110_clkgate_slcg_init_gpc_zcull_0 },
+   { gk110_clkgate_slcg_init_gpc_l1c_0 },
+   { gk110_clkgate_slcg_init_gpc_unk_1 },
+   { gk110_clkgate_slcg_init_gpc_mp_0 },
+   { gk110_clkgate_slcg_init_gpc_ppc_0 },
+   { gk110_clkgate_slcg_init_pcounter_0 },
{}
 };
 
-- 
2.14.3

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

[RFC 5/5] drm/nouveau: Introduce NvPmEnableGating option

[Lyude Paul]

This adds the NvPmEnableGating config option to nouveau, which can be
used to enable or disable clockgating for supported chipsets. Enabling
can be done by passing

config=NvPmEnableGating=1

To nouveau. If your chipset supports it, you'll see a message in your
kernel log indicating that clockgating is enabled. Since clockgating has
only had limited testing thus far, we leave this option disabled by
default for now.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index de07bc07abdb..bf62303571b3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -434,7 +434,9 @@ nvkm_therm_ctor(struct nvkm_therm *therm, struct 
nvkm_device *device,
therm->attr_get = nvkm_therm_attr_get;
therm->attr_set = nvkm_therm_attr_set;
therm->mode = therm->suspend = -1; /* undefined */
-   therm->clkgating_enabled = false;
+
+   therm->clkgating_enabled = nvkm_boolopt(device->cfgopt,
+   "NvPmEnableGating", false);
 }
 
 int
-- 
2.14.3

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

[RFC v4 3/5] drm/nouveau: Add support for BLCG on Kepler2

[Lyude Paul]

Same as the previous patch, but for Kepler2 now

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h  |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |  8 +--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62 
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c| 71 +++
 5 files changed, 139 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
index adb78f7d083a..92be0e5269c6 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
@@ -75,6 +75,7 @@ int mcp89_fb_new(struct nvkm_device *, int, struct nvkm_fb 
**);
 int gf100_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
 int gf108_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
 int gk104_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
+int gk110_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
 int gk20a_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
 int gm107_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
 int gm200_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 74bd09b1c893..7590a30b7ff0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1812,7 +1812,7 @@ nvf0_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
-   .fb = gk104_fb_new,
+   .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1850,7 +1850,7 @@ nvf1_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
-   .fb = gk104_fb_new,
+   .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1888,7 +1888,7 @@ nv106_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
-   .fb = gk104_fb_new,
+   .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1926,7 +1926,7 @@ nv108_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
-   .fb = gk104_fb_new,
+   .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index a38e19b61c1d..a528894231d0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -22,6 +22,7 @@
  * Authors: Ben Skeggs 
  */
 #include "gf100.h"
+#include "gk104.h"
 #include "ctxgf100.h"
 
 #include 
@@ -156,6 +157,66 @@ gk110_gr_pack_mmio[] = {
{}
 };
 
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_sked_0[] = {
+   { 0x407000, 1, 0x4041 },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_gcc_0[] = {
+   { 0x419020, 1, 0x0042 },
+   { 0x419038, 1, 0x0042 },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_l1c_0[] = {
+   { 0x419cd4, 2, 0x4042 },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_mp_0[] = {
+   { 0x419fd0, 1, 0x4043 },
+   { 0x419fd8, 1, 0x4049 },
+   { 0x419fe0, 2, 0x4042 },
+   { 0x419ff0, 1, 0x0046 },
+   { 0x419ff8, 1, 0x4042 },
+   { 0x419f90, 1, 0x4042 },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_pack
+gk110_clkgate_pack[] = {
+   { gk104_clkgate_blcg_init_main_0 },
+   { gk104_clkgate_blcg_init_rstr2d_0 },
+   { gk104_clkgate_blcg_init_unk_0 },
+   { gk104_clkgate_blcg_init_gcc_0 },
+   { gk110_clkgate_blcg_init_sked_0 },
+   { gk104_clkgate_blcg_init_unk_1 },
+   { gk104_clkgate_blcg_init_gpc_ctxctl_0 },
+   { gk104_clkgate_blcg_init_gpc_unk_0 },
+   { gk104_clkgate_blcg_init_gpc_esetup_0 },
+   { gk104_clkgate_blcg_init_gpc_tpbus_0 },
+   { gk104_clkgate_blcg_init_gpc_zcull_0 },
+   { gk104_clkgate_blcg_init_gpc_tpconf_0 },
+   { gk104_clkgate_blcg_init_gpc_unk_1 },
+   { gk110_clkgate_blcg_init_gpc_gcc_0 },
+   { gk104_clkgate_blcg_init_gpc_ffb_0 },
+   { gk104_clkgate_blcg_init_gpc_tex_0 },
+   { gk104_clkgate_blcg_init_gpc_poly_0 },
+   { gk110_clkgate_blcg_init_gpc_l1c_0 },
+   { gk104_clkgate_blcg_init_gpc_unk_2 },
+   { 

[RFC v4 2/5] drm/nouveau: Add support for BLCG on Kepler1

[Lyude Paul]

This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more power hungry then they need to be, so the nvidia driver
writes it's own more optimized set of BLCG settings before enabling
CG_CTRL. This adds support for programming the optimized BLCG values
during engine/subdev init, which enables rather significant power
savings.

This introduces the nvkm_therm_clkgate_init() helper, which we use to
program the optimized BLCG settings before enabling clockgating with
nvkm_therm_clkgate_enable.

As well, this commit shares a lot more code with Fermi since BLCG is
mostly the same there as far as we can tell. In the future, it's likely
we'll reformat the clkgate_packs for kepler1 so that they share a list
of mmio packs with Fermi.

Signed-off-by: Lyude Paul 
---
 .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  12 ++
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 +
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h |  55 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c |   6 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c |  47 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h |  35 
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  10 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c  |  75 
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c  |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |   8 +
 14 files changed, 461 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index 240b19bb4667..9398d9f09339 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -46,6 +46,16 @@ enum nvkm_therm_attr_type {
NVKM_THERM_ATTR_THRS_SHUTDOWN_HYST = 17,
 };
 
+struct nvkm_therm_clkgate_init {
+   u32 addr;
+   u8  count;
+   u32 data;
+};
+
+struct nvkm_therm_clkgate_pack {
+   const struct nvkm_therm_clkgate_init *init;
+};
+
 struct nvkm_therm {
const struct nvkm_therm_func *func;
struct nvkm_subdev subdev;
@@ -92,6 +102,8 @@ struct nvkm_therm {
 int nvkm_therm_temp_get(struct nvkm_therm *);
 int nvkm_therm_fan_sense(struct nvkm_therm *);
 int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_init(struct nvkm_therm *,
+const struct nvkm_therm_clkgate_pack *);
 void nvkm_therm_clkgate_enable(struct nvkm_therm *);
 void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
index d7c2adb9b543..c8ec3fd97155 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
@@ -137,6 +137,7 @@ struct gf100_gr_func {
int (*rops)(struct gf100_gr *);
int ppc_nr;
const struct gf100_grctx_func *grctx;
+   const struct nvkm_therm_clkgate_pack *clkgate_pack;
struct nvkm_sclass sclass[];
 };
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
index 5e82f94c2245..17cea9c70f7f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
@@ -22,6 +22,7 @@
  * Authors: Ben Skeggs 
  */
 #include "gf100.h"
+#include "gk104.h"
 #include "ctxgf100.h"
 
 #include 
@@ -173,6 +174,208 @@ gk104_gr_pack_mmio[] = {
{}
 };
 
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_main_0[] = {
+   { 0x4041f0, 1, 0x4046 },
+   { 0x409890, 1, 0x0045 },
+   { 0x4098b0, 1, 0x007f },
+   {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_rstr2d_0[] = {
+   { 0x4078c0, 1, 0x0042 },
+   {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_unk_0[] = {
+   { 0x406000, 1, 0x4044 },
+   { 0x405860, 1, 0x4042 },
+   { 0x40590c, 1, 0x4042 },
+   {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_gcc_0[] = {
+   { 0x408040, 1, 0x4044 },
+   {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_sked_0[] = {
+   { 0x407000, 1, 

[RFC v4 0/5] Implement full clockgating for Kepler1 and 2

[Lyude Paul]

Next version of my patchseries for adding clockgating support for
kepler1 and 2 on nouveau. The first version of this series can be found
here:

https://patchwork.freedesktop.org/series/36504/

One small change:
 - Set therm->clkgate_enabled to false until the last patch, where we
   introduce the NvPmEnableGating option

Lyude Paul (5):
  drm/nouveau: Add support for basic clockgating on Kepler1
  drm/nouveau: Add support for BLCG on Kepler1
  drm/nouveau: Add support for BLCG on Kepler2
  drm/nouveau: Add support for SLCG for Kepler2
  drm/nouveau: Introduce NvPmEnableGating option

 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h   |   1 +
 .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  17 ++
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  25 +--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 +
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h |  55 ++
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 155 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild  |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c |   6 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c |  47 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h |  35 
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c |  71 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  70 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c  |  75 
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h  |  35 
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c  |   8 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  | 136 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h  |  48 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c  |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |  23 ++-
 22 files changed, 996 insertions(+), 26 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h

-- 
2.14.3

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

[RFC v4 1/5] drm/nouveau: Add support for basic clockgating on Kepler1

[Lyude Paul]

This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).

This introduces two therm helpers for controlling basic clockgating:
nvkm_therm_clkgate_enable() - enables clockgating through
CG_CTRL, done after initializing the GPU fully
nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
driver unload

A lot of this code was originally going to be based off of fermi;
however it turns out that while Fermi's the first line of GPUs that
introduced this kind of power saving, Fermi requires more fine tuned
control of the CG_CTRL registers from the driver while reclocking that
we don't entirely understand yet.

For the simple parts we will be sharing with Fermi for certain however,
we at least add those into a new subdev/therm/gf100.h header.

Signed-off-by: Lyude Paul 
---
 .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|   5 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  17 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  58 +++--
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h  |  35 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c  |   8 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  | 135 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h  |  48 
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |  15 ++-
 9 files changed, 301 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index b1ac47eb786e..240b19bb4667 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -85,17 +85,22 @@ struct nvkm_therm {
 
int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
+
+   bool clkgating_enabled;
 };
 
 int nvkm_therm_temp_get(struct nvkm_therm *);
 int nvkm_therm_fan_sense(struct nvkm_therm *);
 int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_enable(struct nvkm_therm *);
+void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
 
 int nv40_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gk104_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 08e77cd55e6e..74bd09b1c893 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 
 static DEFINE_MUTEX(nv_devices_mutex);
 static LIST_HEAD(nv_devices);
@@ -1682,7 +1683,7 @@ nve4_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
-   .therm = gf119_therm_new,
+   .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1721,7 +1722,7 @@ nve6_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
-   .therm = gf119_therm_new,
+   .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1760,7 +1761,7 @@ nve7_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
-   .therm = gf119_therm_new,
+   .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1824,7 +1825,7 @@ nvf0_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk110_pmu_new,
-   .therm = gf119_therm_new,
+   .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1862,7 +1863,7 @@ nvf1_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk110_pmu_new,
-   .therm = 

Re: [AMDGPU][TAHITI XT] new display code

[sylvain . bertrand]

On Mon, Jan 29, 2018 at 03:40:34PM -0500, Alex Deucher wrote:
> On Mon, Jan 29, 2018 at 3:34 PM,   wrote:
> > As far as I can remember, not for the new features ofc, DCE programming for 
> > GCN1
> > is very similar if not mostly the same than DCE programming for GCN1.1/2 
> > which
> > is supported by the new DC code.
> >
> > Is this planned?
> 
> Right, as I said, you could definitely leverage the support for DCE8
> in DC.  The blocks are very similar.  At the moment, we have no plans
> to implement DC support for DCE6.

Ok.

Which git repo/branch has the most up-to-date DCE code?

Is there a fine granularity selection system for supported DCE features? That
to expose the available/implemented DCE features to userland DRM (I can test 
only discret
tahiti XT code paths).

I'll try to get something working.

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

Re: [PATCH v2 00/43] DRM Rockchip rk3399 (Kevin)

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:27PM +0100, Thierry Escande wrote:
> Hi,
> 
> This patchset includes cleanups, improvements, and bug fixes for
> Rockchip DRM driver and PSR support.
> 
> this patchset depends and needs to be applied on top of Rockchip rk3399
> eDP support [1].
> 
> [1] https://lkml.org/lkml/2018/1/10/682
> 
> Regards,
> Thierry

Thanks for reviving this set, Thierry. I've made a few comments below, of
varying degrees of severity. I think the only showstopper is the input event
patch. Other than that, feel free to fix up and add my R-b to the rest.

Sean

> 
> Changes in v2:
> - A few patches have been replaced by newer and cleaner versions from
>   the ChromeOS kernel gerrit, especially about disallowing PSR for the
>   whole atomic commit.
> 
> Douglas Anderson (4):
>   drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
>   drm/bridge: analogix_dp: Properly log AUX CH errors
>   drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
>   drm/bridge: analogix_dp: Split the platform-specific poweron in two
> parts
> 
> Haixia Shi (1):
>   drm/rockchip: support prime import sg table
> 
> Kristian H. Kristensen (1):
>   drm/rockchip: Disable PSR on input events
> 
> Lin Huang (6):
>   drm/bridge: analogix_dp: Move enable video into config_video()
>   drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
>   drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the
> panel
>   drm/bridge: analogix_dp: Extend hpd check time to 100ms
>   drm/bridge: analogix_dp: Check dpcd write/read status
>   drm/bridge: analogix_dp: Reset aux channel if an error occurred
> 
> Mark Yao (1):
>   drm/rockchip: pre dither down when output bpc is 8bit
> 
> Sean Paul (3):
>   drm/rockchip: Don't use atomic constructs for psr
>   drm/rockchip: Remove analogix psr worker
>   drm/panel: simple: Change mode for Sharp lq123p1jx31
> 
> Tomasz Figa (8):
>   drm/rockchip: Get rid of some unnecessary code
>   drm/rockchip: analogix_dp: Do not call Analogix code before bind
>   drm/rockchip: Cancel PSR enable work before changing the state
>   drm/rockchip: psr: Avoid redundant calls to .set() callback
>   drm/rockchip: psr: Sanitize semantics of allow/disallow API
>   drm/rockchip: Disable PSR from reboot notifier
>   drm/rockchip: Disallow PSR for the whole atomic commit
>   drm/rockchip: psr: Remove flush by CRTC
> 
> Yakir Yang (1):
>   drm/bridge: analogix_dp: detect Sink PSR state after configuring the
> PSR
> 
> zain wang (17):
>   drm/bridge: analogix_dp: set psr activate/deactivate when
> enable/disable bridge
>   drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind
>   drm/bridge: analogix_dp: Don't change psr while bridge is disabled
>   drm/rockchip: add mutex vop lock
>   drm/bridge: analogix_dp: add fast link train for eDP
>   drm/rockchip: Only wait for panel ACK on PSR entry
>   drm/bridge: analogix_dp: Don't use fast link training when panel just
> powered up
>   drm/bridge: analogix_dp: Retry bridge enable when it failed
>   drm/bridge: analogix_dp: Wait for HPD signal before configuring link
>   drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
>   drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
>   drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
>   drm/rockchip: Restore psr->state when enable/disable psr failed
>   drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
>   drm/bridge: analogix_dp: Fix timeout of video streamclk config
>   drm/bridge: analogix_dp: Fix incorrect operations with register
> ANALOGIX_DP_FUNC_EN_1
>   drm/bridge: analogix_dp: Move fast link training detect to set_bridge
> 
> Ørjan Eide (1):
>   drm/rockchip: Respect page offset for PRIME mmap calls
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 469 
> +++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  14 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 274 +++-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   7 +
>  drivers/gpu/drm/exynos/exynos_dp.c |   2 +-
>  drivers/gpu/drm/panel/panel-simple.c   |   7 +-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  73 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   3 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   3 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  61 ++-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 125 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   5 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 361 +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.h|   7 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  52 ++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   1 +
>  include/drm/bridge/analogix_dp.h   |   5 +-
>  18 files 

Re: [PATCH v2 37/43] drm/rockchip: Disable PSR on input events

[Sean Paul]

On Fri, Jan 26, 2018 at 02:17:04PM +0100, Thierry Escande wrote:
> From: "Kristian H. Kristensen" 
> 
> To improve PSR exit latency, we speculatively start exiting when we
> receive input events. Occasionally, this may lead to false positives,
> but most of the time we get a head start on coming out of PSR. Depending
> on how userspace takes to produce a new frame in response to the event,
> this can completely hide the exit latency. In case of Chrome OS, we
> typically get the input notifier 50ms or more before the dirty_fb
> triggered exit.
> 

I think this is something that ideally would happen in userspace, since it has a
better idea of when to exit psr. IMO, this is something that should probably
stay in the CrOS tree.

Sean

> Signed-off-by: Kristian H. Kristensen 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
> 
>  1 file changed, 134 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index 9376f4396b6b..a107845ba97c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -12,6 +12,8 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -35,6 +37,9 @@ struct psr_drv {
>   enum psr_state  state;
>  
>   struct delayed_work flush_work;
> + struct work_struct  disable_work;
> +
> + struct input_handlerinput_handler;
>  
>   int (*set)(struct drm_encoder *encoder, bool enable);
>  };
> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>   mutex_unlock(>lock);
>  }
>  
> +static void psr_disable_handler(struct work_struct *work)
> +{
> + struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
> +
> + /* If the state has changed since we initiated the flush, do nothing */
> + mutex_lock(>lock);
> + if (psr->state == PSR_ENABLE)
> + psr_set_state_locked(psr, PSR_FLUSH);
> + mutex_unlock(>lock);
> + mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
> +}
> +
>  /**
>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>   * @encoder: encoder to obtain the PSR encoder
> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
> *encoder)
>   psr->active = false;
>   mutex_unlock(>lock);
>   cancel_delayed_work_sync(>flush_work);
> + cancel_work_sync(>disable_work);
>  
>   return 0;
>  }
> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>  
> +static void psr_input_event(struct input_handle *handle,
> + unsigned int type, unsigned int code,
> + int value)
> +{
> + struct psr_drv *psr = handle->handler->private;
> +
> + schedule_work(>disable_work);
> +}
> +
> +static int psr_input_connect(struct input_handler *handler,
> +  struct input_dev *dev,
> +  const struct input_device_id *id)
> +{
> + struct input_handle *handle;
> + int error;
> +
> + handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
> + if (!handle)
> + return -ENOMEM;
> +
> + handle->dev = dev;
> + handle->handler = handler;
> + handle->name = "rockchip-psr";
> +
> + error = input_register_handle(handle);
> + if (error)
> + goto err2;
> +
> + error = input_open_device(handle);
> + if (error)
> + goto err1;
> +
> + return 0;
> +
> +err1:
> + input_unregister_handle(handle);
> +err2:
> + kfree(handle);
> + return error;
> +}
> +
> +static void psr_input_disconnect(struct input_handle *handle)
> +{
> + input_close_device(handle);
> + input_unregister_handle(handle);
> + kfree(handle);
> +}
> +
> +/* Same device ids as cpu-boost */
> +static const struct input_device_id psr_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
> +  INPUT_DEVICE_ID_MATCH_ABSBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
> + BIT_MASK(ABS_MT_POSITION_X) |
> + BIT_MASK(ABS_MT_POSITION_Y) },
> + }, /* multi-touch touchscreen */
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
> +
> + }, /* stylus or joystick device */
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_KEY) },
> + .keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
> + }, /* pointer (e.g. trackpad, mouse) */
> + {
> +

Re: [PATCH v2 29/43] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:56PM +0100, Thierry Escande wrote:
> From: zain wang 
> 
> It's too early to detect fast link training, if other step after it
> failed, we will set fast_link flag to 1, and retry set_bridge again. In
> this case we will power down and power up panel power supply, and we
> will do fast link training since we have set fast_link flag to 1. In
> fact, we should do full link training now, not the fast link training.
> So we should move the fast link detection at the end of set_bridge.
> 
> Cc: Tomasz Figa 
> Signed-off-by: zain wang 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 42 
> +-
>  1 file changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index e7ab871e62b5..bee0f7aa5c23 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -599,7 +599,7 @@ static int analogix_dp_process_equalizer_training(struct 
> analogix_dp_device *dp)
>  {
>   int lane, lane_count, retval;
>   u32 reg;
> - u8 link_align, link_status[2], adjust_request[2], spread;
> + u8 link_align, link_status[2], adjust_request[2];
>  
>   usleep_range(400, 401);
>  
> @@ -643,20 +643,6 @@ static int analogix_dp_process_equalizer_training(struct 
> analogix_dp_device *dp)
>   dev_dbg(dp->dev, "final lane count = %.2x\n",
>   dp->link_train.lane_count);
>  
> - retval = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD,
> -);
> - if (retval != 1) {
> - dev_err(dp->dev, "failed to read downspread %d\n",
> - retval);
> - dp->fast_train_enable = false;
> - } else {
> - dp->fast_train_enable =
> - (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
> - true : false;
> - }
> - dev_dbg(dp->dev, "fast link training %s\n",
> - dp->fast_train_enable ? "supported" : "unsupported");
> -
>   dp->link_train.lt_state = FINISHED;
>  
>   return 0;
> @@ -997,6 +983,22 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void 
> *arg)
>   return IRQ_HANDLED;
>  }
>  
> +static int analogix_dp_fast_link_train_detection(struct analogix_dp_device 
> *dp)
> +{
> + int ret;
> + u8 spread;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to read downspread %d\n", ret);
> + return ret;
> + }
> + dp->fast_train_enable = !!(spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
> + dev_dbg(dp->dev, "fast link training %s\n",
> + dp->fast_train_enable ? "supported" : "unsupported");
> + return 0;
> +}
> +
>  static int analogix_dp_commit(struct analogix_dp_device *dp)
>  {
>   int ret;
> @@ -1039,8 +1041,16 @@ static int analogix_dp_commit(struct 
> analogix_dp_device *dp)
>   if (ret)
>   return ret;
>  
> - if (dp->psr_enable)
> + if (dp->psr_enable) {
>   ret = analogix_dp_enable_sink_psr(dp);
> + if (ret)
> + return ret;
> + }
> +
> + /* Check whether panel supports fast training */
> + ret =  analogix_dp_fast_link_train_detection(dp);
> + if (ret)
> + dp->psr_enable = false;

You could probably flip this with psr_enable and just return on error instead of
flipping psr_enable back. Not a big deal either way.

Sean

>  
>   return ret;
>  }
> -- 
> 2.14.1
> 

-- 
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: [PATCH v2 28/43] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:55PM +0100, Thierry Escande wrote:
> From: zain wang 
> 
> Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
> Exynos:
> 
> on Exynos edp phy,
> BIT 7 MASTER_VID_FUNC_EN_N
> BIT 6 reserved
> BIT 5 SLAVE_VID_FUNC_EN_N
> 
> on Rockchip edp phy,
> BIT 7 reserved
> BIT 6 RK_VID_CAP_FUNC_EN_N
> BIT 5 RK_VID_FIFO_FUNC_EN_N
> 
> So, we should do some private operations to Rockchip.
> 
> Cc: Tomasz Figa 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h |  2 ++
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 02ab1aaa9993..4eae206ec31b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
>   analogix_dp_stop_video(dp);
>   analogix_dp_enable_video_mute(dp, 0);
>  
> - reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> - AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> - HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
> + SW_FUNC_EN_N;
> + else
> + reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> + AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> + HDCP_FUNC_EN_N | SW_FUNC_EN_N;

The patch doesn't mention whether the other flags (AUD/HDCP) are relevant to
rockchip. Even in the CrOS tree we don't see these flags set for RK, so I guess
they're not. Would have been nice to know for certain. ¯\_(ツ)_/¯

Sean

> +
>   writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>  
>   reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
> @@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct 
> analogix_dp_device *dp)
>   u32 reg;
>  
>   reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> - reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> - reg |= MASTER_VID_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
> + } else {
> + reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> + reg |= MASTER_VID_FUNC_EN_N;
> + }
>   writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>  
>   reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> index b633a4a5082a..0cf27c731727 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> @@ -127,7 +127,9 @@
>  
>  /* ANALOGIX_DP_FUNC_EN_1 */
>  #define MASTER_VID_FUNC_EN_N (0x1 << 7)
> +#define RK_VID_CAP_FUNC_EN_N (0x1 << 6)
>  #define SLAVE_VID_FUNC_EN_N  (0x1 << 5)
> +#define RK_VID_FIFO_FUNC_EN_N(0x1 << 5)
>  #define AUD_FIFO_FUNC_EN_N   (0x1 << 4)
>  #define AUD_FUNC_EN_N(0x1 << 3)
>  #define HDCP_FUNC_EN_N   (0x1 << 2)
> -- 
> 2.14.1
> 

-- 
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: [PATCH v2 22/43] drm/bridge: analogix_dp: Check dpcd write/read status

[Sean Paul]

On Mon, Jan 29, 2018 at 04:14:41PM -0500, Sean Paul wrote:
> On Fri, Jan 26, 2018 at 02:16:49PM +0100, Thierry Escande wrote:
> > From: Lin Huang 
> > 
> > We need to check the dpcd write/read return value to see whether the
> > write/read was successful
> > 
> > Cc: Kristian H. Kristensen 
> > Signed-off-by: Lin Huang 
> > Signed-off-by: zain wang 
> > Signed-off-by: Douglas Anderson 
> > Signed-off-by: Sean Paul 
> > Signed-off-by: Thierry Escande 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 181 
> > +++--
> >  1 file changed, 132 insertions(+), 49 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 846574d0dcb0..501f7b4a23d6 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -160,80 +160,135 @@ int analogix_dp_disable_psr(struct 
> > analogix_dp_device *dp)
> >  }
> >  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
> >  
> > -static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> > +static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> >  {
> > unsigned char psr_version;
> > +   int ret;
> > +
> > +   ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> > +   if (ret != 1) {
> > +   dev_err(dp->dev, "failed to get PSR version, disable it\n");
> > +   return ret;
> > +   }
> >  
> > -   drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> > dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
> >  
> > -   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> > +   dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> > +
> > +   return 0;
> >  }
> >  
> > -static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> > +static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> >  {
> > unsigned char psr_en;
> > +   int ret;
> >  
> > /* Disable psr function */
> > -   drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> > +   ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> > +   if (ret != 1) {
> > +   dev_err(dp->dev, "failed to get psr config\n");
> > +   goto end;
> > +   }
> > +
> > psr_en &= ~DP_PSR_ENABLE;
> > -   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   if (ret != 1) {
> > +   dev_err(dp->dev, "failed to disable panel psr\n");
> > +   goto end;
> > +   }
> >  
> > /* Main-Link transmitter remains active during PSR active states */
> > psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> > -   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   if (ret != 1) {
> > +   dev_err(dp->dev, "failed to set panel psr\n");
> > +   goto end;
> > +   }
> >  
> > /* Enable psr function */
> > psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
> >  DP_PSR_CRC_VERIFICATION;
> > -   drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> > +   if (ret != 1) {
> > +   dev_err(dp->dev, "failed to set panel psr\n");
> > +   goto end;
> > +   }
> >  
> > analogix_dp_enable_psr_crc(dp);
> > +
> > +   return 0;
> > +end:
> > +   dev_err(dp->dev, "enable psr fail, force to disable psr\n");
> > +   dp->psr_enable = false;
> > +
> > +   return ret;
> >  }
> >  
> > -static void
> > +static int
> >  analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
> >bool enable)
> >  {
> > u8 data;
> > +   int ret;
> >  
> > -   drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> > +   ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> > +   if (ret < 0)
> > +   return ret;
> >  
> > if (enable)
> > -   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> > -  DP_LANE_COUNT_ENHANCED_FRAME_EN |
> > -   DPCD_LANE_COUNT_SET(data));
> > +   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> > +DP_LANE_COUNT_ENHANCED_FRAME_EN |
> > +DPCD_LANE_COUNT_SET(data));
> > else
> > -   drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> > -  DPCD_LANE_COUNT_SET(data));
> > +   ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> > +DPCD_LANE_COUNT_SET(data));
> > +
> > +   return ret < 0 ? ret : 0;
> >  }
> >  
> > -static int analogix_dp_is_enhanced_mode_available(struct 
> > analogix_dp_device *dp)

Re: [PATCH v2 24/43] drm/bridge: analogix_dp: Reset aux channel if an error occurred

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:51PM +0100, Thierry Escande wrote:
> From: Lin Huang 
> 
> AUX errors are caused by many different reasons. We may not know what
> happened in aux channel on failure, so let's reset aux channel if some
> errors occurred.
> 
> Cc: 征增 王 
> Cc: Douglas Anderson 
> Signed-off-by: Lin Huang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index dee1ba109b5f..7b7fd227e1f9 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -466,6 +466,10 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
>   reg = RPLY_RECEIV | AUX_ERR;
>   writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
>  
> + analogix_dp_set_analog_power_down(dp, AUX_BLOCK, true);
> + usleep_range(10, 11);

This is kind of lame. I don't think this needs to be _exactly_ 10us, even 10/20 
would be
an improvement. Since this is so infrequent, it's not a dealbreaker either way, 
I guess.

Sean

> + analogix_dp_set_analog_power_down(dp, AUX_BLOCK, false);
> +
>   analogix_dp_reset_aux(dp);
>  
>   /* Disable AUX transaction H/W retry */
> @@ -1159,7 +1163,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
> *dp,
>reg, !(reg & AUX_EN), 25, 500 * 1000);
>   if (ret) {
>   dev_err(dp->dev, "AUX CH enable timeout!\n");
> - return -ETIMEDOUT;
> + goto aux_error;
>   }
>  
>   /* TODO: Wait for an interrupt instead of looping? */
> @@ -1168,7 +1172,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
> *dp,
>reg, reg & RPLY_RECEIV, 10, 20 * 1000);
>   if (ret) {
>   dev_err(dp->dev, "AUX CH cmd reply timeout!\n");
> - return -ETIMEDOUT;
> + goto aux_error;
>   }
>  
>   /* Clear interrupt source for AUX CH command reply */
> @@ -1178,7 +1182,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
> *dp,
>   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
>   if (reg & AUX_ERR) {
>   writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
> - return -EREMOTEIO;
> + goto aux_error;
>   }
>  
>   /* Check AUX CH error access status */
> @@ -1186,7 +1190,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
> *dp,
>   if ((reg & AUX_STATUS_MASK)) {
>   dev_err(dp->dev, "AUX CH error happened: %d\n\n",
>   reg & AUX_STATUS_MASK);
> - return -EREMOTEIO;
> + goto aux_error;
>   }
>  
>   if (msg->request & DP_AUX_I2C_READ) {
> @@ -1212,4 +1216,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
> *dp,
>   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
>  
>   return num_transferred > 0 ? num_transferred : -EBUSY;
> +
> +aux_error:
> + /* if aux err happen, reset aux */
> + analogix_dp_init_aux(dp);
> +
> + return -EREMOTEIO;
>  }
> -- 
> 2.14.1
> 

-- 
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: Various TTM cleanups (v2)

[Felix Kuehling]

The series is Reviewed-by: Felix Kuehling 

Regards,
  Felix


On 2018-01-29 08:55 AM, Tom St Denis wrote:
> Various TTM cleanups (mostly no functional changes).
>
> Notably patch #1 fixes a bug in the access_kmap() function.
>
> The rest are either coding style fixes or simplifications.
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

Re: [PATCH v2 22/43] drm/bridge: analogix_dp: Check dpcd write/read status

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:49PM +0100, Thierry Escande wrote:
> From: Lin Huang 
> 
> We need to check the dpcd write/read return value to see whether the
> write/read was successful
> 
> Cc: Kristian H. Kristensen 
> Signed-off-by: Lin Huang 
> Signed-off-by: zain wang 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 181 
> +++--
>  1 file changed, 132 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 846574d0dcb0..501f7b4a23d6 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -160,80 +160,135 @@ int analogix_dp_disable_psr(struct analogix_dp_device 
> *dp)
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>  
> -static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
>  {
>   unsigned char psr_version;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get PSR version, disable it\n");
> + return ret;
> + }
>  
> - drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
>   dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
>  
> - return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> + dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> +
> + return 0;
>  }
>  
> -static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
>  {
>   unsigned char psr_en;
> + int ret;
>  
>   /* Disable psr function */
> - drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get psr config\n");
> + goto end;
> + }
> +
>   psr_en &= ~DP_PSR_ENABLE;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to disable panel psr\n");
> + goto end;
> + }
>  
>   /* Main-Link transmitter remains active during PSR active states */
>   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>  
>   /* Enable psr function */
>   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
>DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>  
>   analogix_dp_enable_psr_crc(dp);
> +
> + return 0;
> +end:
> + dev_err(dp->dev, "enable psr fail, force to disable psr\n");
> + dp->psr_enable = false;
> +
> + return ret;
>  }
>  
> -static void
> +static int
>  analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
>  bool enable)
>  {
>   u8 data;
> + int ret;
>  
> - drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + if (ret < 0)
> + return ret;
>  
>   if (enable)
> - drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> -DP_LANE_COUNT_ENHANCED_FRAME_EN |
> - DPCD_LANE_COUNT_SET(data));
> + ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> +  DP_LANE_COUNT_ENHANCED_FRAME_EN |
> +  DPCD_LANE_COUNT_SET(data));
>   else
> - drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> -DPCD_LANE_COUNT_SET(data));
> + ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> +  DPCD_LANE_COUNT_SET(data));
> +
> + return ret < 0 ? ret : 0;
>  }
>  
> -static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
> *dp)
> +static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device 
> *dp,
> +   u8 *enhanced_mode_support)
>  {
>   u8 

Re: [PATCH v2 20/43] drm/bridge: analogix_dp: Extend hpd check time to 100ms

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:47PM +0100, Thierry Escande wrote:
> From: Lin Huang 
> 
> There was a 1ms delay to detect the hpd signal, which is too short to
> detect a short pulse. This patch extends this delay to 100ms.

The commit message doesn't align with the code here. The code below matches the
code in the CrOS tree, so let's just fix up the commit message.


> 
> Cc: Stéphane Marchesin 
> Cc: 征增 王 
> Signed-off-by: Lin Huang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index fa4ef28e286f..9df92dc54dbe 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
> *dp)
>   return 0;
>  
>   timeout_loop++;
> - usleep_range(10, 11);
> + usleep_range(1000, 1100);
>   }
>  
>   /*
> -- 
> 2.14.1
> 

-- 
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: [PATCH v2 01/43] drm/rockchip: Get rid of unnecessary struct fields

[Sean Paul]

On Fri, Jan 26, 2018 at 02:16:28PM +0100, Thierry Escande wrote:
> From: Tomasz Figa 
> 
> This patch removes unused fields from vop structure.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 


Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index ba7505292b78..7a137bc5708c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -95,9 +95,6 @@ struct vop {
>   struct drm_device *drm_dev;
>   bool is_enabled;
>  
> - /* mutex vsync_ work */
> - struct mutex vsync_mutex;
> - bool vsync_work_pending;
>   struct completion dsp_hold_completion;
>  
>   /* protected by dev->event_lock */
> @@ -1567,8 +1564,6 @@ static int vop_bind(struct device *dev, struct device 
> *master, void *data)
>   spin_lock_init(>reg_lock);
>   spin_lock_init(>irq_lock);
>  
> - mutex_init(>vsync_mutex);
> -
>   ret = devm_request_irq(dev, vop->irq, vop_isr,
>  IRQF_SHARED, dev_name(dev), vop);
>   if (ret)
> -- 
> 2.14.1
> 

-- 
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: [AMDGPU][TAHITI XT] new display code

[Alex Deucher]

On Mon, Jan 29, 2018 at 3:34 PM,   wrote:
> On Mon, Jan 29, 2018 at 02:39:53PM -0500, Alex Deucher wrote:
>> On Mon, Jan 29, 2018 at 2:31 PM,   wrote:
>> > On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote:
>> >> It's similar, but there is still a bunch of DCE specific code.  No one
>> >> has written that DC code for DCE 6 yet.  One could use the DC DCE8
>> >> code as a guide, but it still has to be done.
>> >
>> > I have not checked the new code, but does it mean the atombios is gone for 
>> > DCE
>> > programming?
>>
>> It's still there. Even with atombios, there is still a bunch of DCE
>> specific programming required (page flips, interrupts, hotplug,
>> watermarks, LUTs, cursors, etc.).  DC also adds support for a bunch of
>> new features that are were not supported by either atombios or the old
>> modesetting code (regamma/CTM, DP/HDMI audio, dchub programming for
>> display buffers in system memory for APUs, etc.).
>
> As far as I can remember, not for the new features ofc, DCE programming for 
> GCN1
> is very similar if not mostly the same than DCE programming for GCN1.1/2 which
> is supported by the new DC code.
>
> Is this planned?

Right, as I said, you could definitely leverage the support for DCE8
in DC.  The blocks are very similar.  At the moment, we have no plans
to implement DC support for DCE6.

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

Re: [AMDGPU][TAHITI XT] new display code

[sylvain . bertrand]

On Mon, Jan 29, 2018 at 02:39:53PM -0500, Alex Deucher wrote:
> On Mon, Jan 29, 2018 at 2:31 PM,   wrote:
> > On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote:
> >> It's similar, but there is still a bunch of DCE specific code.  No one
> >> has written that DC code for DCE 6 yet.  One could use the DC DCE8
> >> code as a guide, but it still has to be done.
> >
> > I have not checked the new code, but does it mean the atombios is gone for 
> > DCE
> > programming?
> 
> It's still there. Even with atombios, there is still a bunch of DCE
> specific programming required (page flips, interrupts, hotplug,
> watermarks, LUTs, cursors, etc.).  DC also adds support for a bunch of
> new features that are were not supported by either atombios or the old
> modesetting code (regamma/CTM, DP/HDMI audio, dchub programming for
> display buffers in system memory for APUs, etc.).

As far as I can remember, not for the new features ofc, DCE programming for 
GCN1 
is very similar if not mostly the same than DCE programming for GCN1.1/2 which
is supported by the new DC code.

Is this planned?

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

Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Sean Paul]

On Thu, Jan 18, 2018 at 10:23:55AM +0530, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode. Add an example of an I2C controlled
> device operating in dual-channel DSI mode.
> 
> Signed-off-by: Archit Taneja 

Reviewed-by: Sean Paul 

> ---
> v2:
> - Specify that clock-master is a boolean property.
> - Drop/add unit-address and #*-cells where applicable.
> 
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 
> ++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 94fb72cb916f..7a3abbedb3fa 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,13 @@ Required properties:
>  - #size-cells: Should be 0. There are cases where it makes sense to use a
>different value here. See below.
>  
> +Optional properties:
> +- clock-master: boolean. Should be enabled if the host is being used in
> +  conjunction with another DSI host to drive the same peripheral. Hardware
> +  supporting such a configuration generally requires the data on both the 
> busses
> +  to be driven by the same clock. Only the DSI host instance controlling this
> +  clock should contain this property.
> +
>  DSI peripheral
>  ==
>  
> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus 
> (mostly for the data
>  path). Connections between such peripherals and a DSI host can be represented
>  using the graph bindings [1], [2].
>  
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the 
> display).
> +The graph bindings should be used to represent the multiple DSI busses that 
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked 
> to
> +an input endpoint of the DSI peripheral.
> +
>  [1] Documentation/devicetree/bindings/graph.txt
>  [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -71,6 +88,8 @@ Examples
>with different virtual channel configurations.
>  - (4) is an example of a peripheral on a I2C control bus connected with to
>a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> +  which uses I2C as its primary control bus.
>  
>  1)
>   dsi-host {
> @@ -153,3 +172,64 @@ Examples
>   };
>   };
>   };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> +  * this DSI instance drives the clock for both the host
> +  * controllers
> +  */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port {
> + dsi0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> + dsi1_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list

Re: [PATCH 00/10] drm/uapi: Validate mode flags/type, and deprecate some of them

[Ville Syrjälä]

On Tue, Nov 14, 2017 at 08:32:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> I recently realized that we're not validating the mode flags/type
> passed in from userspace. Let's try to fix that.
> 
> I'd also like to entirely eliminate some of the more crazy mode flags.
> PIXMUX and BCAST look pretty easy, so I've targetted them first.
> 
> Ideally I'd like to kill DBLCLK, CLKDIV2, HSKEW, DBLSCAN, and vscan
> as well. IMO there's no good reason to expose any of that to userspace,
> and instead it should all be handled internally by the drivers.
> Unfortunately all of those seem to be used to some degree by a handful
> of drivers.
> 
> I also tried to nuke some of the crazy mode types.
> 
> Cc: Jose Abreu 
> Cc: Adam Jackson 
> Cc: Keith Packard 
> 
> Ville Syrjälä (10):
>   drm/modes: Move 3D stereo flag check into drm_mode_validate_basic()
>   drm/uapi: Validate the mode flags/type
>   drm/uapi: Deprecate DRM_MODE_FLAG_PIXMUX
>   drm/uapi: Deprecate DRM_MODE_FLAG_BCAST
>   drm/modes: Fix description of DRM_MODE_TYPE_USERDEF
>   drm/modes: Kill off the oddball DRM_MODE_TYPE_CRTC_C vs.
> DRM_MODE_TYPE_BUILTIN handling
>   drm/modes: Kill DRM_MODE_TYPE_CLOCK_CRTC_C define
>   drm/uapi: Deprecate nonsense kms mode types
>   drm/modes: Provide global mode_valid hook
>   drm/i915: Provide a device level .mode_valid() hook

Entire series pushed to drm-misc-next. Thanks for the reviews.

> 
>  drivers/gpu/drm/drm_atomic.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c   |  2 +-
>  drivers/gpu/drm/drm_modes.c  | 60 
> +---
>  drivers/gpu/drm/drm_probe_helper.c   |  2 +-
>  drivers/gpu/drm/i915/intel_crt.c |  3 --
>  drivers/gpu/drm/i915/intel_display.c | 27 
>  drivers/gpu/drm/i915/intel_dsi.c |  5 ---
>  drivers/gpu/drm/i915/intel_dvo.c |  3 --
>  drivers/gpu/drm/i915/intel_fbc.c |  3 +-
>  drivers/gpu/drm/i915/intel_hdmi.c|  3 --
>  drivers/gpu/drm/i915/intel_sdvo.c|  3 --
>  include/drm/drm_mode_config.h| 12 
>  include/drm/drm_modes.h  | 24 +++
>  include/uapi/drm/drm_mode.h  | 30 ++
>  14 files changed, 120 insertions(+), 59 deletions(-)
> 
> -- 
> 2.13.6

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

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 29, 2018 at 12:26:00PM +0200, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> > The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> > ports. Each map has it own I²C address and acts as a standard slave
> > device on the I²C bus.
> > 
> > Allow a device tree node to override the default addresses so that
> > address conflicts with other devices on the same bus may be resolved at
> > the board description level.
> > 
> > Signed-off-by: Kieran Bingham 
> > ---
> >  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> 
> I don't mind personally, but device tree maintainers usually ask for DT 
> bindings changes to be split to a separate patch.

Or perfect bindings, then I won't ask to split it just for that 
(usually).

> >  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
> >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ---
> >  3 files changed, 37 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 22, 2018 at 12:50:01PM +, Kieran Bingham wrote:
> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-

Reviewed-by: Rob Herring 

>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 
> ++
>  3 files changed, 37 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Sean Paul]

On Thu, Jan 18, 2018 at 10:23:54AM +0530, Archit Taneja wrote:
> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus, or no
> control bus at all. Add an example for a peripheral with a non-DSI
> control bus.
> 
> Signed-off-by: Archit Taneja 
> ---
> v2:
> - Mentioned what to do if peripheral has no control bus
> - Drop unit-address and #*-cells where applicable.
> 
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 
> +++---
>  1 file changed, 64 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 973c27273772..94fb72cb916f 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
> connected to a DSI
>  host. Experience shows that this is true for the large majority of setups.
>  
>  DSI host
> -
> +
>  
>  In addition to the standard properties and those defined by the parent bus of
>  a DSI host, the following properties apply to a node representing a DSI host.
> @@ -30,11 +30,16 @@ Required properties:
>different value here. See below.
>  
>  DSI peripheral
> ---
> +==
>  
> -Peripherals are represented as child nodes of the DSI host's node. Properties
> -described here apply to all DSI peripherals, but individual bindings may want
> -to define additional, device-specific properties.
> +Peripherals with DSI as control bus, or no control bus
> +--
> +
> +Peripherals with the DSI bus as the primary control bus, or peripherals with
> +no control bus but use the DSI bus to transmit pixel data are represented
> +as child nodes of the DSI host's node. Properties described here apply to all
> +DSI peripherals, but individual bindings may want to define additional,
> +device-specific properties.
>  
>  Required properties:
>  - reg: The virtual channel number of a DSI peripheral. Must be in the range
> @@ -49,9 +54,25 @@ case two alternative representations can be chosen:
>property is the number of the first virtual channel and the second cell is
>the number of consecutive virtual channels.
>  
> -Example
> 
> +Peripherals with a different control bus
> +
> +
> +There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
> +primary control bus, but are also connected to a DSI bus (mostly for the data
> +path). Connections between such peripherals and a DSI host can be represented
> +using the graph bindings [1], [2].
> +
> +[1] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> +Examples
> +
> +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
> +  with different virtual channel configurations.
> +- (4) is an example of a peripheral on a I2C control bus connected with to

s/with to/with/ or s/with to/to/

Reviewed-by: Sean Paul 

> +  a DSI host using of-graph bindings.
> +
> +1)
>   dsi-host {
>   ...
>  
> @@ -67,6 +88,7 @@ Example
>   ...
>   };
>  
> +2)
>   dsi-host {
>   ...
>  
> @@ -82,6 +104,7 @@ Example
>   ...
>   };
>  
> +3)
>   dsi-host {
>   ...
>  
> @@ -96,3 +119,37 @@ Example
>  
>   ...
>   };
> +
> +4)
> + i2c-host {
> + ...
> +
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port {
> + bridge_mipi_in: endpoint {
> + remote-endpoint = 
> <_mipi_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> + host_mipi_out: endpoint {
> + remote-endpoint = <_mipi_in>;
> + };
> + };
> + };
> + };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

-- 
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: [PATCH 1/2] media: adv7604: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 22, 2018 at 12:49:56PM +, Kieran Bingham wrote:
> From: Jean-Michel Hautbois 
> 
> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> I²C ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Jean-Michel Hautbois 
> [Kieran: Re-adapted for mainline]
> Signed-off-by: Kieran Bingham 
> ---
> Based upon the original posting :
>   https://lkml.org/lkml/2014/10/22/469
> ---
>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-

Reviewed-by: Rob Herring 

In the future, please split bindings to separate patch.

>  drivers/media/i2c/adv7604.c| 60 
> ++
>  2 files changed, 55 insertions(+), 23 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[Sean Paul]

On Thu, Jan 25, 2018 at 09:23:45PM -0800, John Stultz wrote:
> On Wed, Jan 24, 2018 at 7:46 AM, Sean Paul  wrote:
> > On Tue, Jan 23, 2018 at 03:16:37PM -0800, John Stultz wrote:
> >> +#ifdef HIKEY
> >> +uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> >> +  switch (hal_format) {
> >> +case HAL_PIXEL_FORMAT_RGB_888:
> >> +  return DRM_FORMAT_BGR888;
> >> +case HAL_PIXEL_FORMAT_BGRA_:
> >> +  return DRM_FORMAT_ARGB;
> >> +case HAL_PIXEL_FORMAT_RGBX_:
> >> +  return DRM_FORMAT_XBGR;
> >> +case HAL_PIXEL_FORMAT_RGBA_:
> >> +  return DRM_FORMAT_ABGR;
> >> +case HAL_PIXEL_FORMAT_RGB_565:
> >> +  return DRM_FORMAT_BGR565;
> >> +case HAL_PIXEL_FORMAT_YV12:
> >> +  return DRM_FORMAT_YVU420;
> >> +default:
> >> +  ALOGE("Cannot convert hal format to drm format %u", hal_format);
> >> +  return -EINVAL;
> >> +  }
> >
> > This is the same as the generic case, and below is a little confusing to me.
> 
> Yes. HiKey is the same as the generic case.
> 
> >> +}
> >> +#else /* HIKEY960 case*/
> >> +uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
> >> +  switch (hal_format) {
> >> +case HAL_PIXEL_FORMAT_RGB_888:
> >> +  return DRM_FORMAT_BGR888;
> >> +case HAL_PIXEL_FORMAT_BGRA_:
> >> +  return DRM_FORMAT_XBGR;
> >> +case HAL_PIXEL_FORMAT_RGBX_:
> >> +  return DRM_FORMAT_XBGR;
> >> +case HAL_PIXEL_FORMAT_RGBA_:
> >> +  return DRM_FORMAT_XBGR;
> >> +case HAL_PIXEL_FORMAT_RGB_565:
> >> +  return DRM_FORMAT_BGR565;
> >> +case HAL_PIXEL_FORMAT_YV12:
> >> +  return DRM_FORMAT_YVU420;
> >> +default:
> >> +  ALOGE("Cannot convert hal format to drm format %u", hal_format);
> >> +  return -EINVAL;
> >> +  }
> >
> > So it seems like we're smashing a whole bunch of formats into XBGR 
> > here, and
> > I'm not sure how it'll work. If you look above, the primary difference 
> > between
> > the HAL and drm formats is that the subpixels are reversed (ie: RGBA becomes
> > ABGR). In this snippet, you've got BGRA->XBGR, does this actually work?
> 
> Honestly the above is some sort of dyslexia nightmare for me, so I may
> have gotten it slightly wrong. :)
> 

I can certainly sympathize with this. It took me longer than I'd like to admit
to write the above. This seems like a good reason to change things up!


> So my understanding is that for the HiKey960/bifrost the As need to be
> Xs (and I've verified that we don't get anything if we try to leave
> the X's), and we have to switch the R/Bs to get the colors right.  It
> may be the R/B switching is due to other quirks in gralloc and the drm
> driver, I'm not sure.

It'd be nice to figure out. I suspect there's a bug somewhere that's re-
reversing things. 


> 
> > Furthermore, when I look at the kirin driver (I think that's what you use on
> > hikey?), I see full support for all the above formats. So 2 questions:
> 
> So, on HiKey960 we have the out-of-tree kirin960 drm driver, which is
> one of those vendor code drops that is similar but different enough
> that its a pain to whittle down if extending the kirin driver can be
> done to support it, I've not been involved in the upstreaming effort
> for that driver, so I'm not sure what the plan is yet.
> 
> > 1- Does this work as expected
> 
> So yes, the code here does work.  But we're only exercising the
> BGRA_ path, so the rest could very well be wrong.
> 
> 
> > 2- Is there an opportunity to share code between platforms instead of
> > copy-pasting this function over and over again? Perhaps each platform 
> > provides
> > the formats they support and we have the base class do a mapping based on 
> > what
> > is present?
> 
> My C++ is ~20 years stale, but I'll take a look to see what I can do there.
> 
> >> +#ifdef HIKEY
> >> +  bo->pitches[0] = hnd->width * 4;
> >
> > Does this work for formats that are not 32-bit?
> 
> Probably not. I'll try to sort that out in a better way too.
> 
> 
> >> +int HisiImporter::ReleaseBuffer(hwc_drm_bo_t *bo) {
> >> +  if (bo->fb_id)
> >> +if (drmModeRmFB(drm_->fd(), bo->fb_id))
> >> +  ALOGE("Failed to rm fb");
> >> +
> >> +  struct drm_gem_close gem_close;
> >> +  memset(_close, 0, sizeof(gem_close));
> >> +  int num_gem_handles = sizeof(bo->gem_handles) / 
> >> sizeof(bo->gem_handles[0]);
> >> +  for (int i = 0; i < num_gem_handles; i++) {
> >> +if (!bo->gem_handles[i])
> >> +  continue;
> >> +
> >> +gem_close.handle = bo->gem_handles[i];
> >> +int ret = drmIoctl(drm_->fd(), DRM_IOCTL_GEM_CLOSE, _close);
> >> +if (ret)
> >> +  ALOGE("Failed to close gem handle %d %d", i, ret);
> >> +else
> >> +  bo->gem_handles[i] = 0;
> >> +  }
> >> +  return 0;
> >> +}
> >
> > This function is a straight copy-paste from generic, right? Let's try to do
> > better than that. Perhaps you should be subclassing the drm generic platform
> > instead?
> 

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

[Rob Herring]

On Fri, Jan 19, 2018 at 09:29:20PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car LVDS bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring 

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

Re: [PATCH v6 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Rob Herring]

On Fri, Jan 19, 2018 at 05:13:42PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 43 
> ++
>  drivers/iommu/arm-smmu.c   | 13 +++
>  2 files changed, 56 insertions(+)

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

Re: [AMDGPU][TAHITI XT] new display code

[Alex Deucher]

On Mon, Jan 29, 2018 at 2:31 PM,   wrote:
> On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote:
>> It's similar, but there is still a bunch of DCE specific code.  No one
>> has written that DC code for DCE 6 yet.  One could use the DC DCE8
>> code as a guide, but it still has to be done.
>
> I have not checked the new code, but does it mean the atombios is gone for DCE
> programming?

It's still there. Even with atombios, there is still a bunch of DCE
specific programming required (page flips, interrupts, hotplug,
watermarks, LUTs, cursors, etc.).  DC also adds support for a bunch of
new features that are were not supported by either atombios or the old
modesetting code (regamma/CTM, DP/HDMI audio, dchub programming for
display buffers in system memory for APUs, etc.).

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

Re: [PATCH v2 1/2] DT: display: renesas,du: document R8A77970 bindings

[Sergei Shtylyov]

On 01/29/2018 10:02 PM, Rob Herring wrote:

>> Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings.
>>
>> Signed-off-by: Sergei Shtylyov 
>>
>> ---
>> Changes in version 2:
>> - documented  R8A77970 DU ports;
>> - patch split from the main R8A77970 DU support patch.
>>
>>  Documentation/devicetree/bindings/display/renesas,du.txt |2 ++
>>  1 file changed, 2 insertions(+)
> 
> Acked-by: Rob Herring 

   Thank you!
 
> The preferred subject prefix is "dt-bindings: display: ..."

   I use it for the stuff in include/dt-bindings/. :-)

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

Re: [AMDGPU][TAHITI XT] new display code

[sylvain . bertrand]

On Mon, Jan 29, 2018 at 01:58:46PM -0500, Alex Deucher wrote:
> It's similar, but there is still a bunch of DCE specific code.  No one
> has written that DC code for DCE 6 yet.  One could use the DC DCE8
> code as a guide, but it still has to be done.

I have not checked the new code, but does it mean the atombios is gone for DCE
programming?

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

[PULL] Backlight helpers from tinydrm

[Sean Paul]

Hi Lee,
Here's the pull request for Meghana's patch set. It's based on 4.15, and just
contains the backlight portion of the set. I couldn't include the rest as it
depends on patches that only exist in drm-misc-next atm.

Thanks for coordinating with me on this!


topic/backlight_for_lag-2018-01-29:
This contains the backlight portion of Meghana Madhyastha's patch set to
migrate the backlight helpers from tinydrm to the backlight subsystem.

https://patchwork.freedesktop.org/series/36522/

Cc: Meghana Madhyastha 

Cheers, Sean


The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:

  Linux 4.15 (2018-01-28 13:20:33 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc 
tags/topic/backlight_for_lag-2018-01-29

for you to fetch changes up to 2e4ef3347b4a4eb65c4fd950d94bbd75fed4d798:

  video: backlight: Add devres versions of of_find_backlight (2018-01-29 
10:34:53 -0500)


This contains the backlight portion of Meghana Madhyastha's patch set to
migrate the backlight helpers from tinydrm to the backlight subsystem.

https://patchwork.freedesktop.org/series/36522/

Cc: Meghana Madhyastha 


Meghana Madhyastha (3):
  video: backlight: Add helpers to enable and disable backlight
  video: backlight: Add of_find_backlight helper in backlight.c
  video: backlight: Add devres versions of of_find_backlight

 drivers/video/backlight/backlight.c | 73 +
 include/linux/backlight.h   | 58 +
 2 files changed, 131 insertions(+)

-- 
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: [PATCH v2 1/2] DT: display: renesas,du: document R8A77970 bindings

[Rob Herring]

On Fri, Jan 19, 2018 at 12:05:58AM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> Changes in version 2:
> - documented  R8A77970 DU ports;
> - patch split from the main R8A77970 DU support patch.
> 
>  Documentation/devicetree/bindings/display/renesas,du.txt |2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 

The preferred subject prefix is "dt-bindings: display: ..."
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [AMDGPU][TAHITI XT] new display code

[Alex Deucher]

On Mon, Jan 29, 2018 at 1:45 PM,   wrote:
> On Mon, Jan 29, 2018 at 01:04:08PM -0500, Alex Deucher wrote:
>> On Mon, Jan 29, 2018 at 12:56 PM,   wrote:
>> > Hi,
>> >
>> > I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new
>> > display code is not available for gcn1 hardware?
>>
>> No one has written the code.
>
> I don't understand. Isn't the code for DCE programing pretty similar across 
> all
> generations due to the atombios?
>
> I guess I miss something.

It's similar, but there is still a bunch of DCE specific code.  No one
has written that DC code for DCE 6 yet.  One could use the DC DCE8
code as a guide, but it still has to be done.

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

Re: [PATCH v3 6/8] drm: Expose modes with aspect ratio, only if requested

[Ville Syrjälä]

On Fri, Jan 12, 2018 at 11:51:34AM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> We parse the EDID and add all the modes in the connector's
> modelist. This adds CEA modes with aspect ratio information
> too, regadless of if user space requested this information or
> not.
> 
> This patch prunes the modes with aspect-ratio information, from
> a connector's modelist, if the user-space has not set the aspect
> ratio DRM client cap.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Cc: Jose Abreu 
> 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: As suggested by Ville, modified the mechanism of pruning of
> modes with aspect-ratio, if the aspect-ratio is not supported.
> Instead of straight away pruning such a mode, the mode is
> retained with aspect-ratio bits set to zero, provided it is
> unique.
> ---
>  drivers/gpu/drm/drm_connector.c | 31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a774..d968ec3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1502,7 +1502,8 @@ static struct drm_encoder 
> *drm_connector_get_encoder(struct drm_connector *conne
>   return connector->encoder;
>  }
>  
> -static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> +static bool drm_mode_expose_to_userspace(const struct drm_display_mode 
> *last_mode,
> +  const struct drm_display_mode *mode,
>const struct drm_file *file_priv)
>  {
>   /*
> @@ -1511,6 +1512,18 @@ static bool drm_mode_expose_to_userspace(const struct 
> drm_display_mode *mode,
>*/
>   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
>   return false;
> + /*
> +  * If user-space hasn't configured the driver to expose the modes
> +  * with aspect-ratio, don't expose them.
> +  */
> + if (!file_priv->aspect_ratio_allowed &&
> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE &&
> + drm_mode_match(mode, last_mode,
> +DRM_MODE_MATCH_TIMINGS |
> +DRM_MODE_MATCH_CLOCK |
> +DRM_MODE_MATCH_FLAGS |
> +DRM_MODE_MATCH_3D_FLAGS))
> + return false;
>  
>   return true;
>  }
> @@ -1522,6 +1535,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   struct drm_connector *connector;
>   struct drm_encoder *encoder;
>   struct drm_display_mode *mode;
> + struct drm_display_mode last_valid_mode;

A pointer should be sufficient.

>   int mode_count = 0;
>   int encoders_count = 0;
>   int ret = 0;
> @@ -1577,9 +1591,12 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   out_resp->connection = connector->status;
>  
>   /* delayed so we get modes regardless of pre-fill_modes state */
> + memset(_valid_mode, 0, sizeof(struct drm_display_mode));
>   list_for_each_entry(mode, >modes, head)
> - if (drm_mode_expose_to_userspace(mode, file_priv))
> + if (drm_mode_expose_to_userspace(_valid_mode, mode, 
> file_priv)) {
>   mode_count++;
> + drm_mode_copy(_valid_mode, mode);
> + }
>  
>   /*
>* This ioctl is called twice, once to determine how much space is
> @@ -1588,10 +1605,16 @@ int drm_mode_getconnector(struct drm_device *dev, 
> void *data,
>   if ((out_resp->count_modes >= mode_count) && mode_count) {
>   copied = 0;
>   mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
> long)out_resp->modes_ptr;
> + memset(_valid_mode, 0, sizeof(struct drm_display_mode));
>   list_for_each_entry(mode, >modes, head) {
> - if (!drm_mode_expose_to_userspace(mode, file_priv))
> + if (!drm_mode_expose_to_userspace(_valid_mode,
> +   mode,
> +   file_priv))
>   continue;
> -
> + if (!file_priv->aspect_ratio_allowed)
> + mode->picture_aspect_ratio =
> + HDMI_PICTURE_ASPECT_NONE;

Here you're clobbering the internal mode structure. That's not
acceptable.

> + drm_mode_copy(_valid_mode, mode);
>   drm_mode_convert_to_umode(_mode, mode);
>   if (copy_to_user(mode_ptr + copied,
>_mode, sizeof(u_mode))) {
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list

Re: [PATCH v3 5/8] drm: Handle aspect ratio info in atomic and legacy modeset paths

[Ville Syrjälä]

On Fri, Jan 12, 2018 at 11:51:33AM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> If the user mode does not support aspect-ratio, and requests for
> a modeset, then the flag bits representing aspect ratio in the
> given user-mode must be rejected.
> Similarly, while preparing a user-mode from kernel mode, the
> aspect-ratio info must not be given, if aspect-ratio is not
> supported by the user.
> 
> This patch:
> 1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
> which is set only if the aspect-ratio is supported by the user.
> 2. discards the aspect-ratio info from the user mode while
> preparing kernel mode structure, during modeset, if the
> user does not support aspect ratio.
> 3. avoids setting the aspect-ratio info in user-mode, while
> converting user-mode from the kernel-mode.
> 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: Addressed review comments from Ville:
> -Do not corrupt the current crtc state by updating aspect ratio
> on the fly.
> ---
>  drivers/gpu/drm/drm_atomic.c | 61 
> +---
>  drivers/gpu/drm/drm_crtc.c   | 19 ++
>  include/drm/drm_atomic.h |  2 ++
>  3 files changed, 79 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 69ff763..39313e2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -316,6 +316,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
> drm_atomic_state *state,
>  
>   return fence_ptr;
>  }
> +/**
> + * drm_atomic_allow_aspect_ratio_for_kmode
> + * @state: the crtc state
> + * @mode: kernel-internal mode, which is used to create a duplicate mode,
> + * with updated picture aspect ratio.
> + *
> + * Allow the aspect ratio info in the kernel mode only if aspect ratio is
> + * supported.
> + *
> + * RETURNS:
> + * kernel-internal mode with updated picture aspect ratio value.
> + */
> +
> +struct drm_display_mode*
> +drm_atomic_allow_aspect_ratio_for_kmode(struct drm_crtc_state *state,
> + const struct drm_display_mode *mode)
> +{
> + struct drm_atomic_state *atomic_state = state->state;
> + struct drm_display_mode *ar_kmode;
> +
> + ar_kmode = drm_mode_duplicate(state->crtc->dev, mode);
> + /*
> +  * If aspect ratio is not supported, set the picture aspect ratio as
> +  * NONE.
> +  */
> + if (atomic_state && !atomic_state->allow_aspect_ratio)
> + ar_kmode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + return ar_kmode;
> +}
>  
>  /**
>   * drm_atomic_set_mode_for_crtc - set mode for CRTC
> @@ -341,7 +370,10 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>   state->mode_blob = NULL;
>  
>   if (mode) {
> - drm_mode_convert_to_umode(, mode);
> + struct drm_display_mode *ar_mode;
> +
> + ar_mode = drm_atomic_allow_aspect_ratio_for_kmode(state, mode);
> + drm_mode_convert_to_umode(, ar_mode);

This still looks sketchy.

I believe there are just two places where we need to filter out the
aspect ratio flags from the umode, namely the getblob and getcrtc
ioctls.

And for checking the user input I think we should probably just
stick that into drm_mode_convert_umode(). Looks like we never call
that from anywhere but the atomic/setprop and setcrtc paths with
a non-NULL argument.

I *think* those three places should be sufficient to cover everything.

>   state->mode_blob =
>   drm_property_create_blob(state->crtc->dev,
>sizeof(umode),
> @@ -349,10 +381,11 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>   if (IS_ERR(state->mode_blob))
>   return PTR_ERR(state->mode_blob);
>  
> - drm_mode_copy(>mode, mode);
> + drm_mode_copy(>mode, ar_mode);
>   state->enable = true;
>   DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  mode->name, state);
> +  ar_mode->name, state);
> + drm_mode_destroy(state->crtc->dev, ar_mode);
>   } else {
>   memset(>mode, 0, sizeof(state->mode));
>   state->enable = false;
> @@ -436,6 +469,25 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>  }
>  
>  /**
> + * drm_atomic_allow_aspect_ratio_for_umode
> + * @state: the crtc state
> + * @umode: userspace mode, whose aspect ratio flag bits are to be updated.
> + *
> + * Allow the aspect ratio info in the userspace mode only if aspect ratio is
> + * supported.
> + */
> +void
> +drm_atomic_allow_aspect_ratio_for_umode(struct drm_crtc_state *state,
> + struct drm_mode_modeinfo *umode)
> +{
> + struct drm_atomic_state *atomic_state = state->state;
> +
> +

Re: [RFC v2 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Rob Herring]

On Thu, Jan 18, 2018 at 10:23:54AM +0530, Archit Taneja wrote:
> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus, or no
> control bus at all. Add an example for a peripheral with a non-DSI
> control bus.
> 
> Signed-off-by: Archit Taneja 
> ---
> v2:
> - Mentioned what to do if peripheral has no control bus
> - Drop unit-address and #*-cells where applicable.
> 
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 
> +++---
>  1 file changed, 64 insertions(+), 7 deletions(-)

Reviewed-by: Rob Herring 

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

[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, ) == -22

[bugzilla-daemon]

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

--- Comment #12 from Ricardo Perez  ---
This tests continue failing on CFL QA

igt@gem_ctx_param@invalid-param-get
igt@gem_ctx_param@invalid-param-set

IGT-Version: 1.21-g37bd27f (x86_64) (Linux:
4.15.0-rc9-drm-intel-qa-ww4-commit-59275f1+ x86_64)
--
for igt@gem_ctx_param@invalid-param-get

 DEBUG 
(gem_ctx_param:8293) CRITICAL: Test assertion failure function __real_main31,
file gem_ctx_param.c:147:
(gem_ctx_param:8293) CRITICAL: Failed assertion: __gem_context_get_param(fd,
) == -22
(gem_ctx_param:8293) CRITICAL: error: 0 != -22
(gem_ctx_param:8293) igt-core-INFO: Stack trace:
(gem_ctx_param:8293) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(gem_ctx_param:8293) igt-core-INFO:   #1 [__real_main31+0x7fd]
(gem_ctx_param:8293) igt-core-INFO:   #2 [main+0x27]
(gem_ctx_param:8293) igt-core-INFO:   #3 [__libc_start_main+0xf1]
(gem_ctx_param:8293) igt-core-INFO:   #4 [_start+0x2a]
(gem_ctx_param:8293) igt-core-INFO:   #5 [+0x2a]
  END  

--

For igt@gem_ctx_param@invalid-param-set

 DEBUG 
(gem_ctx_param:8296) CRITICAL: Test assertion failure function __real_main31,
file gem_ctx_param.c:152:
(gem_ctx_param:8296) CRITICAL: Failed assertion: __gem_context_set_param(fd,
) == -22
(gem_ctx_param:8296) CRITICAL: error: 0 != -22
(gem_ctx_param:8296) igt-core-INFO: Stack trace:
(gem_ctx_param:8296) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(gem_ctx_param:8296) igt-core-INFO:   #1 [__real_main31+0x71e]
(gem_ctx_param:8296) igt-core-INFO:   #2 [+0x71e]
  END  

-- 
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: [AMDGPU][TAHITI XT] new display code

[sylvain . bertrand]

On Mon, Jan 29, 2018 at 01:04:08PM -0500, Alex Deucher wrote:
> On Mon, Jan 29, 2018 at 12:56 PM,   wrote:
> > Hi,
> >
> > I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new
> > display code is not available for gcn1 hardware?
> 
> No one has written the code.

I don't understand. Isn't the code for DCE programing pretty similar across all
generations due to the atombios?

I guess I miss something.

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

Re: [PATCH v3 06/12] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

[Rob Herring]

On Wed, Jan 17, 2018 at 09:14:15PM +0100, Jernej Skrabec wrote:
> This commit adds all necessary compatibles and descriptions needed to
> implement A83T HDMI pipeline.
> 
> Mixer is already properly described, so only compatible is added.
> 
> However, A83T TV TCON, which is connected to HDMI, doesn't have channel 0,
> contrary to all TCONs currently described. Because of that, TCON
> documentation is extended.
> 
> A83T features Synopsys DW HDMI controller with a custom PHY which looks
> like Synopsys Gen2 PHY with few additions. Since there is no
> documentation, needed properties were found out through experimentation
> and reading BSP code.
> 
> At the end, example is added for newer SoCs, which feature DE2 and DW
> HDMI.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt   | 197 
> -
>  1 file changed, 190 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index cd626ee1147a..4fb380f3e53d 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -64,6 +64,52 @@ Required properties:
>  first port should be the input endpoint. The second should be the
>  output, usually to an HDMI connector.
>  
> +DWC HDMI TX Encoder
> +---
> +
> +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> +
> +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> +following device-specific properties.
> +
> +Required properties:
> +
> +  - compatible: value must be one of:
> +* "allwinner,sun8i-a83t-dw-hdmi"
> +  - reg: base address and size of memory-mapped region
> +  - reg-io-width: See dw_hdmi.txt. Shall be 1.
> +  - interrupts: HDMI interrupt number
> +  - clocks: phandles to the clocks feeding the HDMI encoder
> +* iahb: the HDMI bus clock
> +* isfr: the HDMI register clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandle to the reset controller
> +  - reset-names: must be "ctrl"
> +  - phys: phandle to the DWC HDMI PHY
> +  - phy-names: must be "phy"
> +
> +  - ports: A ports node with endpoint definitions as defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +first port should be the input endpoint. The second should be the
> +output, usually to an HDMI connector.
> +
> +DWC HDMI PHY
> +
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun8i-a83t-hdmi-phy
> +  - reg: base address and size of memory-mapped region
> +  - clocks: phandles to the clocks feeding the HDMI PHY
> +* bus: the HDMI PHY interface clock
> +* mod: the HDMI PHY module clock
> +* tmds: TMDS clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandle to the reset controller driving the PHY
> +  - reset-names: must be "phy"
> +
>  TV Encoder
>  --
>  
> @@ -94,24 +140,23 @@ Required properties:
> * allwinner,sun7i-a20-tcon
> * allwinner,sun8i-a33-tcon
> * allwinner,sun8i-a83t-tcon-lcd
> +   * allwinner,sun8i-a83t-tcon-tv
> * allwinner,sun8i-v3s-tcon
>   - reg: base address and size of memory-mapped region
>   - interrupts: interrupt associated to this IP
> - - clocks: phandles to the clocks feeding the TCON. Three are needed:
> + - clocks: phandles to the clocks feeding the TCON. One is needed:
> - 'ahb': the interface clocks
> -   - 'tcon-ch0': The clock driving the TCON channel 0

Well, it didn't look right before saying 3 are needed, but listing 2. 
However, you can't just change this as it affects all the other SoCs. 
This should probably be a separate patch.

>   - resets: phandles to the reset controllers driving the encoder
> - "lcd": the reset line for the TCON channel 0
>  
>   - clock-names: the clock names mentioned above
>   - reset-names: the reset names mentioned above
> - - clock-output-names: Name of the pixel clock created

Why is this removed?

>  
>  - ports: A ports node with endpoint definitions as defined in
>Documentation/devicetree/bindings/media/video-interfaces.txt. The
>first port should be the input endpoint, the second one the output
>  
> -  The output may have multiple endpoints. The TCON has two channels,
> +  The output may have multiple endpoints. TCON can have two channels,

Perhaps you should say "can have 1 or 2 channels".

>usually with the first channel being used for the panels interfaces
>(RGB, LVDS, etc.), and the second being used for the outputs that
>require another controller (TV Encoder, HDMI, etc.). The endpoints
> @@ -119,11 +164,16 @@ Required properties:
>channel the 

Re: [AMDGPU][TAHITI XT] new display code

[Alex Deucher]

On Mon, Jan 29, 2018 at 12:56 PM,   wrote:
> Hi,
>
> I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new
> display code is not available for gcn1 hardware?

No one has written the code.

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

[AMDGPU][TAHITI XT] new display code

[sylvain . bertrand]

Hi,

I'm an owner of tahiti xt gpu, and I wonder what are the reasons the new
display code is not available for gcn1 hardware?

regards,

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

[Bug 104834] does not boot opensuse on fujitsu-siemens platform on cpu t2400-t7200

[bugzilla-daemon]

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

Jani Nikula  changed:

   What|Removed |Added

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

--- Comment #1 from Jani Nikula  ---
Is this a regression? Did some earlier kernel work?

Please add drm.degug=14 module parameter and try to get dmesg out of the
system.

-- 
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] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Ville Syrjälä]

On Thu, Jan 25, 2018 at 10:12:52AM -0500, Harry Wentland wrote:
> On 2018-01-25 08:30 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > Naturally we can only do that if the index of those objects stays
> > below 32. Issue a warning whenever we exceed that limit, hopefully
> > prompting someone to fix the problem.
> > 
> > For connectors the issue is a bit more complicated as they can
> > be created/destroyed at runtime due to MST. So the problem is no
> > longer a purely theoretical programmer error. As the connector
> > indexes are allocated via ida, we can simply limit the maximum
> > value the ida is allowed to hand out. The error handling is already
> > in place.
> > 
> > v2: Return an error to the caller (Harry)
> > v3: Print a debug message so that we know what happened (Maarten)
> > 
> > Cc: Harry Wentland 
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Vetter 
> > Reviewed-by: Maarten Lankhorst 
> 
> Reviewed-by: Harry Wentland 

Thanks for the review. Pushed to drm-misc-next.

> 
> Harry
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 9 +++--
> >  drivers/gpu/drm/drm_crtc.c  | 4 
> >  drivers/gpu/drm/drm_encoder.c   | 4 
> >  drivers/gpu/drm/drm_plane.c | 4 
> >  4 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index b85a7749709d..16b9c3810af2 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -205,9 +205,14 @@ int drm_connector_init(struct drm_device *dev,
> > connector->dev = dev;
> > connector->funcs = funcs;
> >  
> > -   ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
> > -   if (ret < 0)
> > +   /* connector index is used with 32bit bitmasks */
> > +   ret = ida_simple_get(>connector_ida, 0, 32, GFP_KERNEL);
> > +   if (ret < 0) {
> > +   DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
> > + drm_connector_enum_list[connector_type].name,
> > + ret);
> > goto out_put;
> > +   }
> > connector->index = ret;
> > ret = 0;
> >  
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f0556e654116..5b4be382a1d7 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> > struct drm_crtc *crtc,
> > WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> > WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
> >  
> > +   /* crtc index is used with 32bit bitmasks */
> > +   if (WARN_ON(config->num_crtc >= 32))
> > +   return -EINVAL;
> > +
> > crtc->dev = dev;
> > crtc->funcs = funcs;
> >  
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 59e0ebe733f8..273e1c59c54a 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> >  {
> > int ret;
> >  
> > +   /* encoder index is used with 32bit bitmasks */
> > +   if (WARN_ON(dev->mode_config.num_encoder >= 32))
> > +   return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_ENCODER);
> > if (ret)
> > return ret;
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 2c90519576a3..22b54663b6e7 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev, 
> > struct drm_plane *plane,
> > unsigned int format_modifier_count = 0;
> > int ret;
> >  
> > +   /* plane index is used with 32bit bitmasks */
> > +   if (WARN_ON(config->num_total_plane >= 32))
> > +   return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_PLANE);
> > if (ret)
> > return ret;
> > 

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

Re: [PATCH 7/7] dt-bindings: display: msm/dsi: Add updates for SDM845

[Rob Herring]

On Wed, Jan 17, 2018 at 03:04:48PM +0530, Archit Taneja wrote:
> SDM845 uses a newer revision (v2.0+) of the 6G DSI controller. This
> revision has another clock input at the block boundary called the byte
> interface clock. Specify this new clock in the binding.
> 
> A 10nm DSI PHY is used along with the controller. Add a compatible
> string for it and specify its base address/regulator supply needs.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

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

Re: [PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

[Rob Herring]

On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wrote:
> Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096).
> From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required,
> but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names
> each PHY revision needs.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index 9c3ad6bbb9f0..26a1796b7145 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -86,12 +86,19 @@ Required properties:
>* "qcom,dsi-phy-28nm-lp"
>* "qcom,dsi-phy-20nm"
>* "qcom,dsi-phy-28nm-8960"
> -- reg: Physical base address and length of the registers of PLL, PHY and PHY
> -  regulator
> +  * "qcom,dsi-phy-14nm"
> +- reg: Physical base address and length of the registers of PLL, PHY. Some
> +  revisions require the PHY regulator base address, whereas others require 
> the
> +  PHY lane base address. See below for each PHY revision.
>  - reg-names: The names of register regions. The following regions are 
> required:
> +  For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
>* "dsi_pll"
>* "dsi_phy"
>* "dsi_phy_regulator"
> +  For DSI 14nm PHY:
> +  * "dsi_pll"
> +  * "dsi_phy"
> +  * "dsi_phy_lane"
>  - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, 
> creating
>2 clocks: A byte clock (index 0), and a pixel clock (index 1).
>  - power-domains: Should be < MDSS_GDSC>.
> @@ -102,6 +109,8 @@ Required properties:
>  - vddio-supply: phandle to vdd-io regulator device node
>For 20nm PHY:
>  - vddio-supply: phandle to vdd-io regulator device node
> +- vcca-supply: phandle to vcca regulator device node

Did you mean to add this?

> +  For 14nm PHY:
>  - vcca-supply: phandle to vcca regulator device node
>  
>  Optional properties:
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the 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

Re: [PATCH 5/7] dt-bindings: display: msm/dsi: Fix the PHY regulator supply props

[Rob Herring]

On Wed, Jan 17, 2018 at 03:04:46PM +0530, Archit Taneja wrote:
> The PHY regulator supply names vary across different PHY versions.
> Mention explicitly which PHYs require which supplies.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
>  1 file changed, 4 insertions(+)

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

Re: [PATCH 4/7] dt-bindings: display: msm/dsi: Remove unused properties

[Rob Herring]

On Wed, Jan 17, 2018 at 03:04:45PM +0530, Archit Taneja wrote:
> "qcom,dsi-host-index" and "qcom,dsi-phy-index" DT props aren't
> acceptable and have never been used in any DT files. Remove them.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
>  1 file changed, 4 deletions(-)

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

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

[Boris Brezillon]

Hi Tomi,

On Mon, 29 Jan 2018 16:29:21 +0200
Tomi Valkeinen  wrote:

> On 18/01/18 15:43, Boris Brezillon wrote:
> > Add a driver for Cadence DPI -> DSI bridge.
> > 
> > This driver only support a subset of Cadence DSI bridge capabilities.
> > 
> > Here is a non-exhaustive list of missing features:
> >  * burst mode
> >  * DPHY init/configuration steps
> >  * support for additional input interfaces (SDI input)  
> 
> I think it would be good to have a list of features that are supported
> and tested, and perhaps a word about the development setup you have.
> 
> One thing that slightly worries me are the DPHY and input pixel clock
> rates. Now the code expects that those values match perfectly, which is
> not the case in real life. So what's the accepted difference, and is
> there something in the registers to program differently depending on the
> diff?

Just had a quick chat with Simon, and it seems some of the bits I was
setting were already activating the HSYNC/VSYNC recovery mechanism:

* VID_IGNORE_MISS_VSYNC: recover the case where pixel clock runs slower
  than TX byte clk
* the engine already handles the other case (pixel clock runs faster
  than TX byte clk) automatically (or maybe this is configured with the
  RECOVERY_MODE() field, I'm not sure)

Simon, don't hesitate to provide more information or correct me if I'm
wrong.

Note that the TX byte clk should be configured to match the DPI pixel
clock, which means we should refuse any config where the variation is
too big to be recovered. Anyway, we still don't have a way to configure
the PLL rate (which is driving the TX byte clk), so there's not much I
can do about that right now.

> 
> Another thing is that the mode->crtc_clock is in kHz, I wonder if that
> rounding can cause miscalculations in the above code.

Do we really have modes exposing pixel clks not aligned on a Khz? I
know the display controller can adjust the timings, but then, the
variation caused by the Khz approx should not be that big (999Khz /
10+MHz < 1/1), and anyway, that's what the DRM framework
manipulates...

Regards,

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

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[Michal Hocko]

On Mon 29-01-18 16:29:42, Roger He wrote:
> ttm module needs it to determine its internal parameter setting.

Could you be more specific why?

> Signed-off-by: Roger He 
> ---
>  include/linux/swap.h |  6 ++
>  mm/swapfile.c| 15 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index c2b8128..708d66f 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
>  struct backing_dev_info;
>  extern int init_swap_address_space(unsigned int type, unsigned long 
> nr_pages);
>  extern void exit_swap_address_space(unsigned int type);
> +extern long get_total_swap_pages(void);
>  
>  #else /* CONFIG_SWAP */
>  
> @@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)
>  {
>  }
>  
> +long get_total_swap_pages(void)
> +{
> + return 0;
> +}
> +
>  #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
> is_device_private_entry(e));})
>  #define swapcache_prepare(e) ({(is_migration_entry(e) || 
> is_device_private_entry(e));})
>  
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 3074b02..a0062eb 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
>  
>  atomic_t nr_rotate_swap = ATOMIC_INIT(0);
>  
> +/*
> + * expose this value for others use
> + */
> +long get_total_swap_pages(void)
> +{
> + long ret;
> +
> + spin_lock(_lock);
> + ret = total_swap_pages;
> + spin_unlock(_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(get_total_swap_pages);
> +
>  static inline unsigned char swap_count(unsigned char ent)
>  {
>   return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */
> -- 
> 2.7.4

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

[Bug 104611] [fiji, polaris10] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

--- Comment #7 from Harry Wentland  ---
Did you have a chance to capture a repro dmesg with 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

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

[bugzilla-daemon]

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

--- Comment #5 from Harry Wentland  ---
Can you try with the latest amd-staging-drm-next from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

We just fixed a bunch of driver unload issues. It should be fixed now.

-- 
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 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

[bugzilla-daemon]

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

--- Comment #1 from Harry Wentland  ---
This patch https://patchwork.freedesktop.org/patch/198719/ should fix it, but
there could be some other issues as well.

amd-staging-drm-next has fixes for a whole bunch of driver unload issues,
including what you're seeing. It's hosted at
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

Can you try the patch and/or amd-staging-drm-next?

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

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Leo Li]

Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html

Would someone be able to apply this patch?

Thanks,
Leo

On 2018-01-17 03:18 PM, Sean Paul wrote:

On Wed, Jan 17, 2018 at 10:39 AM, Maarten Lankhorst
 wrote:

Op 17-01-18 om 19:29 schreef Sean Paul:

On Wed, Jan 17, 2018 at 12:51:08PM +0100, Maarten Lankhorst wrote:

From: "Leo (Sunpeng) Li" 

During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).

Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.

Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.

Changes since v1:
- Also check for state->event->base.completion being set, to
   handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
   i915 may unreference the state in a worker.

Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc:  # v4.11+
Signed-off-by: Leo (Sunpeng) Li 
Acked-by: Harry Wentland  #v1
Signed-off-by: Maarten Lankhorst 
---
  drivers/gpu/drm/drm_atomic_helper.c | 15 +++
  include/drm/drm_atomic.h|  9 +
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..ae3cbfe9e01c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1878,6 +1878,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,
  new_crtc_state->event->base.completion = >flip_done;
  new_crtc_state->event->base.completion_release = 
release_crtc_commit;
  drm_crtc_commit_get(commit);
+
+commit->abort_completion = true;
  }

  for_each_oldnew_connector_in_state(state, conn, old_conn_state, 
new_conn_state, i) {
@@ -3421,8 +3423,21 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
  void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
  {
  if (state->commit) {
+/*
+ * In the event that a non-blocking commit returns
+ * -ERESTARTSYS before the commit_tail work is queued, we will
+ * have an extra reference to the commit object. Release it, if
+ * the event has not been consumed by the worker.
+ *
+ * state->event may be freed, so we can't directly look at
+ * state->event->base.completion.
+ */
+if (state->event && state->commit->abort_completion)
+drm_crtc_commit_put(state->commit);
+
  kfree(state->commit->event);
  state->commit->event = NULL;
+
  drm_crtc_commit_put(state->commit);
  }

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1c27526c499e..cf13842a6dbd 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -134,6 +134,15 @@ struct drm_crtc_commit {
   * _pending_vblank_event pointer to clean up private events.
   */
  struct drm_pending_vblank_event *event;
+
+/**
+ * @abort_completion:
+ *
+ * A flag that's set after drm_atomic_helper_setup_commit takes a second
+ * reference for the completion of $drm_crtc_state.event. It's used by
+ * the free code to remove the second reference if commit fails.
+ */

Perhaps it's just me, or I'm oversimplifying the problem. I think this would
be easier to understand if we just dropped the additional reference at the point
of failure (ie: in swap_state). That way we don't have to add Yet Another Piece
Of State.


That's assuming nothing can fail between setup_commit() and swap_state() and
also that the driver implementing atomci puts no calls in between. And also
assumes that even setup_commit has proper rollback. I think it's overkill,
and we have no choice but to do it like this. :(



yeah, fair enough.

Reviewed-by: Sean Paul 


~Maarten


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

[PATCH] dma-fence: add comment for WARN_ON in dma_fence_release()

[Oded Gabbay]

In dma_fence_release() there is a WARN_ON which could be triggered by
several cases of wrong dma-fence usage. This patch adds a comment to
explain two use-cases to help driver developers that use dma-fence
and trigger that WARN_ON to better understand the reasons for it.

Signed-off-by: Oded Gabbay 
---
 drivers/dma-buf/dma-fence.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 5d101c4053e0..a7170ab23ec0 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -171,6 +171,39 @@ void dma_fence_release(struct kref *kref)
 
trace_dma_fence_destroy(fence);
 
+   /*
+* If the WARN_ON below is triggered it could be because the dma fence
+* was not signaled and therefore, the cb list is still not empty
+* because the cb functions were not called.
+*
+* A more subtle case is where the fence got signaled by a thread that
+* didn't hold a ref to the fence. The following describes the scenario:
+*
+*  Thread AThread B
+*----
+* calls dma_fence_signal() {
+*  set signal bit
+*
+*scheduled out
+*  ---> calls dma_fence_wait_timeout() and
+*   returns immediately
+*
+*   calls dma_fence_put()
+* |
+* |thread A doesn't hold ref
+* |to fence so ref goes to 0
+* |and release is called
+* |
+* -> dma_fence_release()
+*|
+*-> WARN_ON triggered
+*
+*  go over CB list,
+*  call each CB and remove it
+*  }
+*
+*
+*/
WARN_ON(!list_empty(>cb_list));
 
if (fence->ops->release)
-- 
2.14.3

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

Re: [PATCH libdrm] tests/amdgpu: add missing config.h include

[Eric Engestrom]

On Monday, 2018-01-29 14:56:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Otherwise we'll end up without the macros set during configure stage.
> And effectively error out in sanity tests such as the mmap static
> assert.
> 
> To reproduce, do a multilib build - 32bit build on 64bit machine.
> 
> Cc: Fabio Pedretti 
> Cc: Andrey Grodzovsky 
> Fixes: 33dcc29f7cc ("amdgpu: Add VMID reservation per GPU context test.")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104819
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

And my apologies for being a bit too trigger-happy when blaming
autotools :(

> ---
>  tests/amdgpu/vm_tests.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tests/amdgpu/vm_tests.c b/tests/amdgpu/vm_tests.c
> index 4b0121ff..0379a79d 100644
> --- a/tests/amdgpu/vm_tests.c
> +++ b/tests/amdgpu/vm_tests.c
> @@ -21,6 +21,10 @@
>   *
>  */
>  
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>  #include "CUnit/Basic.h"
>  
>  #include "amdgpu_test.h"
> -- 
> 2.16.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104281] black / corrupted screen when resuming from S3 [AMDGPU]

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
The commit that broke it was:

commit ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 (refs/bisect/bad)
Author: Andy Lutomirski 
Date:   Wed Nov 22 20:39:16 2017 -0800

x86/entry/64: Add missing irqflags tracing to native_load_gs_index()

I'm not sure what commit fixed it.

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

[PATCH libdrm] tests/amdgpu: add missing config.h include

[Emil Velikov]

From: Emil Velikov 

Otherwise we'll end up without the macros set during configure stage.
And effectively error out in sanity tests such as the mmap static
assert.

To reproduce, do a multilib build - 32bit build on 64bit machine.

Cc: Fabio Pedretti 
Cc: Andrey Grodzovsky 
Fixes: 33dcc29f7cc ("amdgpu: Add VMID reservation per GPU context test.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104819
Signed-off-by: Emil Velikov 
---
 tests/amdgpu/vm_tests.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/amdgpu/vm_tests.c b/tests/amdgpu/vm_tests.c
index 4b0121ff..0379a79d 100644
--- a/tests/amdgpu/vm_tests.c
+++ b/tests/amdgpu/vm_tests.c
@@ -21,6 +21,10 @@
  *
 */
 
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include "CUnit/Basic.h"
 
 #include "amdgpu_test.h"
-- 
2.16.0

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

[Bug 104819] [libdrm build failure on 32 bit Ubuntu 16.04] libdrm_macros.h:79:4: error: size of unnamed array is negative

[bugzilla-daemon]

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

--- Comment #4 from Emil Velikov  ---
(In reply to Eric Engestrom from comment #3)
> I think you might be hitting a bug combining C++ compilers trying to compile
> C and autotools not being smart enough.
> What happens if you try to build using Meson?
> 
> (If you've never used Meson before, Mesa has a good page describing how to
> use it: https://mesa3d.org/meson.html)

That's a lot of bull and you know it ;-) This is pre-processor stuff, where
autotools or any build system doesn't care.

Issue is a missing config.h include in the C file. I'll send a patch in a
moment.

-- 
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 104819] [libdrm build failure on 32 bit Ubuntu 16.04] libdrm_macros.h:79:4: error: size of unnamed array is negative

[bugzilla-daemon]

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

--- Comment #3 from Eric Engestrom  ---
I think you might be hitting a bug combining C++ compilers trying to compile C
and autotools not being smart enough.
What happens if you try to build using Meson?

(If you've never used Meson before, Mesa has a good page describing how to use
it: https://mesa3d.org/meson.html)

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

Re: [PATCH v19 03/10] video: backlight: Add of_find_backlight helper in backlight.c

[Sean Paul]

On Mon, Jan 29, 2018 at 4:11 AM, Lee Jones  wrote:
> On Fri, 26 Jan 2018, Randy Dunlap wrote:
>
>> On 01/26/2018 01:48 AM, Lee Jones wrote:
>> > On Wed, 24 Jan 2018, Meghana Madhyastha wrote:
>> >
>> >> Add of_find_backlight, a helper function which is a generic version
>> >> of tinydrm_of_find_backlight that can be used by other drivers to avoid
>> >> repetition of code and simplify things.
>> >>
>> >> Acked-by: Daniel Thompson 
>> >> Reviewed-by: Noralf Trønnes 
>> >> Reviewed-by: Sean Paul
>> >> Signed-off-by: Meghana Madhyastha 
>> >
>> > Nit: These should be in chronological order.
>>
>> Where does that tidbit of information come from?
>> I have never heard or read that.
>
> Not sure it is documented anywhere.  It appeared to be the widely
> used, most sensible approach, so I adopted it a few years ago.
>
> This method provides us with information which would otherwise be
> absent; including description of the patch submission/acceptance path
> and an idea of who did what, when.
>
> For example:
>
> Original Author sign-off
> Original Co-author sign-off
> [Additional contributions: rebase, API changes, fix-ups]
> Re-worker's sign-off
> Tester's tested-by
> Reviewer's acked-by/reviewed-by
> Level-2 Maintainer sign-off
> Level-1 Maintainer sign-off
>
> Are you aware of a more functional/practical/useful method?


Hi Lee,
Our tooling adds a Link: tag to the commit message pointing back to
mailing list archives. This provides more detailed patch provenance in
addition to reducing the burden on contributors to order tags
correctly (I had never heard of this as a requirement either). Check
out [1]  if you're interested.

Sean

[1]- https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html

>
> --
> Lee Jones
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104837] 'radeonsi: Failed to create context' with 32 bit applications

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Version|XOrg git|unspecified
Product|DRI |Mesa
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact||mesa-dev@lists.freedesktop.
   ||org
  Component|DRM/AMDgpu  |GLX

--- Comment #1 from Michel Dänzer  ---
This is a Mesa or xserver (or maybe GLVND?) issue, the dmesg messages are
unrelated and harmless.

Please attach the glxinfo output and the Xorg log file.

Did it work with an older version of Mesa / xserver / GLVND?

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

Re: [PATCH 01/12] drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap() (v2)

[Christian König]

Am 29.01.2018 um 15:31 schrieb Michel Dänzer:

On 2018-01-29 02:55 PM, Tom St Denis wrote:

The buf pointer was not being incremented inside the loop
meaning the same block of data would be read or written
repeatedly.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 

Please add:

Cc: sta...@vger.kernel.org
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")


What Michel meant here is that you should add the "Cc: " and "Fixes: " 
tags to the commit message and NOT send it manually to 
sta...@vger.kernel.org.


The "Cc:" tag results in automatically backporting of the patch to 
stable kernels. Manually sending a patch to sta...@vger.kernel.org is 
only necessary when the automated backport doesn't work.


Christian.



so that it'll get backported to the relevant stable branches.




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

Re: [PATCH 01/12] drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap() (v2)

[Michel Dänzer]

On 2018-01-29 02:55 PM, Tom St Denis wrote:
> The buf pointer was not being incremented inside the loop
> meaning the same block of data would be read or written
> repeatedly.
> 
> Signed-off-by: Tom St Denis 
> Reviewed-by: Christian König 

Please add:

Cc: sta...@vger.kernel.org
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")

so that it'll get backported to the relevant stable branches.


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

[Bug 104819] [libdrm build failure on 32 bit Ubuntu 16.04] libdrm_macros.h:79:4: error: size of unnamed array is negative

[bugzilla-daemon]

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

--- Comment #2 from Fabio Pedretti  ---
Note I am compiling the drm source from git. The same source builds fine on
newer Ubuntu. Maybe it's something broken/old in the ubuntu 16.04 toolchain?

-- 
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 v5 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]

On 18/01/18 15:43, Boris Brezillon wrote:
> Add a driver for Cadence DPI -> DSI bridge.
> 
> This driver only support a subset of Cadence DSI bridge capabilities.
> 
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * DPHY init/configuration steps
>  * support for additional input interfaces (SDI input)

I think it would be good to have a list of features that are supported
and tested, and perhaps a word about the development setup you have.

One thing that slightly worries me are the DPHY and input pixel clock
rates. Now the code expects that those values match perfectly, which is
not the case in real life. So what's the accepted difference, and is
there something in the registers to program differently depending on the
diff?

Another thing is that the mode->crtc_clock is in kHz, I wonder if that
rounding can cause miscalculations in the above code.

 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 v5 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

On Mon, 29 Jan 2018 15:59:33 +0200
Tomi Valkeinen  wrote:

> On 29/01/18 15:14, Boris Brezillon wrote:
> 
> >> You don't disable the dsi_sys_clk neither in the ok nor in the error 
> >> paths.  
> > 
> > Hm, it shouldn't be enabled in the first place: the runtime resume
> > hook takes care of enabling it, and we don't need this clock to access
> > IP registers (which is all we do in the probe).  
> 
> Ah, right, you can just use pm_runtime directly to enable the IP.
> 
> I was looking at the docs, but it wasn't quite clear to me when exactly
> dsi_sys_clk is needed. I take it that you can access registers with just
> the dsi_p_clk, but you can't really do anything with the IP without
> dsi_sys_clk? If so, I think enabling both dsi_p_clk and dsi_sys_clk in
> the runtime PM callbacks is ok.

That's my understanding.

> 
> Alternatively, if dsi_sys_clk is only needed for some specific
> functionality, a more correct way would be to enable that clock only
> when that operation is performed.

IIUC, it's needed to clock the PPI domain, so any operation
transmitting things on the DSI bus requires the sys clock.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104837] 'radeonsi: Failed to create context' with 32 bit applications

[bugzilla-daemon]

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

Bug ID: 104837
   Summary: 'radeonsi: Failed to create context' with 32 bit
applications
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: rafael.ristov...@gmail.com

Created attachment 137021
  --> https://bugs.freedesktop.org/attachment.cgi?id=137021=edit
dmesg log

Running 32bit OpenGL applications on my AMD card with DRI_PRIME=1 produces the
following error, running 64bit applications works just fine.
Somehow I suspect virtual memory is the cause.

libGL: pci id for fd 5: 1002:6823, driver radeonsi
libGL: OpenDriver: trying /usr/lib32/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib32/dri/radeonsi_dri.so
/usr/share/libdrm/amdgpu.ids version: 1.0.0
radeonsi: Failed to create a context.
libGL: Using DRI3 for screen 0
radeonsi: Failed to create a context.
X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  31
  Current serial number in output stream:  33

At the same time, the following messages are logged in dmesg:
(See similar but apparently harmless:
https://bugs.freedesktop.org/show_bug.cgi?id=104082)

[433611.485600] amdgpu :03:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[433611.485602] amdgpu :03:00.0: swiotlb: coherent allocation failed,
size=2097152

Full relevant dmesg log of the accident is attached

Various VRAM/GTT info from boot:

[   10.485945] [drm] amdgpu kernel modesetting enabled.
[   10.486189] amdgpu :03:00.0: enabling device ( -> 0003)
[   10.669296] amdgpu :03:00.0: VRAM: 2048M 0x00F4 -
0x00F47FFF (2048M used)
[   10.669298] amdgpu :03:00.0: GTT: 1024M 0x -
0x3FFF
[   10.669387] [drm] amdgpu: 2048M of VRAM memory ready
[   10.669388] [drm] amdgpu: 3072M of GTT memory ready.
[   10.670190] amdgpu :03:00.0: PCIE GART of 1024M enabled (table at
0x00F40004).
[   10.685934] [drm] amdgpu: dpm initialized
[   11.043323] [drm] Initialized amdgpu 3.23.0 20150101 for :03:00.0 on
minor 1

Sysinfo:

- Gentoo x86_64
- llvm/clang/mesa/libdrm and friends, including drivers all pulled from git as
of ~2 days ago.

- Intel HD 4400 Gen7.5 Haswell - i915
- AMD Radeon HD 8850M - amdgpu
- Both drivers are using DRI3 for PRIME

-- 
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 v5 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]

On 29/01/18 15:14, Boris Brezillon wrote:

>> You don't disable the dsi_sys_clk neither in the ok nor in the error paths.
> 
> Hm, it shouldn't be enabled in the first place: the runtime resume
> hook takes care of enabling it, and we don't need this clock to access
> IP registers (which is all we do in the probe).

Ah, right, you can just use pm_runtime directly to enable the IP.

I was looking at the docs, but it wasn't quite clear to me when exactly
dsi_sys_clk is needed. I take it that you can access registers with just
the dsi_p_clk, but you can't really do anything with the IP without
dsi_sys_clk? If so, I think enabling both dsi_p_clk and dsi_sys_clk in
the runtime PM callbacks is ok.

Alternatively, if dsi_sys_clk is only needed for some specific
functionality, a more correct way would be to enable that clock only
when that operation is performed.

 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

[PATCH 08/12] drm/ttm: Remove unncessary retval from ttm_bo_vm_fault()

[Tom St Denis]

The dual ret/retval was more complex than need be.  Now
we drop the retval variable and assign the appropriate VM
codes to ret instead.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 60fcef1593dd..716e724ac710 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -118,7 +118,6 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
int ret;
int i;
unsigned long address = vmf->address;
-   int retval = VM_FAULT_NOPAGE;
struct ttm_mem_type_manager *man =
>man[bo->mem.mem_type];
struct vm_area_struct cvma;
@@ -158,7 +157,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
 * (if at all) by redirecting mmap to the exporter.
 */
if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
-   retval = VM_FAULT_SIGBUS;
+   ret = VM_FAULT_SIGBUS;
goto out_unlock;
}
 
@@ -169,10 +168,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
break;
case -EBUSY:
case -ERESTARTSYS:
-   retval = VM_FAULT_NOPAGE;
+   ret = VM_FAULT_NOPAGE;
goto out_unlock;
default:
-   retval = VM_FAULT_SIGBUS;
+   ret = VM_FAULT_SIGBUS;
goto out_unlock;
}
}
@@ -183,12 +182,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
 */
ret = ttm_bo_vm_fault_idle(bo, vmf);
if (unlikely(ret != 0)) {
-   retval = ret;
-
-   if (retval == VM_FAULT_RETRY &&
+   if (ret == VM_FAULT_RETRY &&
!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
/* The BO has already been unreserved. */
-   return retval;
+   return ret;
}
 
goto out_unlock;
@@ -196,12 +193,12 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
 
ret = ttm_mem_io_lock(man, true);
if (unlikely(ret != 0)) {
-   retval = VM_FAULT_NOPAGE;
+   ret = VM_FAULT_NOPAGE;
goto out_unlock;
}
ret = ttm_mem_io_reserve_vm(bo);
if (unlikely(ret != 0)) {
-   retval = VM_FAULT_SIGBUS;
+   ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
 
@@ -211,7 +208,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
drm_vma_node_start(>vma_node);
 
if (unlikely(page_offset >= bo->num_pages)) {
-   retval = VM_FAULT_SIGBUS;
+   ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
 
@@ -238,7 +235,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
 
/* Allocate all page at once, most common usage */
if (ttm->bdev->driver->ttm_tt_populate(ttm, )) {
-   retval = VM_FAULT_OOM;
+   ret = VM_FAULT_OOM;
goto out_io_unlock;
}
}
@@ -255,7 +252,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {
-   retval = VM_FAULT_OOM;
+   ret = VM_FAULT_OOM;
goto out_io_unlock;
} else if (unlikely(!page)) {
break;
@@ -280,7 +277,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
break;
else if (unlikely(ret != 0)) {
-   retval =
+   ret =
(ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
goto out_io_unlock;
}
@@ -289,11 +286,12 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (unlikely(++page_offset >= page_last))
break;
}
+   ret = VM_FAULT_NOPAGE;
 out_io_unlock:
ttm_mem_io_unlock(man);
 out_unlock:
ttm_bo_unreserve(bo);
-   return retval;
+   return ret;
 }
 
 static void ttm_bo_vm_open(struct vm_area_struct *vma)
-- 
2.14.3

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

[PATCH 11/12] drm/ttm: Fix coding style in ttm_dma_pool_alloc_new_pages()

[Tom St Denis]

Add missing {} braces.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 469e68e06be6..fcd16804c738 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -763,10 +763,9 @@ static int ttm_dma_pool_alloc_new_pages(struct dma_pool 
*pool,
return -ENOMEM;
}
 
-   if (count > 1) {
+   if (count > 1)
pr_debug("%s: (%s:%d) Getting %d pages\n",
 pool->dev_name, pool->name, current->pid, count);
-   }
 
for (i = 0, cpages = 0; i < count; ++i) {
dma_p = __ttm_dma_alloc_page(pool);
-- 
2.14.3

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

[PATCH 07/12] drm/ttm: Fix coding style in ttm_bo_move_memcpy()

[Tom St Denis]

Add missing {} braces.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 153de1bf0232..33ffe286f3a5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -402,8 +402,9 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
PAGE_KERNEL);
ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
   prot);
-   } else
+   } else {
ret = ttm_copy_io_page(new_iomap, old_iomap, page);
+   }
if (ret)
goto out1;
}
-- 
2.14.3

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

[PATCH 10/12] drm/ttm: Fix coding style in ttm_tt_swapout()

[Tom St Denis]

Add missing {} braces.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e90d3ed6283f..95a77dab8cc9 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -352,8 +352,9 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
pr_err("Failed allocating swap storage\n");
return PTR_ERR(swap_storage);
}
-   } else
+   } else {
swap_storage = persistent_swap_storage;
+   }
 
swap_space = swap_storage->f_mapping;
 
-- 
2.14.3

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

[PATCH 12/12] drm/ttm: Simplify ttm_dma_page_put()

[Tom St Denis]

Remove redundant store of return code.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index fcd16804c738..b122f6eee94c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -390,14 +390,12 @@ static void ttm_dma_page_put(struct dma_pool *pool, 
struct dma_page *d_page)
 {
struct page *page = d_page->p;
unsigned i, num_pages;
-   int ret;
 
/* Don't set WB on WB page pool. */
if (!(pool->type & IS_CACHED)) {
num_pages = pool->size / PAGE_SIZE;
for (i = 0; i < num_pages; ++i, ++page) {
-   ret = set_pages_array_wb(, 1);
-   if (ret) {
+   if (set_pages_array_wb(, 1)) {
pr_err("%s: Failed to set %d pages to wb!\n",
   pool->dev_name, 1);
}
-- 
2.14.3

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

[PATCH 05/12] drm/ttm: Fix coding style in ttm_pool_store()

[Tom St Denis]

Correct missing {} style.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 9e90d0ebc773..647eb5f40ab9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -210,6 +210,7 @@ static ssize_t ttm_pool_store(struct kobject *kobj, struct 
attribute *attr,
container_of(kobj, struct ttm_pool_manager, kobj);
int chars;
unsigned val;
+
chars = sscanf(buffer, "%u", );
if (chars == 0)
return size;
@@ -217,11 +218,11 @@ static ssize_t ttm_pool_store(struct kobject *kobj, 
struct attribute *attr,
/* Convert kb to number of pages */
val = val / (PAGE_SIZE >> 10);
 
-   if (attr == _page_pool_max)
+   if (attr == _page_pool_max) {
m->options.max_size = val;
-   else if (attr == _page_pool_small)
+   } else if (attr == _page_pool_small) {
m->options.small = val;
-   else if (attr == _page_pool_alloc_size) {
+   } else if (attr == _page_pool_alloc_size) {
if (val > NUM_PAGES_TO_ALLOC*8) {
pr_err("Setting allocation size to %lu is not allowed. 
Recommended size is %lu\n",
   NUM_PAGES_TO_ALLOC*(PAGE_SIZE >> 7),
-- 
2.14.3

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

[PATCH 09/12] drm/ttm: Simplify ttm_eu_reserve_buffers()

[Tom St Denis]

Hoist the comparison of the ret to -EDEADLK above
the two code paths to simplify the function.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 373ced0b2fc2..fa44f7b15285 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -139,12 +139,14 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
 */
ttm_eu_backoff_reservation_reverse(list, entry);
 
-   if (ret == -EDEADLK && intr) {
-   ret = ww_mutex_lock_slow_interruptible(>resv->lock,
-  ticket);
-   } else if (ret == -EDEADLK) {
-   ww_mutex_lock_slow(>resv->lock, ticket);
-   ret = 0;
+   if (ret == -EDEADLK) {
+   if (intr) {
+   ret = 
ww_mutex_lock_slow_interruptible(>resv->lock,
+  ticket);
+   } else {
+   ww_mutex_lock_slow(>resv->lock, ticket);
+   ret = 0;
+   }
}
 
if (!ret && entry->shared)
-- 
2.14.3

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

[PATCH 06/12] drm/ttm: Simplify ttm_dma_find_pool() (v2)

[Tom St Denis]

Flip the logic of the comparison and remove
the redudant variable for the pool address.

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 

(v2): Remove {} bracing.
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 647eb5f40ab9..469e68e06be6 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -682,10 +682,10 @@ static struct dma_pool *ttm_dma_pool_init(struct device 
*dev, gfp_t flags,
 static struct dma_pool *ttm_dma_find_pool(struct device *dev,
  enum pool_type type)
 {
-   struct dma_pool *pool, *tmp, *found = NULL;
+   struct dma_pool *pool, *tmp;
 
if (type == IS_UNDEFINED)
-   return found;
+   return NULL;
 
/* NB: We iterate on the 'struct dev' which has no spinlock, but
 * it does have a kref which we have taken. The kref is taken during
@@ -698,13 +698,10 @@ static struct dma_pool *ttm_dma_find_pool(struct device 
*dev,
 * thing is at that point of time there are no pages associated with the
 * driver so this function will not be called.
 */
-   list_for_each_entry_safe(pool, tmp, >dma_pools, pools) {
-   if (pool->type != type)
-   continue;
-   found = pool;
-   break;
-   }
-   return found;
+   list_for_each_entry_safe(pool, tmp, >dma_pools, pools)
+   if (pool->type == type)
+   return pool;
+   return NULL;
 }
 
 /*
-- 
2.14.3

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

Various TTM cleanups (v2)

[Tom St Denis]

Various TTM cleanups (mostly no functional changes).

Notably patch #1 fixes a bug in the access_kmap() function.

The rest are either coding style fixes or simplifications.


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