Re: [PATCH RFC v2 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info

[Laurent Pinchart]

Hello,

On Wednesday, 19 December 2018 09:26:08 EET Andrzej Hajda wrote:
> On 30.11.2018 14:42, Neil Armstrong wrote:
> > From: Zheng Yang 
> > 
> > To get input/output bus_format/enc_format dynamically, this patch
> > 
> > introduce following funstion in plat_data:
> > - get_input_bus_format
> > - get_output_bus_format
> > - get_enc_in_encoding
> > - get_enc_out_encoding
> 
> It seems fishy. On one side description says about dynamic resolution of
> formats and encodings.
> 
> On the other side these functions as only argument takes platform_data
> which should be rather static.
> 
> Where is this "dynamic" thing? The only usage of these callbacks I have
> found in next patches is also not dynamic, the functions just return
> some static value.
> 
> Moreover function takes void* argument, which is again something
> suspicious, why cannot you pass know structure?
> 
> And finally encoding usually should depend on display mode, it should
> not depend only static data.
> 
> 
> What kind of problems do you want to solve here?

I would add that this doesn't seem to be specific to dw-hdmi in any way. I'd 
prefer an API at the drm_bridge level to handle this.

> > Signed-off-by: Zheng Yang 
> > Signed-off-by: Neil Armstrong 
> > ---
> > 
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 +--
> >  include/drm/bridge/dw_hdmi.h  |  5 
> >  2 files changed, 26 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 4a9a24e854db..bd564ffdf18b 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1810,6 +1810,7 @@ static void hdmi_disable_overflow_interrupts(struct
> > dw_hdmi *hdmi)> 
> >  static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode
> >  *mode) {
> >  
> > int ret;
> > 
> > +   void *data = hdmi->plat_data->phy_data;
> > 
> > hdmi_disable_overflow_interrupts(hdmi);
> > 
> > @@ -1821,10 +1822,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
> > struct drm_display_mode *mode)> 
> > dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
> > 
> > }
> > 
> > -   if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
> > -   (hdmi->vic == 21) || (hdmi->vic == 22) ||
> > -   (hdmi->vic == 2) || (hdmi->vic == 3) ||
> > -   (hdmi->vic == 17) || (hdmi->vic == 18))
> > +   if (hdmi->plat_data->get_enc_out_encoding)
> > +   hdmi->hdmi_data.enc_out_encoding =
> > +   hdmi->plat_data->get_enc_out_encoding(data);
> > +   else if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
> > +(hdmi->vic == 21) || (hdmi->vic == 22) ||
> > +(hdmi->vic == 2) || (hdmi->vic == 3) ||
> > +(hdmi->vic == 17) || (hdmi->vic == 18))
> > 
> > hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_601;
> > 
> > else
> > 
> > hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_709;
> > 
> > @@ -1833,21 +1837,31 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
> > struct drm_display_mode *mode)> 
> > hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
> > 
> > /* TOFIX: Get input format from plat data or fallback to RGB888 */
> > 
> > -   if (hdmi->plat_data->input_bus_format)
> > +   if (hdmi->plat_data->get_input_bus_format)
> > +   hdmi->hdmi_data.enc_in_bus_format =
> > +   hdmi->plat_data->get_input_bus_format(data);
> > +   else if (hdmi->plat_data->input_bus_format)
> > 
> > hdmi->hdmi_data.enc_in_bus_format =
> > 
> > hdmi->plat_data->input_bus_format;
> > 
> > else
> > 
> > hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > 
> > /* TOFIX: Get input encoding from plat data or fallback to none */
> > 
> > -   if (hdmi->plat_data->input_bus_encoding)
> > +   if (hdmi->plat_data->get_enc_in_encoding)
> > +   hdmi->hdmi_data.enc_in_encoding =
> > +   hdmi->plat_data->get_enc_in_encoding(data);
> > +   else if (hdmi->plat_data->input_bus_encoding)
> > 
> > hdmi->hdmi_data.enc_in_encoding =
> > 
> > hdmi->plat_data->input_bus_encoding;
> > 
> > else
> > 
> > hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT;
> > 
> > /* TOFIX: Default to RGB888 output format */
> > 
> > -   hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > +   if (hdmi->plat_data->get_output_bus_format)
> > +   hdmi->hdmi_data.enc_out_bus_format =
> > +   hdmi->plat_data->get_output_bus_format(data);
> > +   else
> > +   hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > 
> > hdmi->hdmi_data.pix_repet_factor = 0;
> > hdmi->hdmi_data.hdcp_enable = 0;
> > 
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h

Re: [PATCH RFC v2 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info

[Andrzej Hajda]

On 30.11.2018 14:42, Neil Armstrong wrote:
> From: Zheng Yang 
>
> To get input/output bus_format/enc_format dynamically, this patch
> introduce following funstion in plat_data:
>   - get_input_bus_format
>   - get_output_bus_format
>   - get_enc_in_encoding
>   - get_enc_out_encoding


It seems fishy. On one side description says about dynamic resolution of
formats and encodings.

On the other side these functions as only argument takes platform_data
which should be rather static.

Where is this "dynamic" thing? The only usage of these callbacks I have
found in next patches is also not dynamic, the functions just return
some static value.

Moreover function takes void* argument, which is again something
suspicious, why cannot you pass know structure?

And finally encoding usually should depend on display mode, it should
not depend only static data.


What kind of problems do you want to solve here?


Regards

Andrzej



>
> Signed-off-by: Zheng Yang 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 +--
>  include/drm/bridge/dw_hdmi.h  |  5 
>  2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 4a9a24e854db..bd564ffdf18b 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1810,6 +1810,7 @@ static void hdmi_disable_overflow_interrupts(struct 
> dw_hdmi *hdmi)
>  static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
>  {
>   int ret;
> + void *data = hdmi->plat_data->phy_data;
>  
>   hdmi_disable_overflow_interrupts(hdmi);
>  
> @@ -1821,10 +1822,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
>   }
>  
> - if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
> - (hdmi->vic == 21) || (hdmi->vic == 22) ||
> - (hdmi->vic == 2) || (hdmi->vic == 3) ||
> - (hdmi->vic == 17) || (hdmi->vic == 18))
> + if (hdmi->plat_data->get_enc_out_encoding)
> + hdmi->hdmi_data.enc_out_encoding =
> + hdmi->plat_data->get_enc_out_encoding(data);
> + else if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
> +  (hdmi->vic == 21) || (hdmi->vic == 22) ||
> +  (hdmi->vic == 2) || (hdmi->vic == 3) ||
> +  (hdmi->vic == 17) || (hdmi->vic == 18))
>   hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_601;
>   else
>   hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_709;
> @@ -1833,21 +1837,31 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
>  
>   /* TOFIX: Get input format from plat data or fallback to RGB888 */
> - if (hdmi->plat_data->input_bus_format)
> + if (hdmi->plat_data->get_input_bus_format)
> + hdmi->hdmi_data.enc_in_bus_format =
> + hdmi->plat_data->get_input_bus_format(data);
> + else if (hdmi->plat_data->input_bus_format)
>   hdmi->hdmi_data.enc_in_bus_format =
>   hdmi->plat_data->input_bus_format;
>   else
>   hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>  
>   /* TOFIX: Get input encoding from plat data or fallback to none */
> - if (hdmi->plat_data->input_bus_encoding)
> + if (hdmi->plat_data->get_enc_in_encoding)
> + hdmi->hdmi_data.enc_in_encoding =
> + hdmi->plat_data->get_enc_in_encoding(data);
> + else if (hdmi->plat_data->input_bus_encoding)
>   hdmi->hdmi_data.enc_in_encoding =
>   hdmi->plat_data->input_bus_encoding;
>   else
>   hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT;
>  
>   /* TOFIX: Default to RGB888 output format */
> - hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> + if (hdmi->plat_data->get_output_bus_format)
> + hdmi->hdmi_data.enc_out_bus_format =
> + hdmi->plat_data->get_output_bus_format(data);
> + else
> + hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>  
>   hdmi->hdmi_data.pix_repet_factor = 0;
>   hdmi->hdmi_data.hdcp_enable = 0;
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 7a02744ce0bc..2e797f782c51 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -142,6 +142,11 @@ struct dw_hdmi_plat_data {
>   int (*configure_phy)(struct dw_hdmi *hdmi,
>const struct dw_hdmi_plat_data *pdata,
>unsigned long mpixelclock);
> +
> + unsigned long (*get_input_bus_format)(void *data);
> + unsigned long 

[radeon-alex:amd-staging-drm-next 597/616] ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

[kbuild test robot]

Hi Ken,

First bad commit (maybe != root cause):

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   0050e1bd9b509dc764c0180ad5010d4591755abf
commit: 1d752442f3d6275b40bace55d022e792167f7fca [597/616] drm/amd/display: Use 
100 Hz precision for pipe pixel clocks
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 1d752442f3d6275b40bace55d022e792167f7fca
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>> ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

[Greg Kroah-Hartman]

On Tue, Dec 18, 2018 at 09:14:43PM +0100, Daniel Vetter wrote:
> This is the much more correct fix for my earlier attempt at:
> 
> https://lkml.org/lkml/2018/12/10/118
> 
> Short recap:
> 
> - There's not actually a locking issue, it's just lockdep being a bit
>   too eager to complain about a possible deadlock.
> 
> - Contrary to what I claimed the real problem is recursion on
>   kn->count. Greg pointed me at sysfs_break_active_protection(), used
>   by the scsi subsystem to allow a sysfs file to unbind itself. That
>   would be a real deadlock, which isn't what's happening here. Also,
>   breaking the active protection means we'd need to manually handle
>   all the lifetime fun.
> 
> - With Rafael we discussed the task_work approach, which kinda works,
>   but has two downsides: It's a functional change for a lockdep
>   annotation issue, and it won't work for the bind file (which needs
>   to get the errno from the driver load function back to userspace).
> 
> - Greg also asked why this never showed up: To hit this you need to
>   unregister a 2nd driver from the unload code of your first driver. I
>   guess only gpus do that. The bug has always been there, but only
>   with a recent patch series did we add more locks so that lockdep
>   built a chain from unbinding the snd-hda driver to the
>   acpi_video_unregister call.
> 
> Full lockdep splat:
> 
> [12301.898799] 
> [12301.898805] WARNING: possible recursive locking detected
> [12301.898811] 4.20.0-rc7+ #84 Not tainted
> [12301.898815] 
> [12301.898821] bash/5297 is trying to acquire lock:
> [12301.898826] f61c6093 (kn->count#39){}, at: 
> kernfs_remove_by_name_ns+0x3b/0x80
> [12301.898841] but task is already holding lock:
> [12301.898847] 5f634021 (kn->count#39){}, at: 
> kernfs_fop_write+0xdc/0x190
> [12301.898856] other info that might help us debug this:
> [12301.898862]  Possible unsafe locking scenario:
> [12301.898867]CPU0
> [12301.898870]
> [12301.898874]   lock(kn->count#39);
> [12301.898879]   lock(kn->count#39);
> [12301.898883] *** DEADLOCK ***
> [12301.898891]  May be due to missing lock nesting notation
> [12301.898899] 5 locks held by bash/5297:
> [12301.898903]  #0: cd800e54 (sb_writers#4){.+.+}, at: 
> vfs_write+0x17f/0x1b0
> [12301.898915]  #1: 0465e7c2 (>mutex){+.+.}, at: 
> kernfs_fop_write+0xd3/0x190
> [12301.898925]  #2: 5f634021 (kn->count#39){}, at: 
> kernfs_fop_write+0xdc/0x190
> [12301.898936]  #3: 414ef7ac (>mutex){}, at: 
> device_release_driver_internal+0x34/0x240
> [12301.898950]  #4: 3218fbdf (register_count_mutex){+.+.}, at: 
> acpi_video_unregister+0xe/0x40
> [12301.898960] stack backtrace:
> [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
> [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 
> 68SCF Ver. F.01 03/11/2011
> [12301.898982] Call Trace:
> [12301.898989]  dump_stack+0x67/0x9b
> [12301.898997]  __lock_acquire+0x6ad/0x1410
> [12301.899003]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899010]  ? find_held_lock+0x2d/0x90
> [12301.899017]  ? mutex_spin_on_owner+0xe4/0x150
> [12301.899023]  ? find_held_lock+0x2d/0x90
> [12301.899030]  ? lock_acquire+0x90/0x180
> [12301.899036]  lock_acquire+0x90/0x180
> [12301.899042]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899049]  __kernfs_remove+0x296/0x310
> [12301.899055]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899060]  ? kernfs_name_hash+0xd/0x80
> [12301.899066]  ? kernfs_find_ns+0x6c/0x100
> [12301.899073]  kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899080]  bus_remove_driver+0x92/0xa0
> [12301.899085]  acpi_video_unregister+0x24/0x40
> [12301.899127]  i915_driver_unload+0x42/0x130 [i915]
> [12301.899160]  i915_pci_remove+0x19/0x30 [i915]
> [12301.899169]  pci_device_remove+0x36/0xb0
> [12301.899176]  device_release_driver_internal+0x185/0x240
> [12301.899183]  unbind_store+0xaf/0x180
> [12301.899189]  kernfs_fop_write+0x104/0x190
> [12301.899195]  __vfs_write+0x31/0x180
> [12301.899203]  ? rcu_read_lock_sched_held+0x6f/0x80
> [12301.899209]  ? rcu_sync_lockdep_assert+0x29/0x50
> [12301.899216]  ? __sb_start_write+0x13c/0x1a0
> [12301.899221]  ? vfs_write+0x17f/0x1b0
> [12301.899227]  vfs_write+0xb9/0x1b0
> [12301.899233]  ksys_write+0x50/0xc0
> [12301.899239]  do_syscall_64+0x4b/0x180
> [12301.899247]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [12301.899253] RIP: 0033:0x7f452ac7f7a4
> [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 
> 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 
> 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX: 
> 0001
> [12301.899282] RAX: ffda RBX: 000d RCX: 
> 7f452ac7f7a4
> [12301.899288] RDX: 000d RSI: 

Re: [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

Tomas and Daniel,

From the discussion on this thread, I infer following understanding:

 * At present(v9) I915 wants to be hard binded to mei_hdcp
   device-driver binding status through components
 o This means I915 driver load will get complete only when the
   mei_hdcp's device and driver are bound.
 o if mei_hdcp device reset I915 will unregister itself from
   userspace, and wait for the mei_hdcp device-deriver rebinding.
 + Could be due to FW error or any unexpected failures those
   are rare occurances.
 o when mei_hdcp module is removed i915 will unregister itself.
 o Becasue of this, Ideally I915 dont expect the device reset from
   mei for suspend and resume.
 * At present Mei bus is designed as below:
 o Device will disappear on FW failures, FW upgrade, suspend of the
   system etc.
 o And when the errors are handled or on system resume mei device
   will reappear, hence binding with corresponding driver.
 * Mei doesn't plan to avoid the device reset(disappearance and
   reappearance) for suspend and resume in near future.

Based on above understanding, I propose the below approach. Please correct or 
approve it.

 * At present(v9) component_add from mei_hdcp indicates the mei_hdcp's
   device-driver binded state.
 * Instead lets use component to indicate the mei_hdcp's module
   availability,
 o by adding the component at module_init and removing it from
   module_exit.
 * This way I915 will not be impacted due to the mei device reset at
   suspend.
 * In such scenario I915 will have no idea about the device-driver bind
   status of mei_hdcp.
 o So incase of device is not available, mei_hdcp is responsible to
   prune such calls with -EIO error.
 * This approach avoid any future impact to I915, incase mei intended
   to support suspend and resume.

I am aware this is not the ideal solution we want. But I feel this is the best 
at present we could do for this I915-mei interface.

Best regards,
Ram

On 12/17/2018 7:16 PM, Daniel Vetter wrote:

On Mon, Dec 17, 2018 at 11:57 AM Winkler, Tomas  wrote:



On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:

On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas

wrote:

On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam

wrote:

Tomas and Daniel,

We got an issue here.

The relationship that we try to build between I915 and
mei_hdcp is as

follows:

We are using the components to establish the relationship.
I915 is component master where as mei_hdcp is component.
I915 adds the component master during the module load.
mei_hdcp adds the

component when the driver->probe is called (on device driver binding).

I915 forces itself such that until mei_hdcp component is added
I915_load

wont be complete.

Similarly on complete system, if mei_hdcp component is
removed,

immediately I915 unregister itself and HW will be shutdown.

This is completely fine when the modules are loaded and unloaded.

But during suspend, mei device disappears and mei bus handles
it by

unbinding device and driver by calling driver->remove.

This in-turn removes the component and triggers the master
unbind of I915

where, I915 unregister itself.

This cause the HW state mismatch during the suspend and resume.

Please check the powerwell mismatch errors at CI report for v9
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4
005/
igt@
gem_exec_susp...@basic-s3.html

More over unregistering I915 during the suspend is not expected.
So how do

we handle this?

Bit more context from our irc discussion with Ram:

I found this very surprising, since I don't know of any other
subsystems where the devices get outright removed when going
through a

suspend/resume cycle.

The device model was built to handle this stuff
correctly: First clients/devices/interfaces get suspend, then
the parent/bridge/bus. Same dance in reverse when resuming. This
even holds for lots of hotpluggable buses, where child devices
could indeed disappear on resume, but as long as they don't,
everything stays the same. It's really surprising for something
that's soldered onto the

board like ME.

HDCP is an application in the ME it's not ME itself..  On the
linux side HDCP2 is a virtual device  on mei client virtual bus,
the bus  is teared

down on ME reset, which mostly happen  on power transitions.

Theoretically,  we could keep it up during power transitions, but
so fare it was not necessary and second it's not guarantie that
the all ME

applications will reappear after reset.

When does this happen that an ME application doesn't come back after e.g.
suspend/resume?

No, this can happen in special flows such as  fw updates and error conditions,

but is has to be supported as well.

Also, what's all the place where this reset can happen? Just
suspend/resume/hibernate and all these, or also at other times?

Also on errors and fw update,  the basic assumption is here that it can happen

any time.

If this can happen any time, what are 

[Bug 109090] email id is accepting values

[bugzilla-daemon]

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

nikhilverma1...@gmail.com changed:

   What|Removed |Added

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

-- 
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 109090] email id is accepting values

[bugzilla-daemon]

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

nikhilverma1...@gmail.com changed:

   What|Removed |Added

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

-- 
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 109090] email id is accepting values

[bugzilla-daemon]

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

--- Comment #1 from nikhilverma1...@gmail.com ---
ok

-- 
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 109090] email id is accepting values

[bugzilla-daemon]

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

nikhilverma1...@gmail.com changed:

   What|Removed |Added

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

-- 
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 109090] email id is accepting values

[bugzilla-daemon]

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

Bug ID: 109090
   Summary: email id is accepting values
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R100
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nikhilverma1...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

xxyyzz

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

[radeon-alex:amd-staging-drm-next 563/616] ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   0050e1bd9b509dc764c0180ad5010d4591755abf
commit: 6378ef012ddce949a60c9c3742816a9c3c9ff3bf [563/616] drm/amd/display: Add 
below the range support for FreeSync
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6378ef012ddce949a60c9c3742816a9c3c9ff3bf
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   ./usr/include/linux/v4l2-controls.h:1105: found __[us]{8,16,32,64} type 
without #include 
>> ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
   make[2]: *** [__modpost] Error 1
   make[2]: Target '_modpost' not remade because of errors.
   make[1]: *** [modules] Error 2
   make[1]: Target '_all' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] drm/msm/dpu: add display port support in DPU

[kbuild test robot]

Hi Jeykumar,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.20-rc7 next-20181218]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jeykumar-Sankaran/drm-msm-dpu-fix-documentation-for-intf_type/20181218-070519
base:   git://people.freedesktop.org/~robclark/linux msm-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/msm/disp/dpu1/dpu_kms.c: In function 
'_dpu_kms_initialize_displayport':
>> drivers/gpu//drm/msm/disp/dpu1/dpu_kms.c:449:13: error: 'struct 
>> msm_drm_private' has no member named 'dp'; did you mean 'edp'?
 if (!priv->dp)
^~
edp
>> drivers/gpu//drm/msm/disp/dpu1/dpu_kms.c:458:7: error: implicit declaration 
>> of function 'msm_dp_modeset_init'; did you mean 'msm_edp_modeset_init'? 
>> [-Werror=implicit-function-declaration]
 rc = msm_dp_modeset_init(priv->dp, dev, encoder);
  ^~~
  msm_edp_modeset_init
   drivers/gpu//drm/msm/disp/dpu1/dpu_kms.c:458:33: error: 'struct 
msm_drm_private' has no member named 'dp'; did you mean 'edp'?
 rc = msm_dp_modeset_init(priv->dp, dev, encoder);
^~
edp
   cc1: some warnings being treated as errors

vim +449 drivers/gpu//drm/msm/disp/dpu1/dpu_kms.c

   441  
   442  static int _dpu_kms_initialize_displayport(struct drm_device *dev,
   443  struct msm_drm_private 
*priv,
   444  struct dpu_kms *dpu_kms)
   445  {
   446  struct drm_encoder *encoder = NULL;
   447  int rc;
   448  
 > 449  if (!priv->dp)
   450  return 0;
   451  
   452  encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
   453  if (IS_ERR(encoder)) {
   454  DPU_ERROR("encoder init failed for dsi display\n");
   455  return PTR_ERR(encoder);
   456  }
   457  
 > 458  rc = msm_dp_modeset_init(priv->dp, dev, encoder);
   459  if (rc) {
   460  DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
   461  drm_encoder_cleanup(encoder);
   462  }
   463  
   464  return rc;
   465  }
   466  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][resend] drm: dw-hdmi-i2s: convert to SPDX identifiers

[Laurent Pinchart]

Hi Morimoto-san,

On Wednesday, 19 December 2018 02:16:55 EET Kuninori Morimoto wrote:
> Hi
> 
>  This patch updates license to use SPDX-License-Identifier
>  instead of verbose license text.
>  
>  Signed-off-by: Kuninori Morimoto 
> >>> 
> >>> Reviewed-by: Laurent Pinchart 
> >>> 
>  ---
>  few weeks passed, nothing happen. I re-post this patch again.
>  I added Andrew on Cc
> >>> 
> >>> The driver seems to be lacking a maintainer :-S
> >> 
> >> bridge drivers all have a fallback maintainer, but none of them are
> >> cc'ed. It's maintained in drm-misc, so you could just push the patch
> >> too :-) Especially since you're listed:
> >> 
> >> DRM DRIVERS FOR BRIDGE CHIPS
> >> M:Archit Taneja 
> >> M:Andrzej Hajda 
> >> R:Laurent Pinchart 
> 
> ??
> I double checked To and Cc.
> Original patch included Archit, Andrzej address,
> but these were suddenly removed on from Re: mail.
> (I added these address again on this mail).
> ... what's happening ??

I've noticed that several mailing lists sometimes drop addresses from Cc: in 
the e-mail content (but still forwards mails to those addresses). I haven't 
investigated why.

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v7 3/6] ARM: dts: qcom: Removed unused interrupt-names from GPU node

[Jordan Crouse]

On Tue, Dec 18, 2018 at 02:29:25PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
> >
> > 'interrupt-names' shouldn't be used in cases when there is only
> > one interrupt and it is not otherwise used in the driver.
> >
> > Signed-off-by: Jordan Crouse 
> > ---
> >  arch/arm/boot/dts/qcom-apq8064.dtsi | 1 -
> >  1 file changed, 1 deletion(-)
> 
> Looks good to me.  It should be noted that Andy shouldn't land this
> until he has a tree that contains ("drm/msm/gpu: Remove hardcoded
> interrupt name").  ...or he should Ack this and it should go through
> the same tree as that patch.
> 
> I'm curious: is there a reason you didn't remove it from the other two users?
> 
> linuxnext/master:arch/arm/boot/dts/imx51.dtsi:
> interrupt-names = "kgsl_3d0_irq";
> linuxnext/master:arch/arm/boot/dts/imx53.dtsi:
> interrupt-names = "kgsl_3d0_irq";

Because those aren't in Andy's tree. I suspect after all this lands we'll need
another sweep to clean up the extras. There is also a 8996 dt floating around
somewhere.

Jordan

> ...also: if this really is only for "apq8064" and not globally for all
> qcom devices it'd be nice to mention "apq8064" somewhere in the
> subject.

> -Doug

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] arm64: dts: sdm845: Add gpu and gmu device nodes

[Doug Anderson]

Hi,

On Tue, Dec 18, 2018 at 10:33 AM Jordan Crouse  wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse 
> ---
>
> v7: Updated the GMU compatible string and removed interrupt-names
>
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 122 +++
>  1 file changed, 122 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 233a5898ebc2..4779014e4a05 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1349,6 +1350,127 @@
> };
> };
>
> +
> +   gpu@500 {

Repeating my comments from v6:

nit that you're adding an extra blank line here that you don't need.
Given the quantity of outstanding dts patches though, it's almost
certain that Andy will need to manually resolve conflicts when
applying this patch so presumably he can fix up when he lands.

In any case, feel free to add:

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 


> +   compatible = "qcom,adreno-630.2", "qcom,adreno";
> +   #stream-id-cells = <16>;
> +
> +   reg = <0x500 0x4>, <0x509e000 0x10>;
> +   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
> +
> +   /*
> +* Look ma, no clocks! The GPU clocks and power are
> +* controlled entirely by the GMU
> +*/
> +
> +   interrupts = ;
> +
> +   iommus = <_smmu 0>;
> +
> +   operating-points-v2 = <_opp_table>;
> +
> +   qcom,gmu = <>;
> +
> +   gpu_opp_table: opp-table {
> +   compatible = "operating-points-v2-qcom-level";

I believe that the consensus from the v2 comments at
 are that this should
be:

compatible = "operating-points-v2-qcom-level", "operating-points-v2";

...same with the other one below...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 4/6] arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU

[Doug Anderson]

Hi,

On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
>
> 'interrupt-names' shouldn't be used in cases when there is only
> one interrupt and it is not otherwise used in the driver.
>
> Signed-off-by: Jordan Crouse 
> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 -
>  1 file changed, 1 deletion(-)

Looks good to me.  It should be noted that Andy shouldn't land this
until he has a tree that contains ("drm/msm/gpu: Remove hardcoded
interrupt name").  ...or he should Ack this and it should go through
the same tree as that patch.

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

Re: [PATCH v7 1/6] drm/msm/gpu: Remove hardcoded interrupt name

[Doug Anderson]

Hi,

On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
>
> Every GPU core only has one interrupt so there isn't any
> value in looking up the interrupt by name. Remove the name (which
> is legacy anyway) and use platform_get_irq() instead.
>
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
>  drivers/gpu/drm/msm/msm_gpu.c   | 2 +-
>  drivers/gpu/drm/msm/msm_gpu.h   | 1 -
>  3 files changed, 1 insertion(+), 3 deletions(-)

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

Re: [PATCH] drm/panel: rpi-touchscreen: Add backlight support

[kbuild test robot]

Hi Nicolas,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc7 next-20181218]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Saenz-Julienne/drm-panel-rpi-touchscreen-Add-backlight-support/20181215-164117
config: x86_64-randconfig-s3-12190437 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "devm_backlight_device_register" 
>> [drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 5/6] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings

[Rob Herring]

On Tue, 18 Dec 2018 11:32:40 -0700, Jordan Crouse wrote:
> Update the GPU bindings and document the new bindings for the GMU
> device found with Adreno a6xx targets.
> 
> Signed-off-by: Jordan Crouse 
> ---
> 
> v7: Updated the GMU compatible string and clarified details about when clocks
> can be optional on the GPU
> 
>  .../devicetree/bindings/display/msm/gmu.txt   | 59 +++
>  .../devicetree/bindings/display/msm/gpu.txt   | 42 -
>  2 files changed, 98 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
> 

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

[PATCH 1/4] drm/i915: Add an update callback to intel_encoder and call this on fastsets

[Hans de Goede]

When we are doing a fastset (needs_modeset=false, update_pipe=true) we
may need to update some encoder-level things such as checking that psr
is enabled.

This commit adds an update callback to intel_encoder and a new
intel_encoders_update helper which calls this for all encoders connected
to a crtc. The new intel_encoders_update helper is called from
intel_update_crtc this when doing a fastset.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_display.c | 23 +++
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e472b650931a..9a22c84ff2be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5578,6 +5578,26 @@ static void intel_encoders_post_pll_disable(struct 
drm_crtc *crtc,
}
 }
 
+static void intel_encoders_update(struct drm_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct drm_atomic_state *old_state)
+{
+   struct drm_connector_state *conn_state;
+   struct drm_connector *conn;
+   int i;
+
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
+   struct intel_encoder *encoder =
+   to_intel_encoder(conn_state->best_encoder);
+
+   if (conn_state->crtc != crtc)
+   continue;
+
+   if (encoder->update)
+   encoder->update(encoder, crtc_state, conn_state);
+   }
+}
+
 static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
 struct drm_atomic_state *old_state)
 {
@@ -12774,6 +12794,9 @@ static void intel_update_crtc(struct drm_crtc *crtc,
} else {
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state),
   pipe_config);
+
+   if (pipe_config->update_pipe)
+   intel_encoders_update(crtc, pipe_config, state);
}
 
if (new_plane_state)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ef1315d7c4ae..9fb5b518f91c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -243,6 +243,9 @@ struct intel_encoder {
void (*post_pll_disable)(struct intel_encoder *,
 const struct intel_crtc_state *,
 const struct drm_connector_state *);
+   void (*update)(struct intel_encoder *,
+  const struct intel_crtc_state *,
+  const struct drm_connector_state *);
/* Read out the current hw state of this connector, returning true if
 * the encoder is active. If the encoder is enabled it also set the pipe
 * it is connected to in the pipe parameter. */
-- 
2.20.1

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

[PATCH 2/4] drm/i915: DDI: call intel_psr_enable() on encoder updates

[Hans de Goede]

Call intel_psr_enable() on encoder updates to make sure that we enable
PSR (when applicable) on fastsets.

Note calling intel_psr_enable() when PSR has already been enabled is a
no-op, so it is safe to do this on every encoder->update callback.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_ddi.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e3cc19e19199..30f54c334dd7 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3537,6 +3537,23 @@ static void intel_disable_ddi(struct intel_encoder 
*encoder,
intel_disable_ddi_dp(encoder, old_crtc_state, old_conn_state);
 }
 
+static void intel_update_ddi_dp(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
+   const struct drm_connector_state *conn_state)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+
+   intel_psr_enable(intel_dp, crtc_state);
+}
+
+static void intel_update_ddi(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state *conn_state)
+{
+   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+   intel_update_ddi_dp(encoder, crtc_state, conn_state);
+}
+
 static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
 const struct intel_crtc_state 
*pipe_config,
 enum port port)
@@ -4169,6 +4186,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_encoder->pre_enable = intel_ddi_pre_enable;
intel_encoder->disable = intel_disable_ddi;
intel_encoder->post_disable = intel_ddi_post_disable;
+   intel_encoder->update = intel_update_ddi;
intel_encoder->get_hw_state = intel_ddi_get_hw_state;
intel_encoder->get_config = intel_ddi_get_config;
intel_encoder->suspend = intel_ddi_encoder_suspend;
-- 
2.20.1

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

[PATCH 4/4] drm/i915: DDI: call intel_edp_drrs_enable() on encoder updates

[Hans de Goede]

Call intel_edp_drrs_enable() on encoder updates to make sure that we enable
DRRS (when applicable) on fastsets.

Note calling intel_edp_drrs_enable() when PSR has already been enabled is a
no-op, so it is safe to do this on every encoder->update callback.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_ddi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 30f54c334dd7..b74f3c415fbb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3544,6 +3544,7 @@ static void intel_update_ddi_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
 
intel_psr_enable(intel_dp, crtc_state);
+   intel_edp_drrs_enable(intel_dp, crtc_state);
 }
 
 static void intel_update_ddi(struct intel_encoder *encoder,
-- 
2.20.1

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

[PATCH 3/4] drm/i915: Allow calling intel_edp_drrs_enable twice

[Hans de Goede]

Do not make it an error to call intel_edp_drrs_enable while drrs has
already been enabled, instead exit silently in this case.

This is a preparation patch for ensuring that drrs is enabled on fastsets.

Note that the removed WARN_ON could also be triggered from userspace
through the i915_drrs_ctl debugfs entry which was added by
commit 35954e88bc50 ("drm/i915: Runtime disable for eDP DRRS")

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5b601b754707..62fd11540942 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6432,8 +6432,8 @@ void intel_edp_drrs_enable(struct intel_dp *intel_dp,
}
 
mutex_lock(_priv->drrs.mutex);
-   if (WARN_ON(dev_priv->drrs.dp)) {
-   DRM_ERROR("DRRS already enabled\n");
+   if (dev_priv->drrs.dp) {
+   DRM_DEBUG_KMS("DRRS already enabled\n");
goto unlock;
}
 
-- 
2.20.1

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

Re: [PATCH v7 3/6] ARM: dts: qcom: Removed unused interrupt-names from GPU node

[Doug Anderson]

Hi,

On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
>
> 'interrupt-names' shouldn't be used in cases when there is only
> one interrupt and it is not otherwise used in the driver.
>
> Signed-off-by: Jordan Crouse 
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 1 -
>  1 file changed, 1 deletion(-)

Looks good to me.  It should be noted that Andy shouldn't land this
until he has a tree that contains ("drm/msm/gpu: Remove hardcoded
interrupt name").  ...or he should Ack this and it should go through
the same tree as that patch.

I'm curious: is there a reason you didn't remove it from the other two users?

linuxnext/master:arch/arm/boot/dts/imx51.dtsi:
interrupt-names = "kgsl_3d0_irq";
linuxnext/master:arch/arm/boot/dts/imx53.dtsi:
interrupt-names = "kgsl_3d0_irq";

...also: if this really is only for "apq8064" and not globally for all
qcom devices it'd be nice to mention "apq8064" somewhere in the
subject.

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

Re: [PATCH v7 2/6] drm/msm: drop interrupt-names

[Rob Herring]

On Tue, 18 Dec 2018 11:32:37 -0700, Jordan Crouse wrote:
> Each GPU core only uses one interrupt so we don't to look up
> an interrupt by name and thereby we don't need interrupt-names.
> 
> Signed-off-by: Jordan Crouse 
> ---
>  Documentation/devicetree/bindings/display/msm/gpu.txt | 1 -
>  1 file changed, 1 deletion(-)
> 

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

Re: [WIP PATCH 05/15] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs

[Lyude Paul]

On Fri, 2018-12-14 at 10:38 +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote:
> > Up until now, freeing payloads on remote MST hubs that just had ports
> > removed has almost never worked because we've been relying on port
> > validation in order to stop us from accessing ports that have already
> > been freed from memory, but ports which need their payloads released due
> > to being removed will never be a valid part of the topology after
> > they've been removed.
> > 
> > Since we've introduced malloc refs, we can replace all of the validation
> > logic in payload helpers which are used for deallocation with some
> > well-placed malloc krefs. This ensures that regardless of whether or not
> > the ports are still valid and in the topology, any port which has an
> > allocated payload will remain allocated in memory until it's payloads
> > have been removed - finally allowing us to actually release said
> > payloads correctly.
> > 
> > Signed-off-by: Lyude Paul 
> 
> I think with this we can also remove the int return value (that everyone
> ignored except for some debug output) from drm_dp_update_payload_part1/2.
> Follow-up cleanup patch ofc.
A note as well-I'm not sure we want to remove that yet, it might actually be a
better idea to just teach drivers to actually look at the return values so
they can take action if it fails. Of course, such actions wouldn't involve
actually changing the atomic state that userspace set, but moreso knowing
which parts of updating the payload succeeded or not so if a downstream branch
was disconnected mid-atomic commit we have enough information to know what
steps we need to skip when userspace later unsets the mode on said branch.
> 
> This looks good.
> 
> Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
> >  1 file changed, 30 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index ae9d019af9f2..93f08bfd2ab3 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1989,10 +1989,6 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> > u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> > int i;
> >  
> > -   port = drm_dp_mst_topology_get_port_validated(mgr, port);
> > -   if (!port)
> > -   return -EINVAL;
> > -
> > port_num = port->port_num;
> > mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
> > if (!mstb) {
> > @@ -2000,10 +1996,8 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> >port->parent,
> >_num);
> >  
> > -   if (!mstb) {
> > -   drm_dp_mst_topology_put_port(port);
> > +   if (!mstb)
> > return -EINVAL;
> > -   }
> > }
> >  
> > txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > @@ -2032,7 +2026,6 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> > kfree(txmsg);
> >  fail_put:
> > drm_dp_mst_topology_put_mstb(mstb);
> > -   drm_dp_mst_topology_put_port(port);
> > return ret;
> >  }
> >  
> > @@ -2137,15 +2130,16 @@ static int drm_dp_destroy_payload_step2(struct
> > drm_dp_mst_topology_mgr *mgr,
> >   */
> >  int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
> >  {
> > -   int i, j;
> > -   int cur_slots = 1;
> > struct drm_dp_payload req_payload;
> > struct drm_dp_mst_port *port;
> > +   int i, j;
> > +   int cur_slots = 1;
> >  
> > mutex_lock(>payload_lock);
> > for (i = 0; i < mgr->max_payloads; i++) {
> > struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> > struct drm_dp_payload *payload = >payloads[i];
> > +   bool put_port = false;
> >  
> > /* solve the current payloads - compare to the hw ones
> >- update the hw view */
> > @@ -2153,12 +2147,20 @@ int drm_dp_update_payload_part1(struct
> > drm_dp_mst_topology_mgr *mgr)
> > if (vcpi) {
> > port = container_of(vcpi, struct drm_dp_mst_port,
> > vcpi);
> > -   port = drm_dp_mst_topology_get_port_validated(mgr,
> > - port);
> > -   if (!port) {
> > -   mutex_unlock(>payload_lock);
> > -   return -EINVAL;
> > +
> > +   /* Validated ports don't matter if we're releasing
> > +* VCPI
> > +*/
> > +   if (vcpi->num_slots) {
> > +   port = drm_dp_mst_topology_get_port_validated(
> > +   mgr, port);
> > +   

Re: [WIP PATCH 06/15] drm/i915: Keep malloc references to MST ports

[Lyude Paul]

On Fri, 2018-12-14 at 10:32 +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:35PM -0500, Lyude Paul wrote:
> > So that the ports stay around until we've destroyed the connectors, in
> > order to ensure that we don't pass an invalid pointer to any MST helpers
> > once we introduce the new MST VCPI helpers.
> > 
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/i915/intel_connector.c | 4 
> >  drivers/gpu/drm/i915/intel_dp_mst.c| 2 ++
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_connector.c
> > b/drivers/gpu/drm/i915/intel_connector.c
> > index 18e370f607bc..37d2c644f4b8 100644
> > --- a/drivers/gpu/drm/i915/intel_connector.c
> > +++ b/drivers/gpu/drm/i915/intel_connector.c
> > @@ -95,6 +95,10 @@ void intel_connector_destroy(struct drm_connector
> > *connector)
> > intel_panel_fini(_connector->panel);
> >  
> > drm_connector_cleanup(connector);
> > +
> > +   if (intel_connector->port)
> 
> We set this as the first thing in intel_dp_add_mst_connector, so this
> check isn't doing anything.

I think this comment might be a mistake? intel_connector_destroy() is shared
by all of the intel connectors, so some may not have a value in
intel_connector->port. I can move it to it's own destroy callback for MST if
you would prefer though.
> 
> > +   drm_dp_mst_put_port_malloc(intel_connector->port);
> > +
> > kfree(connector);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index f05427b74e34..4d6ced34d465 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -484,6 +484,8 @@ static struct drm_connector
> > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > if (ret)
> > goto err;
> >  
> > +   drm_dp_mst_get_port_malloc(port);
> 
> Needs to be moved up where we assing intel_connector->port, or it'll
> underflow on cleanup on error paths.
> 
> > +
> > return connector;
> >  
> >  err:
> > -- 
> > 2.19.2
> > 
-- 
Cheers,
Lyude Paul

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

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

[Rafael J. Wysocki]

On Tue, Dec 18, 2018 at 9:14 PM Daniel Vetter  wrote:
>
> This is the much more correct fix for my earlier attempt at:
>
> https://lkml.org/lkml/2018/12/10/118
>
> Short recap:
>
> - There's not actually a locking issue, it's just lockdep being a bit
>   too eager to complain about a possible deadlock.
>
> - Contrary to what I claimed the real problem is recursion on
>   kn->count. Greg pointed me at sysfs_break_active_protection(), used
>   by the scsi subsystem to allow a sysfs file to unbind itself. That
>   would be a real deadlock, which isn't what's happening here. Also,
>   breaking the active protection means we'd need to manually handle
>   all the lifetime fun.
>
> - With Rafael we discussed the task_work approach, which kinda works,
>   but has two downsides: It's a functional change for a lockdep
>   annotation issue, and it won't work for the bind file (which needs
>   to get the errno from the driver load function back to userspace).
>
> - Greg also asked why this never showed up: To hit this you need to
>   unregister a 2nd driver from the unload code of your first driver. I
>   guess only gpus do that. The bug has always been there, but only
>   with a recent patch series did we add more locks so that lockdep
>   built a chain from unbinding the snd-hda driver to the
>   acpi_video_unregister call.
>
> Full lockdep splat:
>
> [12301.898799] 
> [12301.898805] WARNING: possible recursive locking detected
> [12301.898811] 4.20.0-rc7+ #84 Not tainted
> [12301.898815] 
> [12301.898821] bash/5297 is trying to acquire lock:
> [12301.898826] f61c6093 (kn->count#39){}, at: 
> kernfs_remove_by_name_ns+0x3b/0x80
> [12301.898841] but task is already holding lock:
> [12301.898847] 5f634021 (kn->count#39){}, at: 
> kernfs_fop_write+0xdc/0x190
> [12301.898856] other info that might help us debug this:
> [12301.898862]  Possible unsafe locking scenario:
> [12301.898867]CPU0
> [12301.898870]
> [12301.898874]   lock(kn->count#39);
> [12301.898879]   lock(kn->count#39);
> [12301.898883] *** DEADLOCK ***
> [12301.898891]  May be due to missing lock nesting notation
> [12301.898899] 5 locks held by bash/5297:
> [12301.898903]  #0: cd800e54 (sb_writers#4){.+.+}, at: 
> vfs_write+0x17f/0x1b0
> [12301.898915]  #1: 0465e7c2 (>mutex){+.+.}, at: 
> kernfs_fop_write+0xd3/0x190
> [12301.898925]  #2: 5f634021 (kn->count#39){}, at: 
> kernfs_fop_write+0xdc/0x190
> [12301.898936]  #3: 414ef7ac (>mutex){}, at: 
> device_release_driver_internal+0x34/0x240
> [12301.898950]  #4: 3218fbdf (register_count_mutex){+.+.}, at: 
> acpi_video_unregister+0xe/0x40
> [12301.898960] stack backtrace:
> [12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
> [12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 
> 68SCF Ver. F.01 03/11/2011
> [12301.898982] Call Trace:
> [12301.898989]  dump_stack+0x67/0x9b
> [12301.898997]  __lock_acquire+0x6ad/0x1410
> [12301.899003]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899010]  ? find_held_lock+0x2d/0x90
> [12301.899017]  ? mutex_spin_on_owner+0xe4/0x150
> [12301.899023]  ? find_held_lock+0x2d/0x90
> [12301.899030]  ? lock_acquire+0x90/0x180
> [12301.899036]  lock_acquire+0x90/0x180
> [12301.899042]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899049]  __kernfs_remove+0x296/0x310
> [12301.899055]  ? kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899060]  ? kernfs_name_hash+0xd/0x80
> [12301.899066]  ? kernfs_find_ns+0x6c/0x100
> [12301.899073]  kernfs_remove_by_name_ns+0x3b/0x80
> [12301.899080]  bus_remove_driver+0x92/0xa0
> [12301.899085]  acpi_video_unregister+0x24/0x40
> [12301.899127]  i915_driver_unload+0x42/0x130 [i915]
> [12301.899160]  i915_pci_remove+0x19/0x30 [i915]
> [12301.899169]  pci_device_remove+0x36/0xb0
> [12301.899176]  device_release_driver_internal+0x185/0x240
> [12301.899183]  unbind_store+0xaf/0x180
> [12301.899189]  kernfs_fop_write+0x104/0x190
> [12301.899195]  __vfs_write+0x31/0x180
> [12301.899203]  ? rcu_read_lock_sched_held+0x6f/0x80
> [12301.899209]  ? rcu_sync_lockdep_assert+0x29/0x50
> [12301.899216]  ? __sb_start_write+0x13c/0x1a0
> [12301.899221]  ? vfs_write+0x17f/0x1b0
> [12301.899227]  vfs_write+0xb9/0x1b0
> [12301.899233]  ksys_write+0x50/0xc0
> [12301.899239]  do_syscall_64+0x4b/0x180
> [12301.899247]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [12301.899253] RIP: 0033:0x7f452ac7f7a4
> [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 
> 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 
> 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX: 
> 0001
> [12301.899282] RAX: ffda RBX: 000d RCX: 
> 7f452ac7f7a4
> [12301.899288] RDX: 000d RSI: 5612a1abf7c0 

Re: [WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports

[Lyude Paul]

On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote:
> > The current way of handling refcounting in the DP MST helpers is really
> > confusing and probably just plain wrong because it's been hacked up many
> > times over the years without anyone actually going over the code and
> > seeing if things could be simplified.
> > 
> > To the best of my understanding, the current scheme works like this:
> > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
> > this refcount hits 0 for either of the two, they're removed from the
> > topology state, but not immediately freed. Both ports and branch devices
> > will reinitialize their kref once it's hit 0 before actually destroying
> > themselves. The intended purpose behind this is so that we can avoid
> > problems like not being able to free a remote payload that might still
> > be active, due to us having removed all of the port/branch device
> > structures in memory, as per:
> > 
> > 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
> > 
> > Which may have worked, but then it caused use-after-free errors. Being
> > new to MST at the time, I tried fixing it;
> > 
> > 263efde31f97 ("drm/dp/mst: Get validated port ref in
> > drm_dp_update_payload_part1()")
> > 
> > But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
> > are validated in almost every DP MST helper function. Simply put, this
> > means we go through the topology and try to see if the given
> > drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> > before trying to use it in order to avoid dereferencing freed memory
> > (something that has happened a LOT in the past with this library).
> > Because of this it doesn't actually matter whether or not we keep keep
> > the ports and branches around in memory as that's not enough, because
> > any function that validates the branches and ports passed to it will
> > still reject them anyway since they're no longer in the topology
> > structure. So, use-after-free errors were fixed but payload deallocation
> > was completely broken.
> > 
> > Two years later, AMD informed me about this issue and I attempted to
> > come up with a temporary fix, pending a long-overdue cleanup of this
> > library:
> > 
> > c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just
> > ref")
> > 
> > But then that introduced use-after-free errors, so I quickly reverted
> > it:
> > 
> > 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
> > destruction, just ref"")
> > 
> > And in the process, learned that there is just no simple fix for this:
> > the design is just broken. Unfortuntely, the usage of these helpers are
> > quite broken as well. Some drivers like i915 have been smart enough to
> > avoid accessing any kind of information from MST port structures, but
> > others like nouveau have assumed, understandably so, that
> > drm_dp_mst_port structures are normal and can just be accessed at any
> > time without worrying about use-after-free errors.
> > 
> > After a lot of discussion, me and Daniel Vetter came up with a better
> > idea to replace all of this.
> > 
> > To summarize, since this is documented far more indepth in the
> > documentation this patch introduces, we make it so that drm_dp_mst_port
> > and drm_dp_mst_branch structures have two different classes of
> > refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
> > the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> > given topology. Once it hits zero, any associated connectors are removed
> > and the branch or port can no longer be validated. malloc_kref
> > corresponds to the lifetime of the memory allocation for the actual
> > structure, and will always be non-zero so long as the topology_kref is
> > non-zero. This gives us a way to allow callers to hold onto port and
> > branch device structures past their topology lifetime, and dramatically
> > simplifies the lifetimes of both structures. This also finally fixes the
> > port deallocation problem, properly.
> > 
> > Additionally: since this now means that we can keep ports and branch
> > devices allocated in memory for however long we need, we no longer need
> > a significant amount of the port validation that we currently do.
> > 
> > Additionally, there is one last scenario that this fixes, which couldn't
> > have been fixed properly beforehand:
> > 
> > - CPU1 unrefs port from topology (refcount 1->0)
> > - CPU2 refs port in topology(refcount 0->1)
> > 
> > Since we now can guarantee memory safety for ports and branches
> > as-needed, we also can make our main reference counting functions fix
> > this problem by using kref_get_unless_zero() internally so that topology
> > refcounts can only ever reach 0 once.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Jerry Zuo 
> > Cc: Harry Wentland 
> > Cc: Juston Li 
> > 

Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Rob Herring]

On Tue, Dec 18, 2018 at 12:07 PM Jordan Crouse  wrote:
>
> On Tue, Dec 18, 2018 at 11:22:01AM -0600, Rob Herring wrote:
> > On Fri, Dec 14, 2018 at 03:16:39PM -0700, Jordan Crouse wrote:
> > > Add documentation for the interconnect and interconnect-names bindings
> > > for the GPU node as detailed by bindings/interconnect/interconnect.txt.
> > >
> > > Signed-off-by: Jordan Crouse 
> > > ---
> > >  Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> > > b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > > index 8d9415180c22..19b5ae459fdb 100644
> > > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> > > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > > @@ -19,6 +19,9 @@ Required properties:
> > >* "mem_iface"
> > >  - iommus: optional phandle to an adreno iommu instance
> > >  - operating-points-v2: optional phandle to the OPP operating points
> > > +- interconnect: optional phandle to a interconnect provider.  See
> > > +  ../interconnect/interconnect.txt for details.
> > > +- interconnect-names: Name string for the interconnects.
> > >  - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that 
> > > will
> > >control the power for the GPU
> > >
> > > @@ -68,6 +71,9 @@ Example a6xx (with GMU):
> > >
> > > operating-points-v2 = <_opp_table>;
> > >
> > > +   interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
> > > +   interconnect-names = "gfx-mem";
> >
> > There's not really any point to having *-names when there is only 1
> > value.
>
> For the moment we can only look up the path from the DT by name. I guess we
> could add an lookup by index but I'm not sure if that had already been
> considered and rejected.

You don't have to support lookup by index, just support a NULL name.

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

Re: [Bug 109060] android-x86 64bit builds crashes due to android/gralloc_handle.h

[Robert Foss]

Hey Chih-Wei & Mauro,

This fix looks good to me.
Cleaned up patch name and pushed to repo.


Rob.

On 2018-12-14 01:05, bugzilla-dae...@freedesktop.org wrote:

Bug ID  109060 
Summary android-x86 64bit builds crashes due to android/gralloc_handle.h
Product DRI
Version DRI git
Hardwarex86-64 (AMD64)
OS  other
Status  NEW
Severityblocker
Prioritymedium
Component   libdrm
Assigneedri-devel@lists.freedesktop.org
Reporterissor.or...@gmail.com

Createdattachment 142809  [details] 
  [review]  

draft patch that solves the crashes

Hi,
there is a series of Android apps using 32bit libs on 64bit Android that are
crashing (Jackpal terminal, Sky Force, Olympus Rising, Vulkan V1, 3dmark
benchmarks and many others)

The cause is the difference in size of gralloc handle structs created by 32bit
libraries and 64bit architetures libraries.

The problem was observed and patched in gbm_gralloc in the past by Chih-Wei
Huang, but it was not taken into account in later evolution,
now with android/gralloc_handle.h in libdrm the problem is again present,
because the handle sizes in 32bit and 64bit are again different.

The attached draft patch solves the issue, tested on all apps that were
crashing
Please review and provide feedback

Mauro


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


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

[PATCH] sysfs: Disable lockdep for driver bind/unbind files

[Daniel Vetter]

This is the much more correct fix for my earlier attempt at:

https://lkml.org/lkml/2018/12/10/118

Short recap:

- There's not actually a locking issue, it's just lockdep being a bit
  too eager to complain about a possible deadlock.

- Contrary to what I claimed the real problem is recursion on
  kn->count. Greg pointed me at sysfs_break_active_protection(), used
  by the scsi subsystem to allow a sysfs file to unbind itself. That
  would be a real deadlock, which isn't what's happening here. Also,
  breaking the active protection means we'd need to manually handle
  all the lifetime fun.

- With Rafael we discussed the task_work approach, which kinda works,
  but has two downsides: It's a functional change for a lockdep
  annotation issue, and it won't work for the bind file (which needs
  to get the errno from the driver load function back to userspace).

- Greg also asked why this never showed up: To hit this you need to
  unregister a 2nd driver from the unload code of your first driver. I
  guess only gpus do that. The bug has always been there, but only
  with a recent patch series did we add more locks so that lockdep
  built a chain from unbinding the snd-hda driver to the
  acpi_video_unregister call.

Full lockdep splat:

[12301.898799] 
[12301.898805] WARNING: possible recursive locking detected
[12301.898811] 4.20.0-rc7+ #84 Not tainted
[12301.898815] 
[12301.898821] bash/5297 is trying to acquire lock:
[12301.898826] f61c6093 (kn->count#39){}, at: 
kernfs_remove_by_name_ns+0x3b/0x80
[12301.898841] but task is already holding lock:
[12301.898847] 5f634021 (kn->count#39){}, at: 
kernfs_fop_write+0xdc/0x190
[12301.898856] other info that might help us debug this:
[12301.898862]  Possible unsafe locking scenario:
[12301.898867]CPU0
[12301.898870]
[12301.898874]   lock(kn->count#39);
[12301.898879]   lock(kn->count#39);
[12301.898883] *** DEADLOCK ***
[12301.898891]  May be due to missing lock nesting notation
[12301.898899] 5 locks held by bash/5297:
[12301.898903]  #0: cd800e54 (sb_writers#4){.+.+}, at: 
vfs_write+0x17f/0x1b0
[12301.898915]  #1: 0465e7c2 (>mutex){+.+.}, at: 
kernfs_fop_write+0xd3/0x190
[12301.898925]  #2: 5f634021 (kn->count#39){}, at: 
kernfs_fop_write+0xdc/0x190
[12301.898936]  #3: 414ef7ac (>mutex){}, at: 
device_release_driver_internal+0x34/0x240
[12301.898950]  #4: 3218fbdf (register_count_mutex){+.+.}, at: 
acpi_video_unregister+0xe/0x40
[12301.898960] stack backtrace:
[12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
[12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 
68SCF Ver. F.01 03/11/2011
[12301.898982] Call Trace:
[12301.898989]  dump_stack+0x67/0x9b
[12301.898997]  __lock_acquire+0x6ad/0x1410
[12301.899003]  ? kernfs_remove_by_name_ns+0x3b/0x80
[12301.899010]  ? find_held_lock+0x2d/0x90
[12301.899017]  ? mutex_spin_on_owner+0xe4/0x150
[12301.899023]  ? find_held_lock+0x2d/0x90
[12301.899030]  ? lock_acquire+0x90/0x180
[12301.899036]  lock_acquire+0x90/0x180
[12301.899042]  ? kernfs_remove_by_name_ns+0x3b/0x80
[12301.899049]  __kernfs_remove+0x296/0x310
[12301.899055]  ? kernfs_remove_by_name_ns+0x3b/0x80
[12301.899060]  ? kernfs_name_hash+0xd/0x80
[12301.899066]  ? kernfs_find_ns+0x6c/0x100
[12301.899073]  kernfs_remove_by_name_ns+0x3b/0x80
[12301.899080]  bus_remove_driver+0x92/0xa0
[12301.899085]  acpi_video_unregister+0x24/0x40
[12301.899127]  i915_driver_unload+0x42/0x130 [i915]
[12301.899160]  i915_pci_remove+0x19/0x30 [i915]
[12301.899169]  pci_device_remove+0x36/0xb0
[12301.899176]  device_release_driver_internal+0x185/0x240
[12301.899183]  unbind_store+0xaf/0x180
[12301.899189]  kernfs_fop_write+0x104/0x190
[12301.899195]  __vfs_write+0x31/0x180
[12301.899203]  ? rcu_read_lock_sched_held+0x6f/0x80
[12301.899209]  ? rcu_sync_lockdep_assert+0x29/0x50
[12301.899216]  ? __sb_start_write+0x13c/0x1a0
[12301.899221]  ? vfs_write+0x17f/0x1b0
[12301.899227]  vfs_write+0xb9/0x1b0
[12301.899233]  ksys_write+0x50/0xc0
[12301.899239]  do_syscall_64+0x4b/0x180
[12301.899247]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[12301.899253] RIP: 0033:0x7f452ac7f7a4
[12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 
00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX: 
0001
[12301.899282] RAX: ffda RBX: 000d RCX: 7f452ac7f7a4
[12301.899288] RDX: 000d RSI: 5612a1abf7c0 RDI: 0001
[12301.899295] RBP: 5612a1abf7c0 R08: 000a R09: 5612a1c46730
[12301.899301] R10: 000a R11: 0246 R12: 000d
[12301.899308] R13: 0001 R14: 7f452af4a740 R15: 

Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent

[Noralf Trønnes]

Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:

From: Oleksandr Andrushchenko 

When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the backend always sees correct display
buffer content.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/gpu/drm/xen/xen_drm_front_gem.c | 62 +++--
  1 file changed, 48 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019d3aef..c592735e49d2 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -33,8 +33,11 @@ struct xen_gem_object {
/* set for buffers allocated by the backend */
bool be_alloc;
  
-	/* this is for imported PRIME buffer */

-   struct sg_table *sgt_imported;
+   /*
+* this is for imported PRIME buffer or the one allocated via
+* drm_gem_get_pages.
+*/
+   struct sg_table *sgt;
  };
  
  static inline struct xen_gem_object *

@@ -77,10 +80,21 @@ static struct xen_gem_object *gem_create_obj(struct 
drm_device *dev,
return xen_obj;
  }
  
+struct sg_table *xen_drm_front_gem_get_sg_table(struct drm_gem_object *gem_obj)

+{
+   struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
+
+   if (!xen_obj->pages)
+   return ERR_PTR(-ENOMEM);
+
+   return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
+}
+
  static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size)
  {
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
struct xen_gem_object *xen_obj;
+   struct address_space *mapping;
int ret;
  
  	size = round_up(size, PAGE_SIZE);

@@ -113,10 +127,14 @@ static struct xen_gem_object *gem_create(struct 
drm_device *dev, size_t size)
xen_obj->be_alloc = true;
return xen_obj;
}
+
/*
 * need to allocate backing pages now, so we can share those
 * with the backend
 */



Let's see if I understand what you're doing:

Here you say that the pages should be DMA accessible for devices that can
only see 4GB.


+   mapping = xen_obj->base.filp->f_mapping;
+   mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
+
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
if (IS_ERR_OR_NULL(xen_obj->pages)) {
@@ -125,8 +143,27 @@ static struct xen_gem_object *gem_create(struct drm_device 
*dev, size_t size)
goto fail;
}
  
+	xen_obj->sgt = xen_drm_front_gem_get_sg_table(_obj->base);

+   if (IS_ERR_OR_NULL(xen_obj->sgt)){
+   ret = PTR_ERR(xen_obj->sgt);
+   xen_obj->sgt = NULL;
+   goto fail_put_pages;
+   }
+
+   if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+   DMA_BIDIRECTIONAL)) {



Are you using the DMA streaming API as a way to flush the caches?
Does this mean that GFP_USER isn't making the buffer coherent?

Noralf.


+   ret = -EFAULT;
+   goto fail_free_sgt;
+   }
+
return xen_obj;
  
+fail_free_sgt:

+   sg_free_table(xen_obj->sgt);
+   xen_obj->sgt = NULL;
+fail_put_pages:
+   drm_gem_put_pages(_obj->base, xen_obj->pages, true, false);
+   xen_obj->pages = NULL;
  fail:
DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
return ERR_PTR(ret);
@@ -149,7 +186,7 @@ void xen_drm_front_gem_free_object_unlocked(struct 
drm_gem_object *gem_obj)
struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
  
  	if (xen_obj->base.import_attach) {

-   drm_prime_gem_destroy(_obj->base, xen_obj->sgt_imported);
+   drm_prime_gem_destroy(_obj->base, xen_obj->sgt);
gem_free_pages_array(xen_obj);
} else {
if (xen_obj->pages) {
@@ -158,6 +195,13 @@ void xen_drm_front_gem_free_object_unlocked(struct 
drm_gem_object *gem_obj)
xen_obj->pages);
gem_free_pages_array(xen_obj);
} else {
+   if (xen_obj->sgt) {
+   dma_unmap_sg(xen_obj->base.dev->dev,
+xen_obj->sgt->sgl,
+xen_obj->sgt->nents,
+DMA_BIDIRECTIONAL);
+   sg_free_table(xen_obj->sgt);
+   }

Re: [PATCH libdrm] libdrm: Fix drmNodeIsDRM() on DragonFly

[Francois Tigeot]

On Mon, Dec 17, 2018 at 06:09:47PM +, Emil Velikov wrote:
> On Tue, 11 Dec 2018 at 22:15, François Tigeot  wrote:
> >
> > * There is no way to check if a device name is really a drm device
> >   by looking it up in a virtual filesystem like on Linux
> >
> > * The major device number is also dynamically allocated from a pool,
> >   comparing it to a constant makes no sense
> >
> > * In the absence of better ideas, just assume the device name really
> >   points to a drm device and always return true
> >
> I guess one could use the sysfs path, although that may require a few
> extra lines to the linux emulation layer.

We currently have such a thing living in local patches and it's a source
of pain; it regularly breaks for one reason or another.
It's not using sysfs but a hw.dri sysctl mechanism originating from FreeBSD.
Some of the patches are visible here:
https://github.com/DragonFlyBSD/DPorts/blob/master/graphics/libdrm/files/patch-xf86drm.c

> What's the reason behind the dynamic allocation of the major? FWIW
> some userspace requires a fixed DRM_MAJOR - they will need patching to
> run :-(

Major/minor numbers were required when device files had to be created on
regular filesystem like UFS but when a devfs filesystem was implemented
for DragonFly almost a decade ago, nobody thought it was important anymore.

There have been no fixed major numbers on DragonFly since 2009 or so.

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

Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Doug Anderson]

Hi,

On Tue, Dec 18, 2018 at 10:40 AM Stephen Boyd  wrote:
>
> Quoting Doug Anderson (2018-12-17 16:34:31)
> > Hi,
> >
> > On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar  
> > wrote:
> > >
> > > +Rob +Stephen,
> > >
> > > On 14-12-18, 09:04, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar  
> > > > wrote:
> > > > >
> > > > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > > > + gpu_opp_table: opp-table {
> > > > > > + compatible = 
> > > > > > "operating-points-v2-qcom-level";
> > > > >
> > > > > I think you need to mention "operating-points-v2" as well here.
> > > >
> > > > Are you saying the above should be:
> > > >   compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> > > >
> > > > If so I'm not sure I agree.
> > >
> > > Well I have my doubts as well on this. This is where the ordering was 
> > > discussed
> > > earlier:
> > >
> > > https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
> > >
> > > @Rob/Stephen: Should the opp-table node above also have 
> > > "operating-points-v2"
> > > string in the compatible property ?
> > >
> > > > It's _not_ really compatible with the
> > > > "operating-points-v2" binding.  If you had a driver that had never
> > > > heard of "operating-points-v2-qcom-level" and had only heard of
> > > > "operating-points-v2" and it took a look at this node it would have no
> > > > idea what to do with it.
> > >
> > > Well it will parse everything apart from the qcom,level thing, so it can
> > > actually parse stuff here.
> > >
> > > > I'll also note that other instances posted to the list don't list both:
> > > >
> > > > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > > > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for 
> > > > sdm845
> > > >
> > > > The bindings patch also makes no mention of needing
> > > > "operating-points-v2".  I think the common case when a fallback is
> > > > required it is explicitly called out in the bindings:
> > > >
> > > > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
> > >
> > > Sure, maybe I am wrong but its better to get some clarity on it from 
> > > Rob/Stephen.
> >
> > In case it helps:
> >
> > https://lkml.kernel.org/r/20181217210849.GA15490@bogus
> >
> > ...shows Rob giving a Reviewed-by with just
> >
> >   compatible = "operating-points-v2-qcom-level";
> >
> > ...and not:
> >
> >   compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> >
>
> I don't see a problem if both compatible strings are there. Does that
> change anything? I suppose the platform bus populate code won't create a
> device for the subnode if it has 'operating-points-v2', so maybe the
> fallback compatible string should be there? And then the generic OPP
> code can parse out the frequency at least without having to know that
> it's a qcom specific OPP table.

OK, it's fine with me to have the fallback, but if we do we should be
consistent about it and make sure it's in all the bindings and device
tree files...

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

[v1] drm/msm/dpu: Remove unused enum and comment from dpu mdss

[Jayant Shekhar]

Remove enum dpu_iommu_domain from dpu mdss as its unused.

Remove unnecessary comment for variable which is already
removed.

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 68c54d2..1ab8d4a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -258,12 +258,6 @@ enum dpu_vbif {
VBIF_NRT = VBIF_1
 };
 
-enum dpu_iommu_domain {
-   DPU_IOMMU_DOMAIN_UNSECURE,
-   DPU_IOMMU_DOMAIN_SECURE,
-   DPU_IOMMU_DOMAIN_MAX
-};
-
 /**
  * DPU HW,Component order color map
  */
@@ -358,7 +352,6 @@ enum dpu_3d_blend_mode {
  * @alpha_enable: whether the format has an alpha channel
  * @num_planes: number of planes (including meta data planes)
  * @fetch_mode: linear, tiled, or ubwc hw fetch behavior
- * @is_yuv: is format a yuv variant
  * @flag: usage bit flags
  * @tile_width: format tile width
  * @tile_height: format tile height
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [Xen-devel][PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

[Oleksandr Andrushchenko]

On 12/18/18 20:31, Boris Ostrovsky wrote:

On 12/18/18 11:15 AM, Noralf Trønnes wrote:

Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:

From: Oleksandr Andrushchenko 

Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.

Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.

Signed-off-by: Oleksandr Andrushchenko

---

Reviewed-by: Noralf Trønnes 

Thank you, Noralf!


Now that all 3 have been acked/reviewed

Applied to for-linus-4.21

Thank you, Boris, Juergen!



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

Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Stephen Boyd]

Quoting Doug Anderson (2018-12-17 16:34:31)
> Hi,
> 
> On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar  wrote:
> >
> > +Rob +Stephen,
> >
> > On 14-12-18, 09:04, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar  
> > > wrote:
> > > >
> > > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > > + gpu_opp_table: opp-table {
> > > > > + compatible = 
> > > > > "operating-points-v2-qcom-level";
> > > >
> > > > I think you need to mention "operating-points-v2" as well here.
> > >
> > > Are you saying the above should be:
> > >   compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> > >
> > > If so I'm not sure I agree.
> >
> > Well I have my doubts as well on this. This is where the ordering was 
> > discussed
> > earlier:
> >
> > https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
> >
> > @Rob/Stephen: Should the opp-table node above also have 
> > "operating-points-v2"
> > string in the compatible property ?
> >
> > > It's _not_ really compatible with the
> > > "operating-points-v2" binding.  If you had a driver that had never
> > > heard of "operating-points-v2-qcom-level" and had only heard of
> > > "operating-points-v2" and it took a look at this node it would have no
> > > idea what to do with it.
> >
> > Well it will parse everything apart from the qcom,level thing, so it can
> > actually parse stuff here.
> >
> > > I'll also note that other instances posted to the list don't list both:
> > >
> > > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for 
> > > sdm845
> > >
> > > The bindings patch also makes no mention of needing
> > > "operating-points-v2".  I think the common case when a fallback is
> > > required it is explicitly called out in the bindings:
> > >
> > > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
> >
> > Sure, maybe I am wrong but its better to get some clarity on it from 
> > Rob/Stephen.
> 
> In case it helps:
> 
> https://lkml.kernel.org/r/20181217210849.GA15490@bogus
> 
> ...shows Rob giving a Reviewed-by with just
> 
>   compatible = "operating-points-v2-qcom-level";
> 
> ...and not:
> 
>   compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> 

I don't see a problem if both compatible strings are there. Does that
change anything? I suppose the platform bus populate code won't create a
device for the subnode if it has 'operating-points-v2', so maybe the
fallback compatible string should be there? And then the generic OPP
code can parse out the frequency at least without having to know that
it's a qcom specific OPP table.

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

[PATCH v7 5/6] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings

[Jordan Crouse]

Update the GPU bindings and document the new bindings for the GMU
device found with Adreno a6xx targets.

Signed-off-by: Jordan Crouse 
---

v7: Updated the GMU compatible string and clarified details about when clocks
can be optional on the GPU

 .../devicetree/bindings/display/msm/gmu.txt   | 59 +++
 .../devicetree/bindings/display/msm/gpu.txt   | 42 -
 2 files changed, 98 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..59e6865898f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,59 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible: "qcom,adreno-gmu-XYZ.W", "qcom,adreno-gmu"
+for example: "qcom,adreno-gmu-630.2", "qcom,adreno-gmu"
+  Note that you need to list the less specific "qcom,adreno-gmu"
+  for generic matches and the more specific identifier to identify
+  the specific device.
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+  * "gmu"
+  * "gmu_pdc"
+  * "gmu_pdc_seg"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+  * "hfi"
+  * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+   * "gmu"
+   * "cxo"
+   * "axi"
+   * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+   ...
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb28 0x1>,
+   <0xb48 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = < GPU_CC_CX_GMU_CLK>,
+   < GPU_CC_CXO_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>,
+   < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = < GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 4ad5e70e5c3e..9c89f4fdb8ca 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,14 +8,23 @@ Required properties:
   with the chip-id.
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+- clocks: device clocks (if applicable)
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks are required by a3xx, a4xx and a5xx
+  cores:
   * "core"
   * "iface"
   * "mem_iface"
+  For GMU attached devices the GPU clocks are not used and are not required. 
The
+  following devices should not list clocks:
+   - qcom,adreno-630.2
+- iommus: optional phandle to an adreno iommu instance
+- operating-points-v2: optional phandle to the OPP operating points
+- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
+  control the power for the GPU. Applicable targets:
+- qcom,adreno-630.2
 
-Example:
+Example 3xx/4xx/a5xx:
 
 / {
...
@@ -35,3 +44,30 @@ Example:
< MMSS_IMEM_AHB_CLK>;
};
 };
+
+Example a6xx (with GMU):
+
+/ {
+   ...
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>, <0x509e000 0x10>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+   interrupts = ;
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   qcom,gmu = <>;
+   };
+};
-- 
2.18.0

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

[PATCH v7 6/6] arm64: dts: sdm845: Add gpu and gmu device nodes

[Jordan Crouse]

Add the nodes to describe the Adreno GPU and GMU devices.

Signed-off-by: Jordan Crouse 
---

v7: Updated the GMU compatible string and removed interrupt-names

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 122 +++
 1 file changed, 122 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 233a5898ebc2..4779014e4a05 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1349,6 +1350,127 @@
};
};
 
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>, <0x509e000 0x10>;
+   reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+   interrupts = ;
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   qcom,gmu = <>;
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   opp-71000 {
+   opp-hz = /bits/ 64 <71000>;
+   qcom,level = 
;
+   };
+
+   opp-67500 {
+   opp-hz = /bits/ 64 <67500>;
+   qcom,level = 
;
+   };
+
+   opp-59600 {
+   opp-hz = /bits/ 64 <59600>;
+   qcom,level = 
;
+   };
+
+   opp-52000 {
+   opp-hz = /bits/ 64 <52000>;
+   qcom,level = ;
+   };
+
+   opp-41400 {
+   opp-hz = /bits/ 64 <41400>;
+   qcom,level = 
;
+   };
+
+   opp-34200 {
+   opp-hz = /bits/ 64 <34200>;
+   qcom,level = ;
+   };
+
+   opp-25700 {
+   opp-hz = /bits/ 64 <25700>;
+   qcom,level = 
;
+   };
+   };
+   };
+
+   adreno_smmu: iommu@504 {
+   compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+   reg = <0x504 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+   < GCC_GPU_CFG_AHB_CLK>;
+   clock-names = "bus", "iface";
+
+   power-domains = < GPU_CX_GDSC>;
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb28 0x1>,
+   <0xb48 0x1>;
+   reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = < GPU_CC_CX_GMU_CLK>,
+   < GPU_CC_CXO_CLK>,
+   < GCC_DDRSS_GPU_AXI_CLK>,
+   < GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = < GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+
+   gmu_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+

[PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Jordan Crouse]

Now that more of the sdm845 bindings are headed upstream this a refresh of
of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes
interrupt-names from the driver and the existing DT changes per feedback from
Rob Herring.

This is based on :
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next

with:
https://lore.kernel.org/patchwork/patch/1018365/

This change requires the following dependencies:

include/dt-bindings/power/qcom-rpmpd.h:
https://patchwork.kernel.org/patch/1079/

qcom,smmu-v2 binding:
https://patchwork.kernel.org/patch/10581911/

v7: Add patches to remove interrupt-names, add version specific compatible
string for gmu
v6: Update GPU bindings for a6xx and make the examples match the nodes and vice
 versa.  Clean up types and rebase on
 https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate merging.
v5: Use symbolic names for the RPMH power levels defined in OPP table,
 move the opp tables as children of their respective nodes and rename
 the iommu device.
v4: Rebase
v3: Split GMU PDC region into two GPU specific sections, fix indentation,
  really use qcom,gmu for the phandle name
v2: changed qcom,arc-level to qcom,level following discussion with Viresh;
  change gmu phandle to qcom,gmu per Rob

Jordan Crouse (6):
  drm/msm/gpu: Remove hardcoded interrupt name
  drm/msm: drop interrupt-names
  ARM: dts: qcom: Removed unused interrupt-names from GPU node
  arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU
  dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
  arm64: dts: sdm845: Add gpu and gmu device nodes

 .../devicetree/bindings/display/msm/gmu.txt   |  59 +
 .../devicetree/bindings/display/msm/gpu.txt   |  43 +-
 arch/arm/boot/dts/qcom-apq8064.dtsi   |   1 -
 arch/arm64/boot/dts/qcom/msm8916.dtsi |   1 -
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 122 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |   1 -
 drivers/gpu/drm/msm/msm_gpu.c |   2 +-
 drivers/gpu/drm/msm/msm_gpu.h |   1 -
 8 files changed, 221 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

-- 
2.18.0

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

[PATCH v7 1/6] drm/msm/gpu: Remove hardcoded interrupt name

[Jordan Crouse]

Every GPU core only has one interrupt so there isn't any
value in looking up the interrupt by name. Remove the name (which
is legacy anyway) and use platform_get_irq() instead.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
 drivers/gpu/drm/msm/msm_gpu.c   | 2 +-
 drivers/gpu/drm/msm/msm_gpu.h   | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 93d70f4a2154..bfeea50fca8a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -713,7 +713,6 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
adreno_gpu->rev = config->rev;
 
adreno_gpu_config.ioname = "kgsl_3d0_reg_memory";
-   adreno_gpu_config.irqname = "kgsl_3d0_irq";
 
adreno_gpu_config.va_start = SZ_16M;
adreno_gpu_config.va_end = 0x;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 11aac8337066..f9de09d14344 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -868,7 +868,7 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
}
 
/* Get Interrupt: */
-   gpu->irq = platform_get_irq_byname(pdev, config->irqname);
+   gpu->irq = platform_get_irq(pdev, 0);
if (gpu->irq < 0) {
ret = gpu->irq;
dev_err(drm->dev, "failed to get irq: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index f82bac08..fc4040e24a6b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -31,7 +31,6 @@ struct msm_gpu_state;
 
 struct msm_gpu_config {
const char *ioname;
-   const char *irqname;
uint64_t va_start;
uint64_t va_end;
unsigned int nr_rings;
-- 
2.18.0

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

[PATCH v7 4/6] arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU

[Jordan Crouse]

'interrupt-names' shouldn't be used in cases when there is only
one interrupt and it is not otherwise used in the driver.

Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c5348c3da5a2..846de1043e4d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -880,7 +880,6 @@
reg = <0x01c0 0x2>;
reg-names = "kgsl_3d0_reg_memory";
interrupts = ;
-   interrupt-names = "kgsl_3d0_irq";
clock-names =
"core",
"iface",
-- 
2.18.0

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

[PATCH v7 3/6] ARM: dts: qcom: Removed unused interrupt-names from GPU node

[Jordan Crouse]

'interrupt-names' shouldn't be used in cases when there is only
one interrupt and it is not otherwise used in the driver.

Signed-off-by: Jordan Crouse 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 48c3cf427610..0a9862729c80 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1186,7 +1186,6 @@
reg = <0x0430 0x2>;
reg-names = "kgsl_3d0_reg_memory";
interrupts = ;
-   interrupt-names = "kgsl_3d0_irq";
clock-names =
"core_clk",
"iface_clk",
-- 
2.18.0

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

[PATCH v7 2/6] drm/msm: drop interrupt-names

[Jordan Crouse]

Each GPU core only uses one interrupt so we don't to look up
an interrupt by name and thereby we don't need interrupt-names.

Signed-off-by: Jordan Crouse 
---
 Documentation/devicetree/bindings/display/msm/gpu.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..4ad5e70e5c3e 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -25,7 +25,6 @@ Example:
reg = <0x0430 0x2>;
reg-names = "kgsl_3d0_reg_memory";
interrupts = ;
-   interrupt-names = "kgsl_3d0_irq";
clock-names =
"core",
"iface",
-- 
2.18.0

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

[PATCH] drm/msm: Unblock writer if reader closes file

[Kristian H. Kristensen]

Prevents deadlock when fifo is full and reader closes file.

Signed-off-by: Kristian H. Kristensen 
---
 drivers/gpu/drm/msm/msm_rd.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index b5672061ae085..d990b5f5154cf 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -115,7 +115,9 @@ static void rd_write(struct msm_rd_state *rd, const void 
*buf, int sz)
char *fptr = >buf[fifo->head];
int n;
 
-   wait_event(rd->fifo_event, circ_space(>fifo) > 0);
+   wait_event(rd->fifo_event, circ_space(>fifo) > 0 || 
!rd->open);
+   if (!rd->open)
+   return;
 
/* Note that smp_load_acquire() is not strictly required
 * as CIRC_SPACE_TO_END() does not access the tail more
@@ -213,7 +215,10 @@ static int rd_open(struct inode *inode, struct file *file)
 static int rd_release(struct inode *inode, struct file *file)
 {
struct msm_rd_state *rd = inode->i_private;
+
rd->open = false;
+   wake_up_all(>fifo_event);
+
return 0;
 }
 
-- 
2.20.0.405.gbc1bbc6f85-goog

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

Re: [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset

[Rodrigo Vivi]

On Tue, Dec 18, 2018 at 05:07:34PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 17-12-18 19:43, Rodrigo Vivi wrote:
> > On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
> > > Hi All,
> > > 
> > > As discussed a while ago, I would like to see us enable fastboot by
> > > default, starting with Skylake / GEN9 and newer hardware, so that we can
> > > avoid an unnecessary modeset at boot and move to a truely flickerfree 
> > > boot.
> > > 
> > > During our previous discussion about this Maarten mentioned that a first
> > > step would be to get this patch from him upstream. So I'm hereby
> > > resubmitting it, with a small fix. Hopefully the CI will like it better
> > > this time (if not we will need to investigate) and once this passes CI
> > > I hope this can be reviewed quickly and we can get this upstream.
> > 
> > I honestly believe the first step is to make sure FBC, PSR, DRRS features > 
> > gets enabled somehow with fastboot.
> 
> That is a good point, FBC will already be enabled on a fastboot as
> intel_update_crtc does:
> 
> if (new_plane_state)
> intel_fbc_enable(intel_crtc, pipe_config, new_plane_state);

oh cool!

> 
> Independent of need_modeset() returning true.
> 
> PSR indeed stays off, even if i915.enable_psr=1 is passed on the kernel
> commandline. I've just completed writing a patch-set (2 patches) fixing
> this. I will submit these upstream soon.

cool, thanks!

> 
> DRRS seems to be the same as PSR (I don't have hw to test) I will also
> submit 2 patches building on top of the previous 2 which should fix this,
> we already allow runtime enabling/disabling through i915_drrs_ctl in
> debugfs, so these 2 patches should be fine.

yeap, I think so

> 
> 
> > Maybe DSC as well?!
> 
> DSC? :

VESA's Display Stream Compression

> 
> [hans@shalem linux]$ grep -r dsc  drivers/gpu/drm/i915
> [hans@shalem linux]$

*** intel_ddi.c:
intel_ddi_pre_enable_dp[3211]  intel_dsc_enable(encoder, crtc_state);

*** intel_vdsc.c:
intel_dsc_enable[1018] void intel_dsc_enable(struct intel_encoder 
*encoder,

> 
> > Right now as I can remember FBC, PSR, and DRRS will get disabled if fastboot
> > is used because we just enable those when enabling the pipe.
> 
> You're right for PSR and DRRS, as Maarten just found out FBC has the
> opposite problem, we don't turn it off on a fastset when it was enabled and we
> decide it should no longer be enabled.
> 
> Regards,
> 
> Hans
> 

Thanks a lot for this work,
Rodrigo.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Jordan Crouse]

On Tue, Dec 18, 2018 at 11:22:01AM -0600, Rob Herring wrote:
> On Fri, Dec 14, 2018 at 03:16:39PM -0700, Jordan Crouse wrote:
> > Add documentation for the interconnect and interconnect-names bindings
> > for the GPU node as detailed by bindings/interconnect/interconnect.txt.
> > 
> > Signed-off-by: Jordan Crouse 
> > ---
> >  Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> > b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > index 8d9415180c22..19b5ae459fdb 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > @@ -19,6 +19,9 @@ Required properties:
> >* "mem_iface"
> >  - iommus: optional phandle to an adreno iommu instance
> >  - operating-points-v2: optional phandle to the OPP operating points
> > +- interconnect: optional phandle to a interconnect provider.  See
> > +  ../interconnect/interconnect.txt for details.
> > +- interconnect-names: Name string for the interconnects.
> >  - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that 
> > will
> >control the power for the GPU
> >  
> > @@ -68,6 +71,9 @@ Example a6xx (with GMU):
> >  
> > operating-points-v2 = <_opp_table>;
> >  
> > +   interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
> > +   interconnect-names = "gfx-mem";
> 
> There's not really any point to having *-names when there is only 1 
> value.

For the moment we can only look up the path from the DT by name. I guess we
could add an lookup by index but I'm not sure if that had already been
considered and rejected.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Rob Herring]

On Fri, Dec 14, 2018 at 03:16:39PM -0700, Jordan Crouse wrote:
> Add documentation for the interconnect and interconnect-names bindings
> for the GPU node as detailed by bindings/interconnect/interconnect.txt.
> 
> Signed-off-by: Jordan Crouse 
> ---
>  Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> b/Documentation/devicetree/bindings/display/msm/gpu.txt
> index 8d9415180c22..19b5ae459fdb 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> @@ -19,6 +19,9 @@ Required properties:
>* "mem_iface"
>  - iommus: optional phandle to an adreno iommu instance
>  - operating-points-v2: optional phandle to the OPP operating points
> +- interconnect: optional phandle to a interconnect provider.  See
> +  ../interconnect/interconnect.txt for details.
> +- interconnect-names: Name string for the interconnects.
>  - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
>control the power for the GPU
>  
> @@ -68,6 +71,9 @@ Example a6xx (with GMU):
>  
>   operating-points-v2 = <_opp_table>;
>  
> + interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
> + interconnect-names = "gfx-mem";

There's not really any point to having *-names when there is only 1 
value.

> +
>   qcom,gmu = <>;
>   };
>  };
> -- 
> 2.18.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] video: lcd: Remove useless BACKLIGHT_LCD_SUPPORT kernel symbol

[Daniel Thompson]

On Sun, Dec 16, 2018 at 08:02:46AM +0300, Alexander Shiyan wrote:
> Symbol BACKLIGHT_LCD_SUPPORT affecting anything, except enabling
> the backlight & LCD Kconfig menu. The patch removes this symbol as
> useless and converts it into a menu.

Something bothered me about the patch but I think its the lack of
explanation in the patch header about *why* we don't use/need/want
BACKLIGHT_LCD_SUPPORT.

Essentially the reason BACKLIGHT_LCD_SUPPORT is useless is that we have
two _CLASS_DEVICE configs (LCD_CLASS_DEVICE and BACKLIGHT_LCD_DEVICE)
that do the same job (ad that do have code attached to them).

It would be good to mention that in the patch header.


Daniel.

> 
> Signed-off-by: Alexander Shiyan 
> ---
>  arch/unicore32/Kconfig|  1 -
>  drivers/gpu/drm/Kconfig   |  2 --
>  drivers/gpu/drm/bridge/Kconfig|  1 -
>  drivers/gpu/drm/fsl-dcu/Kconfig   |  1 -
>  drivers/gpu/drm/i915/Kconfig  |  1 -
>  drivers/gpu/drm/nouveau/Kconfig   |  1 -
>  drivers/gpu/drm/shmobile/Kconfig  |  1 -
>  drivers/gpu/drm/tilcdc/Kconfig|  1 -
>  drivers/staging/olpc_dcon/Kconfig |  1 -
>  drivers/usb/misc/Kconfig  |  1 -
>  drivers/video/backlight/Kconfig   | 10 ++
>  drivers/video/fbdev/Kconfig   |  5 -
>  12 files changed, 2 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index a4c0515..afeea3d 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -211,7 +211,6 @@ config I2C_EEPROM_AT24
>  
>  config LCD_BACKLIGHT
>   tristate "LCD Backlight support"
> - select BACKLIGHT_LCD_SUPPORT
>   select BACKLIGHT_PWM
>  
>  endmenu
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 4385f00..ef442a7 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -198,7 +198,6 @@ config DRM_RADEON
>   select POWER_SUPPLY
>   select HWMON
>   select BACKLIGHT_CLASS_DEVICE
> - select BACKLIGHT_LCD_SUPPORT
>   select INTERVAL_TREE
>   help
> Choose this option if you have an ATI Radeon graphics card.  There
> @@ -219,7 +218,6 @@ config DRM_AMDGPU
>   select POWER_SUPPLY
>   select HWMON
>   select BACKLIGHT_CLASS_DEVICE
> - select BACKLIGHT_LCD_SUPPORT
>   select INTERVAL_TREE
>   select CHASH
>   help
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 9eeb8ef..0f724e2 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -75,7 +75,6 @@ config DRM_PARADE_PS8622
>   depends on OF
>   select DRM_PANEL
>   select DRM_KMS_HELPER
> - select BACKLIGHT_LCD_SUPPORT
>   select BACKLIGHT_CLASS_DEVICE
>   ---help---
> Parade eDP-LVDS bridge chip driver.
> diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig
> index 14a72c4..dc82588 100644
> --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> @@ -2,7 +2,6 @@ config DRM_FSL_DCU
>   tristate "DRM Support for Freescale DCU"
>   depends on DRM && OF && ARM && COMMON_CLK
>   select BACKLIGHT_CLASS_DEVICE
> - select BACKLIGHT_LCD_SUPPORT
>   select DRM_KMS_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_PANEL
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 33a458b..90d406e73 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -15,7 +15,6 @@ config DRM_I915
>   select IRQ_WORK
>   # i915 depends on ACPI_VIDEO when ACPI is enabled
>   # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> - select BACKLIGHT_LCD_SUPPORT if ACPI
>   select BACKLIGHT_CLASS_DEVICE if ACPI
>   select INPUT if ACPI
>   select ACPI_VIDEO if ACPI
> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
> index 4b75ad40..a0238bf 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -11,7 +11,6 @@ config DRM_NOUVEAU
>   select MXM_WMI if ACPI && X86
>   select POWER_SUPPLY
>   # Similar to i915, we need to select ACPI_VIDEO and it's dependencies
> - select BACKLIGHT_LCD_SUPPORT if ACPI && X86
>   select BACKLIGHT_CLASS_DEVICE if ACPI && X86
>   select INPUT if ACPI && X86
>   select THERMAL if ACPI && X86
> diff --git a/drivers/gpu/drm/shmobile/Kconfig 
> b/drivers/gpu/drm/shmobile/Kconfig
> index 61bbe8e..e2a6c82 100644
> --- a/drivers/gpu/drm/shmobile/Kconfig
> +++ b/drivers/gpu/drm/shmobile/Kconfig
> @@ -4,7 +4,6 @@ config DRM_SHMOBILE
>   depends on DRM && ARM
>   depends on ARCH_SHMOBILE || COMPILE_TEST
>   select BACKLIGHT_CLASS_DEVICE
> - select BACKLIGHT_LCD_SUPPORT
>   select DRM_KMS_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_GEM_CMA_HELPER
> diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
> index 5259804..cb7df20 100644
> --- 

Re: [Freedreno] [v1] drm/msm/dpu: Cleanup dpu plane interface

[Jordan Crouse]

On Tue, Dec 18, 2018 at 06:50:38PM +0530, Jayant Shekhar wrote:
> Remove unused functions from dpu plane interface
> and unused variables from dpu plane state structure.
> 
> Signed-off-by: Jayant Shekhar 

Reviewed-by: Jordan Crouse 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 27 ---
>  1 file changed, 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> index 7fed0b6..0e6063a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> @@ -28,23 +28,18 @@
>  /**
>   * struct dpu_plane_state: Define dpu extension of drm plane state object
>   * @base:base drm plane state object
> - * @property_state: Local storage for msm_prop properties
> - * @property_values: cached plane property values
>   * @aspace:  pointer to address space for input/output buffers
> - * @input_fence: dereferenced input fence pointer
>   * @stage:   assigned by crtc blender
>   * @multirect_index: index of the rectangle of SSPP
>   * @multirect_mode: parallel or time multiplex multirect mode
>   * @pending: whether the current update is still pending
>   * @scaler3_cfg: configuration data for scaler3
>   * @pixel_ext: configuration data for pixel extensions
> - * @scaler_check_state: indicates status of user provided pixel extension 
> data
>   * @cdp_cfg: CDP configuration
>   */
>  struct dpu_plane_state {
>   struct drm_plane_state base;
>   struct msm_gem_address_space *aspace;
> - void *input_fence;
>   enum dpu_stage stage;
>   uint32_t multirect_index;
>   uint32_t multirect_mode;
> @@ -107,12 +102,6 @@ void dpu_plane_get_ctl_flush(struct drm_plane *plane, 
> struct dpu_hw_ctl *ctl,
>  void dpu_plane_flush(struct drm_plane *plane);
>  
>  /**
> - * dpu_plane_kickoff - final plane operations before commit kickoff
> - * @plane: Pointer to drm plane structure
> - */
> -void dpu_plane_kickoff(struct drm_plane *plane);
> -
> -/**
>   * dpu_plane_set_error: enable/disable error condition
>   * @plane: pointer to drm_plane structure
>   */
> @@ -147,14 +136,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
>  void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state);
>  
>  /**
> - * dpu_plane_wait_input_fence - wait for input fence object
> - * @plane:   Pointer to DRM plane object
> - * @wait_ms: Wait timeout value
> - * Returns: Zero on success
> - */
> -int dpu_plane_wait_input_fence(struct drm_plane *plane, uint32_t wait_ms);
> -
> -/**
>   * dpu_plane_color_fill - enables color fill on plane
>   * @plane:  Pointer to DRM plane object
>   * @color:  RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
> @@ -164,12 +145,4 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
>  int dpu_plane_color_fill(struct drm_plane *plane,
>   uint32_t color, uint32_t alpha);
>  
> -/**
> - * dpu_plane_set_revalidate - sets revalidate flag which forces a full
> - *   validation of the plane properties in the next atomic check
> - * @plane: Pointer to DRM plane object
> - * @enable: Boolean to set/unset the flag
> - */
> -void dpu_plane_set_revalidate(struct drm_plane *plane, bool enable);
> -
>  #endif /* _DPU_PLANE_H_ */
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #36 from Shmerl  ---
(In reply to Jerry Zuo from comment #35)
> "startup monitor sleep regression". Please give more details on that. Thanks.

This behavior used to happen in the previous kernerls but got fixed at one
point. Now it's back.

Basically, after GRUB, the system boots (I usually enable loglevel=4 to see
system output), but right before reaching graphical login (sddm in my case),
the monitor simply switched to sleep mode. To work around it, I have to:

1. Turn the monitor off and on.
2. Switch to tty1, and restart sddm from there.

This enables graphical login.

-- 
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: [Xen-devel][PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

[Noralf Trønnes]

Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:

From: Oleksandr Andrushchenko 

Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.

Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.

Signed-off-by: Oleksandr Andrushchenko 
---


Reviewed-by: Noralf Trønnes 

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

Re: [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset

[Hans de Goede]

Hi,

On 17-12-18 19:43, Rodrigo Vivi wrote:

On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:

Hi All,

As discussed a while ago, I would like to see us enable fastboot by
default, starting with Skylake / GEN9 and newer hardware, so that we can
avoid an unnecessary modeset at boot and move to a truely flickerfree boot.

During our previous discussion about this Maarten mentioned that a first
step would be to get this patch from him upstream. So I'm hereby
resubmitting it, with a small fix. Hopefully the CI will like it better
this time (if not we will need to investigate) and once this passes CI
I hope this can be reviewed quickly and we can get this upstream.


I honestly believe the first step is to make sure FBC, PSR, DRRS features > 
gets enabled somehow with fastboot.


That is a good point, FBC will already be enabled on a fastboot as
intel_update_crtc does:

if (new_plane_state)
intel_fbc_enable(intel_crtc, pipe_config, new_plane_state);

Independent of need_modeset() returning true.

PSR indeed stays off, even if i915.enable_psr=1 is passed on the kernel
commandline. I've just completed writing a patch-set (2 patches) fixing
this. I will submit these upstream soon.

DRRS seems to be the same as PSR (I don't have hw to test) I will also
submit 2 patches building on top of the previous 2 which should fix this,
we already allow runtime enabling/disabling through i915_drrs_ctl in
debugfs, so these 2 patches should be fine.



Maybe DSC as well?!


DSC? :

[hans@shalem linux]$ grep -r dsc  drivers/gpu/drm/i915
[hans@shalem linux]$


Right now as I can remember FBC, PSR, and DRRS will get disabled if fastboot
is used because we just enable those when enabling the pipe.


You're right for PSR and DRRS, as Maarten just found out FBC has the
opposite problem, we don't turn it off on a fastset when it was enabled and we
decide it should no longer be enabled.

Regards,

Hans

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

Re: [PATCH] drm/i915: Update crtc scaler settings when update_pipe is set

[Hans de Goede]

Hi,

On 18-12-18 12:07, Maarten Lankhorst wrote:

Op 17-12-2018 om 15:19 schreef Hans de Goede:

When the pipe_config's update_pipe flag is set we may need to update the
panel fitting settings. On GEN9+ this means we need to update the crtc's
scaler settings.

This fixes the following WARN_ON, during i915 loading on an Asrock
B150M Pro4S/D3 board with an i5-6500 CPU / graphics:

[drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
  (expected no, found yes)
pipe state doesn't match!
WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084

With line 12084 being the I915_STATE_WARN call inside the
"if (!intel_pipe_config_compare())" block in verify_crtc_state().

On this board with 2 1920x1080 monitors connected over HDMI the GOP
initializes both monitors at 1920x1080 and despite no scaling being
necessary configures a scaler for one of them.

When booting with fastboot=1 on the initial modeset needs_modeset will
be false while update_pipe is true. Since we were not calling
skl_update_scaler_crtc() in this case we would leave the scaler enabled
causing this error.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62df34d30b1f..df32626e0810 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10919,7 +10919,7 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
}
  
  	if (INTEL_GEN(dev_priv) >= 9) {

-   if (mode_changed)
+   if (mode_changed || pipe_config->update_pipe)
ret = skl_update_scaler_crtc(pipe_config);
  
  		if (!ret)


Hey,

Pushed.


Thank you.


You might also be interested in this patch / series, would be nice to have a 
review on it.

https://patchwork.freedesktop.org/patch/268410/


I don't feel comfortable reviewing the backlight patch, and the last patch in 
the
series, which unconditionally enables fastset seems a bit controversial.

IMHO it would be better to start with a patch which just enables this for GEN9+
(and valleyview and cherryview (*)).

It would be interesting to see what the CI thinks of just patches 1-4, with the 
last
one dropped.

The 2 other patches look good to me, I will reply to them with my Reviewed-by.

Regards,

Hans


*) As a side / hobby project I've been doing hw-enablement for Bay and Cherry 
Trail, as
such I've a ton of devices and I always run with fastboot=1 so I'm confident 
that it is
fine there,\ actually I've 2 devices where the LCD panel will not lightup with 
fastboot=0
(I've debugged this but failed to come up with anything useful).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/gem: Mark pinned pages as unevictable

[Kuo-Hsin Yang]

On Tue, Dec 18, 2018 at 9:55 PM Chris Wilson  wrote:
>
> Quoting Kuo-Hsin Yang (2018-12-17 09:04:01)
> >
> > E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If
> > active_anon / inactive_anon < 5 and all pages in the inactive_anon lru
> > are pinned, page reclaim would keep scanning inactive_anon lru without
> > reclaiming memory. It breaks page reclaim when the rockchip driver only
> > pins about 1/6 of the anon lru pages.
>
> Right, we invalidate the "inactive anon list should be small enough that
> the VM never has to do too much work" assumption.
>
> > Mark these pinned pages as unevictable to avoid the premature oom-killer
> > invocation. See also similar patch on i915 driver [1].
> >
> > [1]: 
> > https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
> >
> > Signed-off-by: Kuo-Hsin Yang 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 

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

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

[bugzilla-daemon]

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

--- Comment #35 from Jerry Zuo  ---
"startup monitor sleep regression". Please give more details on that. Thanks.

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

[RFC 2/3] drm/i915: Move on the new pm runtime interface

[Vincent Guittot]

Use the new pm runtime interface to get the accounted suspended time:
pm_runtime_accounted_time_get()

Signed-off-by: Vincent Guittot 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d6c8f8f..ebc49ea 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include "i915_pmu.h"
 #include "intel_ringbuffer.h"
 #include "i915_drv.h"
@@ -478,7 +479,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
 * counter value.
 */
spin_lock_irqsave(>pmu.lock, flags);
-   spin_lock(>power.lock);
 
/*
 * After the above branch intel_runtime_pm_get_if_in_use failed
@@ -491,16 +491,15 @@ static u64 get_rc6(struct drm_i915_private *i915)
 * suspended and if not we cannot do better than report the last
 * known RC6 value.
 */
-   if (kdev->power.runtime_status == RPM_SUSPENDED) {
+   val = pm_runtime_accounted_time_get(kdev, RPM_SUSPENDED, true);
+   if (pm_runtime_status_suspended(kdev)) {
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
-   i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+   i915->pmu.suspended_time_last =
+   pm_runtime_accounted_time_get(kdev,
+ 
RPM_SUSPENDED,
+ false);
 
-   val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
-   val += jiffies - kdev->power.accounting_timestamp;
-
-   val = jiffies_to_nsecs(val);
+   val -= i915->pmu.suspended_time_last;
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
 
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
@@ -510,7 +509,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
}
 
-   spin_unlock(>power.lock);
spin_unlock_irqrestore(>pmu.lock, flags);
}
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 7f164ca..3dc2a30 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -95,9 +95,9 @@ struct i915_pmu {
 */
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
/**
-* @suspended_jiffies_last: Cached suspend time from PM core.
+* @suspended_time_last: Cached suspend time from PM core.
 */
-   unsigned long suspended_jiffies_last;
+   u64 suspended_time_last;
/**
 * @i915_attr: Memory block holding device attributes.
 */
-- 
2.7.4

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

[PATCH 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

[Vincent Guittot]

From: Thara Gopinath 

This patch replaces jiffies based accounting for runtime_active_time
and runtime_suspended_time with ktime base accounting. This makes the
runtime debug counters inline with genpd and other pm subsytems which
uses ktime based accounting.

Signed-off-by: Thara Gopinath 
[move from ktime to raw nsec]
Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 10 +-
 drivers/base/power/sysfs.c   | 11 ---
 include/linux/pm.h   |  6 +++---
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 6461469..5c18e28 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
  */
 void update_pm_runtime_accounting(struct device *dev)
 {
-   unsigned long now = jiffies;
-   unsigned long delta;
+   u64 now = ktime_to_ns(ktime_get());
+   u64 delta;
 
delta = now - dev->power.accounting_timestamp;
 
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
 
if (dev->power.runtime_status == RPM_SUSPENDED)
-   dev->power.suspended_jiffies += delta;
+   dev->power.suspended_time += delta;
else
-   dev->power.active_jiffies += delta;
+   dev->power.active_time += delta;
 }
 
 static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -1517,7 +1517,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
-   dev->power.accounting_timestamp = jiffies;
+   dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
INIT_WORK(>power.work, pm_runtime_work);
 
dev->power.timer_expires = 0;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+   tmp = dev->power.active_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device 
*dev,
struct device_attribute *attr, char *buf)
 {
int ret;
+   u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
-   ret = sprintf(buf, "%i\n",
-   jiffies_to_msecs(dev->power.suspended_jiffies));
+   tmp = dev->power.suspended_time;
+   do_div(tmp, NSEC_PER_MSEC);
+   ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
 }
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
-   unsigned long   active_jiffies;
-   unsigned long   suspended_jiffies;
-   unsigned long   accounting_timestamp;
+   u64 active_time;
+   u64 suspended_time;
+   u64 accounting_timestamp;
 #endif
struct pm_subsys_data   *subsys_data;  /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
-- 
2.7.4

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

[RFC v3 1/3] PM/runtime: Add a new interface to get accounted time

[Vincent Guittot]

Some drivers (like i915/drm) need to get the accounted suspended time.
pm_runtime_accounted_time_get() will return the suspended or active
accounted time until now.

Signed-off-by: Vincent Guittot 
---
 drivers/base/power/runtime.c | 26 ++
 include/linux/pm_runtime.h   |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 7062469..6461469 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev, enum 
rpm_status status)
dev->power.runtime_status = status;
 }
 
+u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status status, 
bool update)
+{
+   u64 now = ktime_to_ns(ktime_get());
+   u64 delta = 0, time = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(>power.lock, flags);
+
+   if (dev->power.disable_depth > 0)
+   goto unlock;
+
+   /* Add ongoing state  if requested */
+   if (update && dev->power.runtime_status == status)
+   delta = now - dev->power.accounting_timestamp;
+
+   if (status == RPM_SUSPENDED)
+   time = dev->power.suspended_time + delta;
+   else
+   time = dev->power.active_time + delta;
+
+unlock:
+   spin_unlock_irqrestore(>power.lock, flags);
+
+   return time;
+}
+
 /**
  * pm_runtime_deactivate_timer - Deactivate given device's suspend timer.
  * @dev: Device to handle.
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 54af4ee..86f21f9 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -113,6 +113,8 @@ static inline bool pm_runtime_is_irq_safe(struct device 
*dev)
return dev->power.irq_safe;
 }
 
+extern u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status 
status, bool update);
+
 #else /* !CONFIG_PM */
 
 static inline bool queue_pm_work(struct work_struct *work) { return false; }
-- 
2.7.4

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

[PATCH v3 0/3] Move pm_runtime accounted time to raw nsec

[Vincent Guittot]

Move pm_runtime accounted time to raw nsec. The subject of the patchset
has changed as the 1st patch has been queued by Rafael

Patch 1 adds a new pm_runtime interface to get accounted suspended time

Patch 2 moves drm/i915 driver on the new interface and removes access to 
internal
fields

Patch 3 moves time accounting on raw ns. This patch initially used
ktime instead of raw ns but it was easier to move i915 driver on raw ns
than on ktim

Changes since v2:
- remove patch1 that has been queued by rafael
- add new interface in pm_runtime to get accounted time
- reorder patchset to prevent compilation error

Changes since v1:
- updated commit message of patch 1
- Added patches 2 & 3 to move runtime_pm accounting on raw ns
  
Thara Gopinath (1):
  PM/runtime:Replace jiffies based accounting with ktime based
accounting

Vincent Guittot (2):
  PM/runtime: Add a new interface to get accounted time
  drm/i915: Move on the new pm runtime interface

 drivers/base/power/runtime.c| 36 +++-
 drivers/base/power/sysfs.c  | 11 ---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/i915_pmu.h |  4 ++--
 include/linux/pm.h  |  6 +++---
 include/linux/pm_runtime.h  |  2 ++
 6 files changed, 54 insertions(+), 23 deletions(-)

-- 
2.7.4

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

[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in

[bugzilla-daemon]

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

--- Comment #5 from fin4...@hotmail.com ---
Use latest AMd wip kernel, firmware files and Oibaf ppa.
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

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

Re: [PATCH v4 2/2] drm/i915: Validate userspace-provided color management LUT's (v3)

[Ville Syrjälä]

On Mon, Dec 17, 2018 at 02:44:15PM -0800, Matt Roper wrote:
> We currently program userspace-provided gamma and degamma LUT's into our
> hardware without really checking to see whether they satisfy our
> hardware's rules.  We should try to catch tables that are invalid for
> our hardware early and reject the atomic transaction.
> 
> All of our platforms that accept a degamma LUT expect that the entries
> in the LUT are always flat or increasing, never decreasing.  Also, our
> GLK and ICL platforms only accept degamma tables with r=g=b entries; so
> we should also add the relevant checks for that in anticipation of
> degamma support landing for those platforms.
> 
> v2:
>  - Use new API (single check function with bitmask of tests to apply)
>  - Call helper for our gamma table as well (with no additional tests
>specified) so that the table size will be validated.
> 
> v3:
>  - Don't call on the gamma table since the LUT size is already tested at
>property blob upload and we don't have any additional hardware
>constraints for that LUT.
> 
> Cc: Uma Shankar 
> Cc: Swati Sharma 
> Signed-off-by: Matt Roper 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_color.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index 37fd9ddf762e..bdbe474ad9b2 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>   size_t gamma_length, degamma_length;
> + uint32_t tests = DRM_COLOR_LUT_NON_DECREASING;
>  
>   degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>   gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>  
> + /*
> +  * All of our platforms mandate that the degamma curve be
> +  * non-decreasing.  Additionally, GLK and gen11 only accept a single
> +  * value for red, green, and blue in the degamma table.  Make sure
> +  * userspace didn't try to pass us something we can't handle.
> +  *
> +  * We don't have any extra hardware constraints on the gamma table,
> +  * so no need to explicitly check it.
> +  */
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> + tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;

 >= 10 ?

> +
> + if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
> + return -EINVAL;
> +
>   /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
> -- 
> 2.14.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v2] drm/gem: Mark pinned pages as unevictable

[Chris Wilson]

Quoting Kuo-Hsin Yang (2018-12-17 09:04:01)
> The gem drivers use shmemfs to allocate backing storage for gem objects.
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
> to pin a lot of pages, breaking the page reclaim mechanism and causing
> oom-killer invocation.
> 
> E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If
> active_anon / inactive_anon < 5 and all pages in the inactive_anon lru
> are pinned, page reclaim would keep scanning inactive_anon lru without
> reclaiming memory. It breaks page reclaim when the rockchip driver only
> pins about 1/6 of the anon lru pages.

Right, we invalidate the "inactive anon list should be small enough that
the VM never has to do too much work" assumption.
 
> Mark these pinned pages as unevictable to avoid the premature oom-killer
> invocation. See also similar patch on i915 driver [1].
> 
> [1]: 
> https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
> 
> Signed-off-by: Kuo-Hsin Yang 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v2 4/8] drm/bridge: dw-hdmi: add support for YUV420 output

[Andrzej Hajda]

On 30.11.2018 14:42, Neil Armstrong wrote:
> In order to support the HDMI2.0 YUV420 display modes, this patch
> adds support for the YUV420 TMDS Clock divided by 2 and the controller
> passthrough mode.
>
> YUV420 Synopsys PHY support will need some specific configuration table
> to support theses modes.
>
> This patch is based on work from Zheng Yang  in
> the Rockchip Linux 4.4 BSP at [1]
>
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
>
> Cc: Zheng Yang 
> Signed-off-by: Neil Armstrong 


Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej


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

Re: [PATCH v2 -next] staging: fbtft: use strcmp() instead of strncmp() for

[Dan Carpenter]

On Tue, Dec 18, 2018 at 09:25:08PM +0800, YueHaibing wrote:
> strncmp() stops comparing when either the end of one of the first two 
> arguments is reached or when 'n' characters have been compared, whichever
> comes first.That means that strncmp(s1, s2, n) is equivalent to 
> strcmp(s1, s2) if n exceeds the length of s1 or the length of s2.
> 
> This patch avoids that the following warning is reported by smatch:
> 
> drivers/staging/fbtft/fbtft_device.c:1458
>  fbtft_device_init() error: strncmp() '"list"' too small (5 vs 32)
> 
> Signed-off-by: YueHaibing 
> ---
> v2: fix patch title

v2 is worse than v1...

v1 is a little long but I wouldn't have complained about it.

Please assume that the subject and the commit message are separate
things.  Take a look how the patch description reads on marc.info:

https://marc.info/?l=linux-driver-devel=154513957719226=2

regards,
dan carpenter

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

[PATCH 5/7] drm: sti: Delete base.id prints

[Shayenne Moura]

This patch removes base.id prints from drm_display_mode 
objects in sti files. It removes dependency from drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/sti/sti_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index ed76e52eb213..ab7989bc8fa0 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -53,9 +53,9 @@ sti_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
struct clk *compo_clk, *pix_clk;
int rate = mode->clock * 1000;
 
-   DRM_DEBUG_KMS("CRTC:%d (%s) mode:%d (%s)\n",
+   DRM_DEBUG_KMS("CRTC:%d (%s) mode: (%s)\n",
  crtc->base.id, sti_mixer_to_str(mixer),
- mode->base.id, mode->name);
+ mode->name);
 
DRM_DEBUG_KMS("%d %d %d %d %d %d %d %d %d %d 0x%x 0x%x\n",
  mode->vrefresh, mode->clock,
-- 
2.17.1

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

[PATCH 6/7] drm: meson: Delete base.id prints

[Shayenne Moura]

This patch removes base.id prints from drm_display_mode 
objects in meson files. It removes dependency from drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index d8c5cc34e22e..b203560f666d 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -365,7 +365,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
*data,
unsigned int wr_clk =
readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
 
-   DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
+   DRM_DEBUG_DRIVER("\"%s\"\n", mode->name);
 
/* Enable clocks */
regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
@@ -555,8 +555,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
int vic = drm_match_cea_mode(mode);
enum drm_mode_status status;
 
-   DRM_DEBUG_DRIVER("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 
0x%x\n",
-   mode->base.id, mode->name, mode->vrefresh, mode->clock,
+   DRM_DEBUG_DRIVER("Modeline \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 
0x%x\n",
+   mode->name, mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start,
@@ -650,8 +650,7 @@ static void meson_venc_hdmi_encoder_mode_set(struct 
drm_encoder *encoder,
struct meson_drm *priv = dw_hdmi->priv;
int vic = drm_match_cea_mode(mode);
 
-   DRM_DEBUG_DRIVER("%d:\"%s\" vic %d\n",
-mode->base.id, mode->name, vic);
+   DRM_DEBUG_DRIVER("\"%s\" vic %d\n", mode->name, vic);
 
/* VENC + VENC-DVI Mode setup */
meson_venc_hdmi_mode_set(priv, vic, mode);
-- 
2.17.1

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

[PATCH 4/7] drm: i915: Delete base.id prints

[Shayenne Moura]

This patch removes base.id prints from drm_display_mode 
objects in i915 files. It removes dependency from drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7f455bca528e..61dd7bb3fa85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2948,8 +2948,8 @@ static void intel_seq_print_mode(struct seq_file *m, int 
tabs,
for (i = 0; i < tabs; i++)
seq_putc(m, '\t');
 
-   seq_printf(m, "id %d:\"%s\" freq %d clock %d hdisp %d hss %d hse %d 
htot %d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n",
-  mode->base.id, mode->name,
+   seq_printf(m, "name:\"%s\" freq %d clock %d hdisp %d hss %d hse %d htot 
%d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n",
+  mode->name,
   mode->vrefresh, mode->clock,
   mode->hdisplay, mode->hsync_start,
   mode->hsync_end, mode->htotal,
-- 
2.17.1

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

[PATCH 7/7] drm: Complete remove drm_mode_object dependency

[Shayenne Moura]

This patch finalizes the KMS cleanup task dependency from drm_display_mode
It removes the use of drm_mode_object from drm_display_mode struct
and it removes the use of base.id and base.type.

Signed-off-by: Shayenne Moura 
---
 include/drm/drm_modes.h | 21 +++--
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index baded6514456..9ecc1e835565 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -136,8 +136,7 @@ enum drm_mode_status {
.hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
.htotal = (ht), .hskew = (hsk), .vdisplay = (vd), \
.vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
-   .vscan = (vs), .flags = (f), \
-   .base.type = DRM_MODE_OBJECT_MODE
+   .vscan = (vs), .flags = (f)
 
 #define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
 #define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
@@ -213,20 +212,6 @@ struct drm_display_mode {
 */
struct list_head head;
 
-   /**
-* @base:
-*
-* A display mode is a normal modeset object, possibly including public
-* userspace id.
-*
-* FIXME:
-*
-* This can probably be removed since the entire concept of userspace
-* managing modes explicitly has never landed in upstream kernel mode
-* setting support.
-*/
-   struct drm_mode_object base;
-
/**
 * @name:
 *
@@ -429,14 +414,14 @@ struct drm_display_mode {
 /**
  * DRM_MODE_FMT - printf string for  drm_display_mode
  */
-#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
+#define DRM_MODE_FMT"\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
 
 /**
  * DRM_MODE_ARG - printf arguments for  drm_display_mode
  * @m: display mode
  */
 #define DRM_MODE_ARG(m) \
-   (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
+   (m)->name, (m)->vrefresh, (m)->clock, \
(m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
(m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
(m)->type, (m)->flags
-- 
2.17.1

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

[PATCH 3/7] drm: omapdrm: Delete base.id prints

[Shayenne Moura]

This patch removes base.id prints from drm_display_mode 
objects in omapdrm files. It removes dependency from drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index b81302c4bf9e..e02986e0b2c6 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -306,9 +306,9 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
 
 done:
DBG("connector: mode %s: "
-   "%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   "\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
(ret == MODE_OK) ? "valid" : "invalid",
-   mode->base.id, mode->name, mode->vrefresh, mode->clock,
+   mode->name, mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start,
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index caffc547ef97..3d6febb2e9c4 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -427,8 +427,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_display_mode *mode = >state->adjusted_mode;
 
-   DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   omap_crtc->name, mode->base.id, mode->name,
+   DBG("%s: set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   omap_crtc->name, mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start, mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start, mode->vsync_end, mode->vtotal,
-- 
2.17.1

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

[PATCH 1/7] drm: msm: Delete base.id prints

[Shayenne Moura]

This patch removes base.id prints from drm_display_mode
objects in msm files. It removes dependency from drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c  | 4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c  | 4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c  | 4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c  | 4 ++--
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++--
 drivers/gpu/drm/msm/edp/edp_bridge.c  | 4 ++--
 9 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 457c29dba4a1..4d35fe5b8c07 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -244,8 +244,8 @@ static void mdp4_crtc_mode_set_nofb(struct drm_crtc *crtc)
 
mode = >state->adjusted_mode;
 
-   DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mdp4_crtc->name, mode->base.id, mode->name,
+   DBG("%s: set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   mdp4_crtc->name, mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
index 6a1ebdace391..a12ad73f08c7 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
@@ -58,8 +58,8 @@ static void mdp4_dsi_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
+   DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
index ba8e587f734b..3ace21e116a0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
@@ -104,8 +104,8 @@ static void mdp4_dtv_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
+   DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
index 2bfb39082f54..21be7640d3a8 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
@@ -273,8 +273,8 @@ static void mdp4_lcdc_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
+   DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
index d6f79dc755b4..ac61a10b79cc 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
@@ -134,8 +134,8 @@ void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
 {
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
+   DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index b1da9ce54379..ef2ee5888777 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -384,8 +384,8 @@ static void mdp5_crtc_mode_set_nofb(struct 

[PATCH 0/7] drm: KMS cleanup remove drm_mode_object dependency

[Shayenne Moura]

This patch serie removes drm_mode_object dependency from 
drm_display_mode struct. This is part of KMS cleanup.  

Shayenne Moura (7):
  drm: msm: Delete base.id prints
  drm: Remove use of drm_mode_object
  drm: omapdrm: Delete base.id prints
  drm: i915: Delete base.id prints 
  drm: sti: Delete base.id prints
  drm: meson: Delete base.id prints
  drm: Complete remove drm_mode_object dependency

 drivers/gpu/drm/drm_crtc_helper.c |  5 ++---
 drivers/gpu/drm/drm_modes.c   |  9 -
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 ++--
 drivers/gpu/drm/meson/meson_dw_hdmi.c |  9 -
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c  |  4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c  |  4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c |  4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c  |  4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c  |  4 ++--
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  4 ++--
 drivers/gpu/drm/msm/edp/edp_bridge.c  |  4 ++--
 drivers/gpu/drm/omapdrm/omap_connector.c  |  4 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c   |  4 ++--
 drivers/gpu/drm/sti/sti_crtc.c|  4 ++--
 include/drm/drm_modes.h   | 10 --
 17 files changed, 36 insertions(+), 49 deletions(-)

-- 
2.17.1

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

[PATCH 2/7] drm: Remove use of drm_mode_object

[Shayenne Moura]

This patch removes the drm_mode_object prints, evaluation and use from 
drm_display_mode objects used in drm files. It removes dependency from
drm_mode_object.

Signed-off-by: Shayenne Moura 
---
 drivers/gpu/drm/drm_crtc_helper.c | 5 ++---
 drivers/gpu/drm/drm_modes.c   | 9 -
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index a3c81850e755..cc5cc8d109a2 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -386,9 +386,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
if (!encoder_funcs)
continue;
 
-   DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%d:%s]\n",
-   encoder->base.id, encoder->name,
-   mode->base.id, mode->name);
+   DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%s]\n",
+   encoder->base.id, encoder->name, mode->name);
if (encoder_funcs->mode_set)
encoder_funcs->mode_set(encoder, mode, adjusted_mode);
 
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 24a750436559..adce9a26bac9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -71,11 +71,6 @@ struct drm_display_mode *drm_mode_create(struct drm_device 
*dev)
if (!nmode)
return NULL;
 
-   if (drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_MODE)) {
-   kfree(nmode);
-   return NULL;
-   }
-
return nmode;
 }
 EXPORT_SYMBOL(drm_mode_create);
@@ -92,8 +87,6 @@ void drm_mode_destroy(struct drm_device *dev, struct 
drm_display_mode *mode)
if (!mode)
return;
 
-   drm_mode_object_unregister(dev, >base);
-
kfree(mode);
 }
 EXPORT_SYMBOL(drm_mode_destroy);
@@ -911,11 +904,9 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
  */
 void drm_mode_copy(struct drm_display_mode *dst, const struct drm_display_mode 
*src)
 {
-   int id = dst->base.id;
struct list_head head = dst->head;
 
*dst = *src;
-   dst->base.id = id;
dst->head = head;
 }
 EXPORT_SYMBOL(drm_mode_copy);
-- 
2.17.1

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

Re: [GIT PULL] etnaviv-next for 4.21 revamp

[Daniel Vetter]

On Tue, Dec 18, 2018 at 12:00:45PM +0100, Lucas Stach wrote:
> Hi Daniel, Dave,
> 
> updated pull request with Christian's review added below.
> 
> Regards,
> Lucas

Thanks, applied. tagged pull would be really nice, avoids me having to
find v1 for the merge commit message.

Cheers, Daniel
> 
> The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0:
> 
>   drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 
> 18:14:48 +0100)
> 
> are available in the Git repository at:
> 
>   https://git.pengutronix.de/git/lst/linux etnaviv/next
> 
> for you to fetch changes up to 801c7a1e528623f073c4007cb04d9a817e33b3a4:
> 
>   drm/etnaviv: remove lastctx member from gpu struct (2018-12-18 11:55:16 
> +0100)
> 
> 
> Lucas Stach (5):
>   drm/etnaviv: kill active fence tracking
>   drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
>   drm/etnaviv: remove unnecessary local irq disable
>   drm/etnaviv: replace header include with forward declaration
>   drm/etnaviv: remove lastctx member from gpu struct
> 
> Thomas Zimmermann (1):
>   drm/etnaviv: Replace drm_dev_unref with drm_dev_put
> 
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  2 --
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 
> -
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++--
>  5 files changed, 23 insertions(+), 55 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[v1] drm/msm/dpu: Cleanup dpu plane interface

[Jayant Shekhar]

Remove unused functions from dpu plane interface
and unused variables from dpu plane state structure.

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 7fed0b6..0e6063a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -28,23 +28,18 @@
 /**
  * struct dpu_plane_state: Define dpu extension of drm plane state object
  * @base:  base drm plane state object
- * @property_state: Local storage for msm_prop properties
- * @property_values:   cached plane property values
  * @aspace:pointer to address space for input/output buffers
- * @input_fence:   dereferenced input fence pointer
  * @stage: assigned by crtc blender
  * @multirect_index: index of the rectangle of SSPP
  * @multirect_mode: parallel or time multiplex multirect mode
  * @pending:   whether the current update is still pending
  * @scaler3_cfg: configuration data for scaler3
  * @pixel_ext: configuration data for pixel extensions
- * @scaler_check_state: indicates status of user provided pixel extension data
  * @cdp_cfg:   CDP configuration
  */
 struct dpu_plane_state {
struct drm_plane_state base;
struct msm_gem_address_space *aspace;
-   void *input_fence;
enum dpu_stage stage;
uint32_t multirect_index;
uint32_t multirect_mode;
@@ -107,12 +102,6 @@ void dpu_plane_get_ctl_flush(struct drm_plane *plane, 
struct dpu_hw_ctl *ctl,
 void dpu_plane_flush(struct drm_plane *plane);
 
 /**
- * dpu_plane_kickoff - final plane operations before commit kickoff
- * @plane: Pointer to drm plane structure
- */
-void dpu_plane_kickoff(struct drm_plane *plane);
-
-/**
  * dpu_plane_set_error: enable/disable error condition
  * @plane: pointer to drm_plane structure
  */
@@ -147,14 +136,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
 void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state);
 
 /**
- * dpu_plane_wait_input_fence - wait for input fence object
- * @plane:   Pointer to DRM plane object
- * @wait_ms: Wait timeout value
- * Returns: Zero on success
- */
-int dpu_plane_wait_input_fence(struct drm_plane *plane, uint32_t wait_ms);
-
-/**
  * dpu_plane_color_fill - enables color fill on plane
  * @plane:  Pointer to DRM plane object
  * @color:  RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
@@ -164,12 +145,4 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
 int dpu_plane_color_fill(struct drm_plane *plane,
uint32_t color, uint32_t alpha);
 
-/**
- * dpu_plane_set_revalidate - sets revalidate flag which forces a full
- * validation of the plane properties in the next atomic check
- * @plane: Pointer to DRM plane object
- * @enable: Boolean to set/unset the flag
- */
-void dpu_plane_set_revalidate(struct drm_plane *plane, bool enable);
-
 #endif /* _DPU_PLANE_H_ */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH] fbdev: make FB_BACKLIGHT a tristate

[Rob Clark]

On Fri, Oct 26, 2018 at 10:09 AM Rob Clark  wrote:
>
> BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
> FB_BACKLIGHT prevents it from being built as a module.  There
> doesn't seem to be any particularly good reason for this, so
> switch FB_BACKLIGHT over to tristate.
>
> Signed-off-by: Rob Clark 
> Tested-by: Arnd Bergmann 

bump

maybe we can merge this via drm-misc?

BR,
-R

> ---
> v2: remove IS_ENABLED() from UABI headers.  Userspace doesn't
> know the kernel config, so just remove the ifdef guard
>
>  drivers/video/fbdev/Kconfig| 2 +-
>  drivers/video/fbdev/core/fbsysfs.c | 8 
>  include/linux/fb.h | 2 +-
>  include/uapi/linux/fb.h| 2 --
>  4 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 591a13a59787..146ab2c347f8 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -198,7 +198,7 @@ config FB_MACMODES
> default n
>
>  config FB_BACKLIGHT
> -   bool
> +   tristate
> depends on FB
> select BACKLIGHT_LCD_SUPPORT
> select BACKLIGHT_CLASS_DEVICE
> diff --git a/drivers/video/fbdev/core/fbsysfs.c 
> b/drivers/video/fbdev/core/fbsysfs.c
> index e31a182b42bf..44cca39f2b51 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -60,7 +60,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct 
> device *dev)
> info->device = dev;
> info->fbcon_rotate_hint = -1;
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> mutex_init(>bl_curve_mutex);
>  #endif
>
> @@ -429,7 +429,7 @@ static ssize_t show_fbstate(struct device *device,
> return snprintf(buf, PAGE_SIZE, "%d\n", fb_info->state);
>  }
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>  static ssize_t store_bl_curve(struct device *device,
>   struct device_attribute *attr,
>   const char *buf, size_t count)
> @@ -510,7 +510,7 @@ static struct device_attribute device_attrs[] = {
> __ATTR(stride, S_IRUGO, show_stride, NULL),
> __ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
> __ATTR(state, S_IRUGO|S_IWUSR, show_fbstate, store_fbstate),
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> __ATTR(bl_curve, S_IRUGO|S_IWUSR, show_bl_curve, store_bl_curve),
>  #endif
>  };
> @@ -551,7 +551,7 @@ void fb_cleanup_device(struct fb_info *fb_info)
> }
>  }
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>  /* This function generates a linear backlight curve
>   *
>   * 0: off
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a3cab6dc9b44..7cdd31a69719 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -485,7 +485,7 @@ struct fb_info {
> struct list_head modelist;  /* mode list */
> struct fb_videomode *mode;  /* current mode */
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> /* assigned backlight device */
> /* set before framebuffer registration,
>remove after unregister */
> diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
> index 6cd9b198b7c6..b6aac7ee1f67 100644
> --- a/include/uapi/linux/fb.h
> +++ b/include/uapi/linux/fb.h
> @@ -393,11 +393,9 @@ struct fb_cursor {
> struct fb_image image;  /* Cursor image */
>  };
>
> -#ifdef CONFIG_FB_BACKLIGHT
>  /* Settings for the generic backlight code */
>  #define FB_BACKLIGHT_LEVELS128
>  #define FB_BACKLIGHT_MAX   0xFF
> -#endif
>
>
>  #endif /* _UAPI_LINUX_FB_H */
> --
> 2.17.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v2 2/8] drm/meson: add HDMI div40 TMDS mode

[Neil Armstrong]

On 18/12/2018 13:36, Andrzej Hajda wrote:
> On 30.11.2018 14:42, Neil Armstrong wrote:
>> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 24 
>>  1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
>> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> index 807111ebfdd9..b8775102b100 100644
>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> @@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
>> *data,
>>  unsigned int wr_clk =
>>  readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>>  
>> -DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
>> +DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
>> + mode->clock > 34 ? 40 : 10);
>>  
>>  /* Enable clocks */
>>  regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
>> @@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
>> *data,
>>  /* Enable normal output to PHY */
>>  dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>>  
>> -/* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
>> -dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
>> -dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
>> +/* TMDS pattern setup (TOFIX Handle the YUV420 case) */
>> +if (mode->clock > 34) {
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>> +  0x03ff03ff);
>> +} else {
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
>> +  0x001f001f);
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>> +  0x001f001f);
>> +}
>>  
>>  /* Load TMDS pattern */
>>  dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
>> @@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
>> *data,
>>  /* Disable clock, fifo, fifo_wr */
>>  regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
>>  
>> +dw_hdmi_set_high_tmds_clock_ratio(hdmi);
>> +
>>  msleep(100);
>>  
>>  /* Reset PHY 3 times in a row */
>> @@ -562,6 +573,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>>  mode->vdisplay, mode->vsync_start,
>>  mode->vsync_end, mode->vtotal, mode->type, mode->flags);
>>  
>> +/* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
>> +if (mode->clock > 34 &&
>> +connector->display_info.max_tmds_clock < 34)
>> +return MODE_BAD;
>> +
> 
> 
> Why not just:
> 
> if (mode->clock > connector->display_info.max_tmds_clock)
>   return MODE_BAD;

Hmm, let me check, it may be better indeed.

Neil

> 
> 
> Regards
> 
> Andrzej
> 
> 
>>  /* Check against non-VIC supported modes */
>>  if (!vic) {
>>  status = meson_venc_hdmi_supported_mode(mode);
> 
> 

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

Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support

[Neil Armstrong]

On 18/12/2018 13:25, Andrzej Hajda wrote:
> Hi Neil,
> 
> 
> On 30.11.2018 14:42, Neil Armstrong wrote:
>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
>> Scrambling when supported or mandatory.
>>
>> This patch also adds an helper to setup the control bit to support
>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
>>
>> These changes were based on work done by Huicong Xu 
>> and Nickey Yang  to support HDMI2.0 modes
>> on the Rockchip 4.4 BSP kernel at [1]
>>
>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
>>
>> Cc: Nickey Yang 
>> Cc: Huicong Xu 
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 88 ++-
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  1 +
>>  include/drm/bridge/dw_hdmi.h  |  1 +
>>  3 files changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 64c3cf027518..fcd941d52753 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -28,6 +28,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #include 
>> @@ -43,6 +44,11 @@
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> +/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 
>> */
>> +#define SCDC_MIN_SOURCE_VERSION 0x1
>> +
>> +#define HDMI14_MAX_TMDSCLK  34000
>> +
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
>> unsigned short data,
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>>  
>> +/*
>> + * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
>> + * - The Source shall suspend transmission of the TMDS clock and data
>> + * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it
>> + * from a 0 to a 1 or from a 1 to a 0
>> + * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from
>> + * the time the TMDS_Bit_Clock_Ratio bit is written until resuming
>> + * transmission of TMDS clock and data
>> + *
>> + * To respect the 100ms maximum delay, the 
>> dw_hdmi_set_high_tmds_clock_ratio()
>> + * helper should called right before enabling the TMDS Clock and Data in
>> + * the PHY configuration callback.
>> + */
>> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
>> +{
>> +unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
>> +
>> +/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
>> +if (hdmi->connector.display_info.hdmi.scdc.supported) {
>> +if (mtmdsclock > HDMI14_MAX_TMDSCLK)
>> +drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
>> +else
>> +drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
>> +}
>> +}
>> +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
>> +
>>  static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>>  {
>>  hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
>> @@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>>  
>>  dw_hdmi_phy_power_off(hdmi);
>>  
>> +dw_hdmi_set_high_tmds_clock_ratio(hdmi);
>> +
>>  /* Leave low power consumption mode by asserting SVSRET. */
>>  if (phy->has_svsret)
>>  dw_hdmi_phy_enable_svsret(hdmi, 1);
>> @@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>>  return ret;
>>  }
>>  
>> +/* Wait for resuming transmission of TMDS clock and data */
>> +if (mpixelclock > HDMI14_MAX_TMDSCLK)
>> +msleep(100);
>> +
>>  return dw_hdmi_phy_power_on(hdmi);
>>  }
>>  
>> @@ -1340,11 +1379,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
>>  
>>  static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode 
>> *mode)
>>  {
>> +bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
>>  struct hdmi_avi_infoframe frame;
>>  u8 val;
>>  
>>  /* Initialise info frame from DRM mode */
>> -drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
>> +drm_hdmi_avi_infoframe_from_display_mode(, mode, is_hdmi2_sink);
>>  
>>  if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>>  frame.colorspace = HDMI_COLORSPACE_YUV444;
>> @@ -1503,7 +1543,8 @@ static void 
>> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
>>  static void hdmi_av_composer(struct dw_hdmi *hdmi,
>>   const struct drm_display_mode *mode)
>>  {
>> -u8 inv_val;
>> +u8 inv_val, bytes;
>> +struct drm_hdmi_info *hdmi_info = >connector.display_info.hdmi;
>>  struct hdmi_vmode *vmode = >hdmi_data.video_mode;
>>  int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
>>  unsigned 

[PATCH][next] amdgpu/dc: remove various variables that are defined but never used

[Colin King]

From: Colin Ian King 

There are several variables that are defined and never used and hence can
be removed. Remove them. Cleans up clang -Wunused-const-variable warnings:

warning: ‘dvi_hdmi_dongle_signature_str’ defined but not used
warning: ‘dce11_one_lpt_channel_max_resolution’ defined but not used
warning: ‘ddc_hw_status_addr’ defined but not used

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |  1 -
 .../gpu/drm/amd/display/dc/dce110/dce110_compressor.c  |  2 --
 .../amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c  | 10 --
 3 files changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 506a97e16956..99a314b79850 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -42,7 +42,6 @@
 #define CV_SMART_DONGLE_ADDRESS 0x20
 /* DVI-HDMI dongle slave address for retrieving dongle signature*/
 #define DVI_HDMI_DONGLE_ADDRESS 0x68
-static const int8_t dvi_hdmi_dongle_signature_str[] = "6140063500G";
 struct dvi_hdmi_dongle_signature_data {
int8_t vendor[3];/* "AMD" */
uint8_t version[2];
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
index 52d50e24a995..7b23239d33fe 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
@@ -62,8 +62,6 @@ static const struct dce110_compressor_reg_offsets 
reg_offsets[] = {
 }
 };
 
-static const uint32_t dce11_one_lpt_channel_max_resolution = 2560 * 1600;
-
 static uint32_t align_to_chunks_number_per_line(uint32_t pixels)
 {
return 256 * ((pixels + 255) / 256);
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c 
b/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
index 4853ee26096a..c9d6cf08e8ab 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
@@ -50,16 +50,6 @@
  * This unit
  */
 
-static const uint32_t ddc_hw_status_addr[] = {
-   mmDC_I2C_DDC1_HW_STATUS,
-   mmDC_I2C_DDC2_HW_STATUS,
-   mmDC_I2C_DDC3_HW_STATUS,
-   mmDC_I2C_DDC4_HW_STATUS,
-   mmDC_I2C_DDC5_HW_STATUS,
-   mmDC_I2C_DDC6_HW_STATUS,
-   mmDC_I2C_DDCVGA_HW_STATUS
-};
-
 /*
  * @brief
  * Cast 'struct i2c_sw_engine *'
-- 
2.19.1

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

Re: [PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range

[Russell King - ARM Linux]

On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 6:03 PM Russell King - ARM Linux
>  wrote:
> >
> > On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux
> > >  wrote:
> > > > This looks like a change in behaviour.
> > > >
> > > > If user_count is zero, and offset is zero, then we pass into
> > > > vm_insert_range() a page_count of zero, and vm_insert_range() does
> > > > nothing and returns zero.
> > > >
> > > > However, as we can see from the above code, the original behaviour
> > > > was to return -ENXIO in that case.
> > >
> > > I think these checks are not necessary. I am not sure if we get into mmap
> > > handlers of driver with user_count = 0.
> >
> > I'm not sure either, I'm just pointing out the change of behaviour.
> 
> Ok. I think feedback from Heiko might be helpful here :)
> 
> >
> > > > The other thing that I'm wondering is that if (eg) count is 8 (the
> > > > object is 8 pages), offset is 2, and the user requests mapping 6
> > > > pages (user_count = 6), then we call vm_insert_range() with a
> > > > pages of rk_obj->pages + 2, and a pages_count of 6 - 2 = 4. So we
> > > > end up inserting four pages.
> > >
> > > Considering the scenario, user_count will remain 8 (user_count =
> > > vma_pages(vma) ). ? No ?
> > > Then we call vm_insert_range() with a pages of rk_obj->pages + 2, and
> > > a pages_count
> > > of 8 - 2 = 6. So we end up inserting 6 pages.
> > >
> > > Please correct me if I am wrong.
> >
> > vma_pages(vma) is the number of pages that the user requested, it is
> > the difference between vma->vm_end and vma->vm_start in pages.  As I
> > said above, "the user requests mapping 6 pages", so vma_pages() will
> > be 6, and so user_count will also be 6.  You are passing
> > user_count - offset into vm_insert_range(), which will be 6 - 2 = 4
> > in my example.  This is two pages short of what the user requested.
> >
> 
> So, this should be the correct behavior.
> 
>  return vm_insert_range(vma, vma->vm_start,
> rk_obj->pages + offset,
>   user_count);

... and by doing so, you're introducing another instance of the same
bug I pointed out in patch 2.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v2 3/8] drm/meson: add support for HDMI2.0 2160p modes

[Andrzej Hajda]

On 30.11.2018 14:42, Neil Armstrong wrote:
> Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
> operation in the DW-HDMI Controller, we can enable support for the
> HDMI2.0 3840x2160@60/50 RGB444 display modes.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_venc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_venc.c 
> b/drivers/gpu/drm/meson/meson_venc.c
> index 0ba04f6813e6..66d73a932d19 100644
> --- a/drivers/gpu/drm/meson/meson_venc.c
> +++ b/drivers/gpu/drm/meson/meson_venc.c
> @@ -848,6 +848,8 @@ struct meson_hdmi_venc_vic_mode {
>   { 93, _hdmi_encp_mode_2160p24 },
>   { 94, _hdmi_encp_mode_2160p25 },
>   { 95, _hdmi_encp_mode_2160p30 },
> + { 96, _hdmi_encp_mode_2160p25 },
> + { 97, _hdmi_encp_mode_2160p30 },
>   { 0, NULL}, /* sentinel */
>  };
>  

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

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

Re: [PATCH RFC v2 2/8] drm/meson: add HDMI div40 TMDS mode

[Andrzej Hajda]

On 30.11.2018 14:42, Neil Armstrong wrote:
> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 807111ebfdd9..b8775102b100 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
> *data,
>   unsigned int wr_clk =
>   readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>  
> - DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
> + DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
> +  mode->clock > 34 ? 40 : 10);
>  
>   /* Enable clocks */
>   regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
> @@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
> *data,
>   /* Enable normal output to PHY */
>   dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>  
> - /* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
> + /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
> + if (mode->clock > 34) {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> +   0x03ff03ff);
> + } else {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
> +   0x001f001f);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> +   0x001f001f);
> + }
>  
>   /* Load TMDS pattern */
>   dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
> @@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
> *data,
>   /* Disable clock, fifo, fifo_wr */
>   regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
>  
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> +
>   msleep(100);
>  
>   /* Reset PHY 3 times in a row */
> @@ -562,6 +573,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>   mode->vdisplay, mode->vsync_start,
>   mode->vsync_end, mode->vtotal, mode->type, mode->flags);
>  
> + /* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
> + if (mode->clock > 34 &&
> + connector->display_info.max_tmds_clock < 34)
> + return MODE_BAD;
> +


Why not just:

if (mode->clock > connector->display_info.max_tmds_clock)
return MODE_BAD;


Regards

Andrzej


>   /* Check against non-VIC supported modes */
>   if (!vic) {
>   status = meson_venc_hdmi_supported_mode(mode);


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

Re: [PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range

[Russell King - ARM Linux]

On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux
>  wrote:
> > This looks like a change in behaviour.
> >
> > If user_count is zero, and offset is zero, then we pass into
> > vm_insert_range() a page_count of zero, and vm_insert_range() does
> > nothing and returns zero.
> >
> > However, as we can see from the above code, the original behaviour
> > was to return -ENXIO in that case.
> 
> I think these checks are not necessary. I am not sure if we get into mmap
> handlers of driver with user_count = 0.

I'm not sure either, I'm just pointing out the change of behaviour.

> > The other thing that I'm wondering is that if (eg) count is 8 (the
> > object is 8 pages), offset is 2, and the user requests mapping 6
> > pages (user_count = 6), then we call vm_insert_range() with a
> > pages of rk_obj->pages + 2, and a pages_count of 6 - 2 = 4. So we
> > end up inserting four pages.
> 
> Considering the scenario, user_count will remain 8 (user_count =
> vma_pages(vma) ). ? No ?
> Then we call vm_insert_range() with a pages of rk_obj->pages + 2, and
> a pages_count
> of 8 - 2 = 6. So we end up inserting 6 pages.
> 
> Please correct me if I am wrong.

vma_pages(vma) is the number of pages that the user requested, it is
the difference between vma->vm_end and vma->vm_start in pages.  As I
said above, "the user requests mapping 6 pages", so vma_pages() will
be 6, and so user_count will also be 6.  You are passing
user_count - offset into vm_insert_range(), which will be 6 - 2 = 4
in my example.  This is two pages short of what the user requested.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [maintainer-tools PATCH v2 0/4] dim: fix git directory evaluation

[Daniel Vetter]

On Tue, Dec 18, 2018 at 11:30:12AM +0100, Andrzej Hajda wrote:
> Hi all,
> 
> This small patchset fixes issues with dim and git worktree's.
> In v2 I have:
>  - removed incorrect rr_cache_dir fix patch,
>  - added patch fixing update_rerere_cache,
>  - added patch converting git_dir function to use git rev_parse,
>  - added R-Bs (thanks Daniel).

Entire series applied, thanks for your patches.
-Daniel

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (4):
>   dim: allow git_dir to specify arbitrary work directory
>   dim: fix git directory handling
>   dim: fix update_rerere_cache
>   dim: use git rev-parse to get git directory
> 
>  dim | 44 +---
>  1 file changed, 17 insertions(+), 27 deletions(-)
> 
> -- 
> 2.17.1
> 
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support

[Andrzej Hajda]

Hi Neil,


On 30.11.2018 14:42, Neil Armstrong wrote:
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
>
> This patch also adds an helper to setup the control bit to support
> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
>
> These changes were based on work done by Huicong Xu 
> and Nickey Yang  to support HDMI2.0 modes
> on the Rockchip 4.4 BSP kernel at [1]
>
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
>
> Cc: Nickey Yang 
> Cc: Huicong Xu 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 88 ++-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  1 +
>  include/drm/bridge/dw_hdmi.h  |  1 +
>  3 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 64c3cf027518..fcd941d52753 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -43,6 +44,11 @@
>  
>  #define HDMI_EDID_LEN512
>  
> +/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
> +#define SCDC_MIN_SOURCE_VERSION  0x1
> +
> +#define HDMI14_MAX_TMDSCLK   34000
> +
>  enum hdmi_datamap {
>   RGB444_8B = 0x01,
>   RGB444_10B = 0x03,
> @@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
> unsigned short data,
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>  
> +/*
> + * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
> + * - The Source shall suspend transmission of the TMDS clock and data
> + * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it
> + * from a 0 to a 1 or from a 1 to a 0
> + * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from
> + * the time the TMDS_Bit_Clock_Ratio bit is written until resuming
> + * transmission of TMDS clock and data
> + *
> + * To respect the 100ms maximum delay, the 
> dw_hdmi_set_high_tmds_clock_ratio()
> + * helper should called right before enabling the TMDS Clock and Data in
> + * the PHY configuration callback.
> + */
> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
> +{
> + unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
> +
> + /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> + if (hdmi->connector.display_info.hdmi.scdc.supported) {
> + if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> + else
> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
> +
>  static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>  {
>   hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
> @@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>  
>   dw_hdmi_phy_power_off(hdmi);
>  
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> +
>   /* Leave low power consumption mode by asserting SVSRET. */
>   if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
> @@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   return ret;
>   }
>  
> + /* Wait for resuming transmission of TMDS clock and data */
> + if (mpixelclock > HDMI14_MAX_TMDSCLK)
> + msleep(100);
> +
>   return dw_hdmi_phy_power_on(hdmi);
>  }
>  
> @@ -1340,11 +1379,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
>  
>  static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode 
> *mode)
>  {
> + bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
>   struct hdmi_avi_infoframe frame;
>   u8 val;
>  
>   /* Initialise info frame from DRM mode */
> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> + drm_hdmi_avi_infoframe_from_display_mode(, mode, is_hdmi2_sink);
>  
>   if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>   frame.colorspace = HDMI_COLORSPACE_YUV444;
> @@ -1503,7 +1543,8 @@ static void 
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
>  static void hdmi_av_composer(struct dw_hdmi *hdmi,
>const struct drm_display_mode *mode)
>  {
> - u8 inv_val;
> + u8 inv_val, bytes;
> + struct drm_hdmi_info *hdmi_info = >connector.display_info.hdmi;
>   struct hdmi_vmode *vmode = >hdmi_data.video_mode;
>   int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
>   unsigned int vdisplay;
> @@ -1513,7 +1554,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   dev_dbg(hdmi->dev, "final pixclk = %d\n", 

[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off

[bugzilla-daemon]

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

--- Comment #4 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
(In reply to Felix Schwarz from comment #2)
> Oh and probably AMD developers would like to know which kernel version you
> are using.

It's here, in "Kernel Version" field in bugzilla. 4.20-rc7

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

[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off

[bugzilla-daemon]

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

Aleksandr Mezin (mezin.alexan...@gmail.com) changed:

   What|Removed |Added

   Severity|normal  |low

--- Comment #3 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
(In reply to Felix Schwarz from comment #1)
> Probably a silly question but still: Did you confirm (visually) that the
> fans are actually turned off? 

Yes

> AFAIK on Windows there is extra software
> running which turns of the fans when the GPU temperature is below a certain
> threshold. IIRC you need third-party scripts to achieve the same.

On Windows I have no additional software, only AMD driver (downloaded from
amd.com, not modded by Sapphire or anything).

Actually, I have my own script that controls fans on Linux (because there's no
sysfs knobs to tweak the "automatic" fan curve), it just checks the temperature
every second and writes desired fan speed to hwmon/pwm1. I tried to manually
write '0' to pwm1 (with pwm1_enable set to '1') - exactly the same bug -
fan1_input stops changing (when the fan is actually spinning, fan speed is
always slightly changing, +/- few rpms), but doesn't show "0" (and, again, the
fans are actually stopped)

This problem occurs with both "pwm1_enable=2" and "pwm1_enable=1, pwm1=0"

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

Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o

[Chris Wilson]

Quoting Nick Desaulniers (2018-10-25 23:20:58)
> On Thu, Oct 25, 2018 at 12:36 PM Nathan Chancellor
>  wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this warning is
> > disabled so it shows up in the build when it shouldn't:
> >
> > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > variable 'wq' is uninitialized when used within its own initialization
> > [-Werror,-Wuninitialized]
> > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > ^~
> > ./include/linux/wait.h:74:63: note: expanded from macro
> > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> >  ^~~~
> > ./include/linux/wait.h:72:33: note: expanded from macro
> > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > ({ init_waitqueue_head(); name; })
> >^~~~
> > 1 error generated.
> >
> > This warning looks to be a false positive given that init_waitqueue_head
> > initializes name before it is used. Rather than disable the warning for
> > the full folder like commit 46e2068081e9 ("drm/i915: Disable some extra
> 
> cc author/reviewer of 46e2068081e9.
> 
> I'm fine with the patch as is, unless others prefer to disable it for
> the whole subdir?  We could be playing whack-a-mole in the future
> disabling this warning for other translation units.

Yes, exactly this since the warning is generated by a core header and a
fairly common pattern its use is not restricted to any single file.
(Will not all selftests similarly explode?)

The other false-positive clang-6 gave was for local_clock_us().
Presumably that one is fixed?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off

[bugzilla-daemon]

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

--- Comment #2 from Felix Schwarz (felix.schw...@oss.schwarz.eu) ---
Oh and probably AMD developers would like to know which kernel version you are
using.

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

[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off

[bugzilla-daemon]

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

Felix Schwarz (felix.schw...@oss.schwarz.eu) changed:

   What|Removed |Added

 CC||felix.schwarz@oss.schwarz.e
   ||u

--- Comment #1 from Felix Schwarz (felix.schw...@oss.schwarz.eu) ---
Probably a silly question but still: Did you confirm (visually) that the fans
are actually turned off? AFAIK on Windows there is extra software running which
turns of the fans when the GPU temperature is below a certain threshold. IIRC
you need third-party scripts to achieve the same.

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

[Bug 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others

[bugzilla-daemon]

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

--- Comment #1 from Łukasz Skocz  ---
Created attachment 142846
  --> https://bugs.freedesktop.org/attachment.cgi?id=142846=edit
another dmesg output

-- 
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 102909] radeon 0000:03:00.0: ring 0 stalled for more than 10000msec

[bugzilla-daemon]

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

Łukasz Skocz  changed:

   What|Removed |Added

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

-- 
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 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others

[bugzilla-daemon]

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

Łukasz Skocz  changed:

   What|Removed |Added

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

-- 
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 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others

[bugzilla-daemon]

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

Bug ID: 109085
   Summary: Radeon driver crashes with a message "ring 0 stalled
for more than 10344msec" when using Citra and others
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: kaszak...@gmail.com

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

Overview: 

Radeon driver crashes and completely corrupts the screen during an attempt to
use Citra emulator (always right after loading a game), and sometimes randomly
during other GPU-demanding tasks, like using hardware video decoding through
VDPAU. Strangely, the X server itself doesn't crash, and i can still see and
move the mouse cursor, although heavily corrupted.

Attached dmesg from the time of the crash.


Steps to Reproduce: 

Open Citra, try to load any game.


Actual Results: The driver crashes, resulting in screen corruption.

Expected Results: Citra running the game or failing safely without crashing the
driver.

Software versions:

Linux 4.19.9
Mesa 18.3.1
Xorg 1.20.3
xf86-video-ati 18.1.0

lspci output for the GPU:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV710/M92 [Mobility Radeon HD 4530/4570/545v] (prog-if 00 [VGA controller])
Subsystem: Dell Mobility Radeon HD 4570 / 545v
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon
00: 02 10 53 95 07 05 10 00 00 00 00 03 10 00 80 00
10: 08 00 00 d0 01 20 00 00 00 00 00 fc 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 be 02
30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 be 02
50: 01 58 03 06 00 00 00 00 10 a0 12 00 a0 8f 2c 01
60: 10 09 0a 00 01 0d 04 00 43 00 01 11 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 05 00 81 00 04 20 e0 fe 00 00 00 00 23 40 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



Additional Information: possibly related bugs:

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

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

[v3] drm/msm/dpu: Clean up dpu hw interrupts

[Jayant Shekhar]

Remove unused functions and macros from files handling
dpu hardware interrupts.

changes in v2:
  Removed clear_interrupt_status (Jordan Crouse)
changes in v3:
  Changed commit text

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 44 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 44 ---
 2 files changed, 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index c0b7f00..8a28a03 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -170,10 +170,6 @@
 /**
  * AD4 interrupt status bit definitions
  */
-#define DPU_INTR_BRIGHTPR_UPDATED BIT(4)
-#define DPU_INTR_DARKENH_UPDATED BIT(3)
-#define DPU_INTR_STREN_OUTROI_UPDATED BIT(2)
-#define DPU_INTR_STREN_INROI_UPDATED BIT(1)
 #define DPU_INTR_BACKLIGHT_UPDATED BIT(0)
 /**
  * struct dpu_intr_reg - array of DPU register sets
@@ -782,18 +778,6 @@ static int dpu_hw_intr_irqidx_lookup(enum dpu_intr_type 
intr_type,
return -EINVAL;
 }
 
-static void dpu_hw_intr_set_mask(struct dpu_hw_intr *intr, uint32_t reg_off,
-   uint32_t mask)
-{
-   if (!intr)
-   return;
-
-   DPU_REG_WRITE(>hw, reg_off, mask);
-
-   /* ensure register writes go through */
-   wmb();
-}
-
 static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr *intr,
void (*cbfunc)(void *, int),
void *arg)
@@ -1004,18 +988,6 @@ static int dpu_hw_intr_disable_irqs(struct dpu_hw_intr 
*intr)
return 0;
 }
 
-static int dpu_hw_intr_get_valid_interrupts(struct dpu_hw_intr *intr,
-   uint32_t *mask)
-{
-   if (!intr || !mask)
-   return -EINVAL;
-
-   *mask = IRQ_SOURCE_MDP | IRQ_SOURCE_DSI0 | IRQ_SOURCE_DSI1
-   | IRQ_SOURCE_HDMI | IRQ_SOURCE_EDP;
-
-   return 0;
-}
-
 static void dpu_hw_intr_get_interrupt_statuses(struct dpu_hw_intr *intr)
 {
int i;
@@ -1065,19 +1037,6 @@ static void dpu_hw_intr_clear_intr_status_nolock(struct 
dpu_hw_intr *intr,
wmb();
 }
 
-static void dpu_hw_intr_clear_interrupt_status(struct dpu_hw_intr *intr,
-   int irq_idx)
-{
-   unsigned long irq_flags;
-
-   if (!intr)
-   return;
-
-   spin_lock_irqsave(>irq_lock, irq_flags);
-   dpu_hw_intr_clear_intr_status_nolock(intr, irq_idx);
-   spin_unlock_irqrestore(>irq_lock, irq_flags);
-}
-
 static u32 dpu_hw_intr_get_interrupt_status(struct dpu_hw_intr *intr,
int irq_idx, bool clear)
 {
@@ -1113,16 +1072,13 @@ static u32 dpu_hw_intr_get_interrupt_status(struct 
dpu_hw_intr *intr,
 
 static void __setup_intr_ops(struct dpu_hw_intr_ops *ops)
 {
-   ops->set_mask = dpu_hw_intr_set_mask;
ops->irq_idx_lookup = dpu_hw_intr_irqidx_lookup;
ops->enable_irq = dpu_hw_intr_enable_irq;
ops->disable_irq = dpu_hw_intr_disable_irq;
ops->dispatch_irqs = dpu_hw_intr_dispatch_irq;
ops->clear_all_irqs = dpu_hw_intr_clear_irqs;
ops->disable_all_irqs = dpu_hw_intr_disable_irqs;
-   ops->get_valid_interrupts = dpu_hw_intr_get_valid_interrupts;
ops->get_interrupt_statuses = dpu_hw_intr_get_interrupt_statuses;
-   ops->clear_interrupt_status = dpu_hw_intr_clear_interrupt_status;
ops->clear_intr_status_nolock = dpu_hw_intr_clear_intr_status_nolock;
ops->get_interrupt_status = dpu_hw_intr_get_interrupt_status;
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
index 61e4cba..4d7a1c7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
@@ -20,13 +20,6 @@
 #include "dpu_hw_util.h"
 #include "dpu_hw_mdss.h"
 
-#define IRQ_SOURCE_MDP BIT(0)
-#define IRQ_SOURCE_DSI0BIT(4)
-#define IRQ_SOURCE_DSI1BIT(5)
-#define IRQ_SOURCE_HDMIBIT(8)
-#define IRQ_SOURCE_EDP BIT(12)
-#define IRQ_SOURCE_MHL BIT(16)
-
 /**
  * dpu_intr_type - HW Interrupt Type
  * @DPU_IRQ_TYPE_WB_ROT_COMP:  WB rotator done
@@ -96,18 +89,6 @@ enum dpu_intr_type {
  */
 struct dpu_hw_intr_ops {
/**
-* set_mask - Programs the given interrupt register with the
-*given interrupt mask. Register value will get overwritten.
-* @intr:   HW interrupt handle
-* @reg_off:MDSS HW register offset
-* @irqmask:IRQ mask value
-*/
-   void (*set_mask)(
-   struct dpu_hw_intr *intr,
-   uint32_t reg,
-   uint32_t irqmask);
-
-   /**
 * irq_idx_lookup - Lookup IRQ index on the HW interrupt type
 * Used for all irq related ops
 * @intr_type:  Interrupt type defined in dpu_intr_type
@@ -177,16 +158,6 

[Bug 202019] New: amdgpu: fan speed reported incorrectly when the fan is off

[bugzilla-daemon]

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

Bug ID: 202019
   Summary: amdgpu: fan speed reported incorrectly when the fan is
off
   Product: Drivers
   Version: 2.5
Kernel Version: 4.20-rc7
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: mezin.alexan...@gmail.com
Regression: No

I have a card with semi-passive cooling (Sapphire RX Vega 64 Nitro+)
When the fan turns off, non-zero speed is still reported through hwmon
fan1_input.
If I'm not mistaken, the same problem was present with my previous card -
Sapphire RX 580 Pulse (so I guess it's the same for all cards).

On Windows zero rpm was correctly reported for both cards, of course.

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

Re: [PATCH] drm/i915: Update crtc scaler settings when update_pipe is set

[Maarten Lankhorst]

Op 17-12-2018 om 15:19 schreef Hans de Goede:
> When the pipe_config's update_pipe flag is set we may need to update the
> panel fitting settings. On GEN9+ this means we need to update the crtc's
> scaler settings.
>
> This fixes the following WARN_ON, during i915 loading on an Asrock
> B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
>
> [drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
>  (expected no, found yes)
> pipe state doesn't match!
> WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084
>
> With line 12084 being the I915_STATE_WARN call inside the
> "if (!intel_pipe_config_compare())" block in verify_crtc_state().
>
> On this board with 2 1920x1080 monitors connected over HDMI the GOP
> initializes both monitors at 1920x1080 and despite no scaling being
> necessary configures a scaler for one of them.
>
> When booting with fastboot=1 on the initial modeset needs_modeset will
> be false while update_pipe is true. Since we were not calling
> skl_update_scaler_crtc() in this case we would leave the scaler enabled
> causing this error.
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 62df34d30b1f..df32626e0810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10919,7 +10919,7 @@ static int intel_crtc_atomic_check(struct drm_crtc 
> *crtc,
>   }
>  
>   if (INTEL_GEN(dev_priv) >= 9) {
> - if (mode_changed)
> + if (mode_changed || pipe_config->update_pipe)
>   ret = skl_update_scaler_crtc(pipe_config);
>  
>   if (!ret)

Hey,

Pushed.

You might also be interested in this patch / series, would be nice to have a 
review on it.

https://patchwork.freedesktop.org/patch/268410/

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

[GIT PULL] etnaviv-next for 4.21 revamp

[Lucas Stach]

Hi Daniel, Dave,

updated pull request with Christian's review added below.

Regards,
Lucas

The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0:

  drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 
18:14:48 +0100)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/next

for you to fetch changes up to 801c7a1e528623f073c4007cb04d9a817e33b3a4:

  drm/etnaviv: remove lastctx member from gpu struct (2018-12-18 11:55:16 +0100)


Lucas Stach (5):
  drm/etnaviv: kill active fence tracking
  drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
  drm/etnaviv: remove unnecessary local irq disable
  drm/etnaviv: replace header include with forward declaration
  drm/etnaviv: remove lastctx member from gpu struct

Thomas Zimmermann (1):
  drm/etnaviv: Replace drm_dev_unref with drm_dev_put

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  2 --
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 
-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++--
 5 files changed, 23 insertions(+), 55 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer

[Andrzej Hajda]

On 18.12.2018 10:53, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday, 18 December 2018 11:39:22 EET Daniel Vetter wrote:
>> On Mon, Sep 17, 2018 at 5:49 PM Sean Paul  wrote:
>>> On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote:
 I have moved on to other stuff for now. Haven't been able to make time
 to review bridge related work. Andrzej has been doing it by himself
 for a while now.

 Cc: Andrzej Hajda 
 Cc: Laurent Pinchart 
 Cc: Gustavo Padovan 
 Cc: Maarten Lankhorst 
 Cc: Sean Paul 
 Cc: Daniel Vetter 
 Signed-off-by: Archit Taneja 
>>> Sorry to see you taking a less active role, Archit. Hopefully you'll stick
>>> around on IRC and find some cycles for us in the future!
>>>
>>> Acked-by: Sean Paul 
>> No one seems to have pushed this ...
> Where did the magic go wrong ? :-)


Fixed, ie queued to drm-misc-next.


>
>> Also might be good to find another bridge maintainer?
> Totally agreed.


Also agreed.


Regards

Andrzej


>
 ---

  MAINTAINERS | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 9d9068ed4ee5..7ed01e227684 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -4793,7 +4793,6 @@ F: 
 Documentation/devicetree/bindings/display/atmel/> > 
  T:   git git://anongit.freedesktop.org/drm/drm-misc
  
  DRM DRIVERS FOR BRIDGE CHIPS
 -M:   Archit Taneja 
  M:   Andrzej Hajda 
  R:   Laurent Pinchart 
  S:   Maintained


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