Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Rodrigo Vivi]

On Wed, Feb 07, 2018 at 09:32:35PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
> > On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> > > > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> > > > return type for drm_crtc_vblank_count() to u64. This could cause
> > > > potential problems if the return value is used in arithmetic operations
> > > > with a 32-bit reference HW vblank count. Explicitly typecasting this
> > > > down to u32 either fixes a potential problem or serves to add clarity in
> > > > case the implicit typecasting was already correct.
> > > > 
> > > > Cc: Keith Packard 
> > > > Cc: Thierry Reding 
> > > 
> > > 
> > > Thierry, 
> > > 
> > > Can I get an Ack on this please? 
> > > 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/tegra/dc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > > > index b8403ed48285..49df2db2ad46 100644
> > > > --- a/drivers/gpu/drm/tegra/dc.c
> > > > +++ b/drivers/gpu/drm/tegra/dc.c
> > > > @@ -1359,7 +1359,7 @@ static u32 tegra_dc_get_vblank_counter(struct 
> > > > drm_crtc *crtc)
> > > > return host1x_syncpt_read(dc->syncpt);
> > > >  
> > > > /* fallback to software emulated VBLANK counter */
> > > > -   return drm_crtc_vblank_count(>base);
> > > > +   return (u32)drm_crtc_vblank_count(>base);
> > 
> > Isn't this the wrong way around? Shouldn't we instead make the
> > ->get_vblank_counter() callback return u64 like drm_crtc_vblank_count()?
> 
> Here's how I understand this - 
> 
> To use the software emulated vblank counter, the driver should set
> max_vblank_count = 0 and the core takes care of calculating elapsed
> vblanks.
> 
> ->get_vblank_counter() is meant to return the hardware counter if
> available, which would be a 32-bit value. Hence the explicit typecast to
> 32-bit for the fallback case too.
> 
> Having said that, I believe drm_crtc_accurate_vblank_count() is the
> appropriate function for fallback.

Hi Thierry,

any further concerns or thoughts here?

I'd like to merge all together on drm-intel since the ones
around us is kind of blocking us.

Thanks,
Rodrigo.

> 
> -DK
> 
> 
> 
> > 
> > Thierry
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers

[Tomasz Figa]

Hi Vivek,

On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
 wrote:
> The device link allows the pm framework to tie the supplier and
> consumer. So, whenever the consumer is powered-on the supplier
> is powered-on first.
>
> There are however cases in which the consumer wants to power-on
> the supplier, but not itself.
> E.g., A Graphics or multimedia driver wants to power-on the SMMU
> to unmap a buffer and finish the TLB operations without powering
> on itself.

This sounds strange to me. If the SMMU is powered down, wouldn't the
TLB lose its contents as well (and so no flushing needed)?

Other than that, what kind of hardware operations would be needed
besides just updating the page tables from the CPU?

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Pekka Paalanen]

On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann  wrote:

>   Hi,
> 
> > >(a) software rendering: client allocates shared memory buffer, renders
> > >into it, then passes a file handle for that shmem block together
> > >with some meta data (size, format, ...) to the wayland server.
> > > 
> > >(b) gpu rendering: client opens a render node, allocates a buffer,
> > >asks the cpu to renders into it, exports the buffer as dma-buf
> > >(DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> > >(again including meta data of course).
> > > 
> > > Is that correct?  
> > 
> > Both are correct descriptions of typical behaviors. But it isn't spec'ed
> > anywhere who has to do the buffer allocation.  
> 
> Well, according to Pekka's reply it is spec'ed that way, for the
> existing buffer types.  So for server allocated buffers you need
> (a) a wayland protocol extension and (b) support for the extension
> in the clients.

Correct. Or simply a libEGL that uses such Wayland extension behind
everyone's back. I believe such things did at least exist, but are
probably not relevant for this discussion.

(If there is a standard library, like libEGL, loaded and used by both a
server and a client, that library can advertise custom private Wayland
protocol extensions and the client side can take advantage of them,
both without needing any code changes on either the server or the
client.)

> We also need a solution for the keymap shmem block.  I guess the keymap
> doesn't change all that often, so maybe it is easiest to just copy it
> over (host proxy -> guest proxy) instead of trying to map the host shmem
> into the guest?

Yes, I believe that would be a perfectly valid solution for that
particular case.


Thanks,
pq


pgpSHhp3YxQZz.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #7 from arne_woer...@yahoo.com ---
4.15.3-1-ARCH has that bug, too... -arne

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

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

[Dan Carpenter]

On Mon, Feb 12, 2018 at 06:11:57PM +, Kieran Bingham wrote:
> + adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
> + ADV7511_PACKET_I2C_ADDR_DEFAULT);
> + if (!adv7511->i2c_packet) {
> + ret = -EINVAL;
> + goto err_unregister_cec;
> + }
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
> +  adv7511->i2c_packet->addr << 1);
> +
>   INIT_WORK(>hpd_work, adv7511_hpd_work);
>  
>   if (i2c->irq) {
> @@ -1181,7 +1190,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
> struct i2c_device_id *id)
>   IRQF_ONESHOT, dev_name(dev),
>   adv7511);
>   if (ret)
> - goto err_unregister_cec;
> + goto err_unregister_packet;
>   }
>  
>   adv7511_power_off(adv7511);

There is another goto which needs to be updated if adv7511_cec_init()
fails.

> @@ -1203,6 +1212,8 @@ static int adv7511_probe(struct i2c_client *i2c, const 
> struct i2c_device_id *id)
>   adv7511_audio_init(dev, adv7511);
>   return 0;
>  
> +err_unregister_packet:
> + i2c_unregister_device(adv7511->i2c_packet);
>  err_unregister_cec:
>   i2c_unregister_device(adv7511->i2c_cec);
>   if (adv7511->cec_clk)


regards,
dan carpenter

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

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

[Nautiyal, Ankit K]

Hi Ville,

As per our last discussion, following points were discussed:

1. To suppress the aspect-ratio info from getblob ioctl to a user that 
does not support it:


i. A new flag must be added to drm_blob_property to mark if the 
blob has mode data.


ii. This flag must be set when the user tries do an atomic modeset.

iii. In the getblob ioctl, based on the above flag, it can be 
determined that if the blob


has mode data, and the aspect ratio info can be suppressed in 
getblob ioctl, if user does not support it.


2. Instead of adding aspect ratio capabilities in drm_atomic_state, pass 
on the file_priv which already has


the required information to the function drm_mode_convert_umode.

It will require addition of an new argument file_priv to several 
functions, but that is right thing to do,


as file_priv is the correct structure for the capability information.

3. Changing the usermode aspect ratio flag bits, without change in the
picture_aspect_ratio would not matter, and does not need to be handled 
in this patch.



I just have one query here. We have agreed to modify 
drm_mode_convert_umode, to filter out the aspect-ratio


info if user has not set aspect-ratio capability, but do we need a 
similar change the drm_mode_convert_to_umode?


If we do, I am not sure if it would be possible to have the file_priv to 
/drm_atomic_set_mode_for_crtc/, which calls


drm_mode_convert_to_umode.  The function /drm_atomic_set_mode_for_crtc/ 
is used to set mode, originating by kernel,


and make a blob from the kernel mode, which it saves in crtc_state.

This function /: drm_atomic_set_mode_for_crtc, /is called by several 
helper functions and driver functions, and passing


file_priv from all these functions does not seem to be plausible.

Any suggestions on how to handle this situation?


Regards,

Ankit


On 2/8/2018 9:59 AM, Nautiyal, Ankit K wrote:

Hi Ville,

I still have some queries regarding the handling of aspect ratio flags 
in getblob ioctl.


Please find below my responses inline.


On 2/1/2018 6:24 PM, Ville Syrjälä wrote:

On Thu, Feb 01, 2018 at 04:35:22PM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

Appreciate your time and the suggestions.
Please find my response inline:

On 1/31/2018 6:39 PM, Ville Syrjälä wrote:

On Wed, Jan 31, 2018 at 12:04:52PM +0530, Nautiyal, Ankit K wrote:

On 1/30/2018 12:23 AM, Ville Syrjälä wrote:

On Fri, Jan 12, 2018 at 11:51:33AM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

If the user mode does not support aspect-ratio, and requests for
a modeset, then the flag bits representing aspect ratio in the
given user-mode must be rejected.
Similarly, while preparing a user-mode from kernel mode, the
aspect-ratio info must not be given, if aspect-ratio is not
supported by the user.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
preparing kernel mode structure, during modeset, if the
user does not support aspect ratio.
3. avoids setting the aspect-ratio info in user-mode, while
converting user-mode from the kernel-mode.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
-Do not corrupt the current crtc state by updating aspect ratio
on the fly.
---
drivers/gpu/drm/drm_atomic.c | 61 
+---

drivers/gpu/drm/drm_crtc.c   | 19 ++
include/drm/drm_atomic.h |  2 ++
3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c 
b/drivers/gpu/drm/drm_atomic.c

index 69ff763..39313e2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -316,6 +316,35 @@ static s32 __user 
*get_out_fence_for_crtc(struct drm_atomic_state *state,

return fence_ptr;
}
+/**
+ * drm_atomic_allow_aspect_ratio_for_kmode
+ * @state: the crtc state
+ * @mode: kernel-internal mode, which is used to create a 
duplicate mode,

+ * with updated picture aspect ratio.
+ *
+ * Allow the aspect ratio info in the kernel mode only if 
aspect ratio is

+ * supported.
+ *
+ * RETURNS:
+ * kernel-internal mode with updated picture aspect ratio value.
+ */
+
+struct drm_display_mode*
+drm_atomic_allow_aspect_ratio_for_kmode(struct drm_crtc_state 
*state,

+const struct drm_display_mode *mode)
+{
+struct drm_atomic_state *atomic_state = state->state;
+struct drm_display_mode *ar_kmode;
+
+ar_kmode = drm_mode_duplicate(state->crtc->dev, mode);
+/*
+ * If aspect ratio is not supported, set the picture aspect 
ratio as

+ * NONE.
+ */
+if (atomic_state && !atomic_state->allow_aspect_ratio)
+ar_kmode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+return ar_kmode;
+}
/**
 * drm_atomic_set_mode_for_crtc - set mode for CRTC
@@ -341,7 +370,10 @@ 

Re: [RFC][PATCH 4/4 v2] drm_hwcomposer: Try to fallback if GLCompisition fails

[John Stultz]

On Wed, Jan 31, 2018 at 11:03 AM, John Stultz  wrote:
> On Wed, Jan 31, 2018 at 10:51 AM, Alexandru-Cosmin Gheorghe
>  wrote:
>> It seems that we don't pass any explicit fences to the kernel for
>> IN_FENCE_FD property. This particular line seems wrong.
>>
>> @@ -593,14 +594,17 @@ int
>> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>>else
>>  rotation |= DRM_MODE_ROTATE_0;
>>
>> -  if (fence_fd < 0) {
>> +  if (fence_fd >= 0) {
>
> I'll give that a whirl.

So I did give that a whirl after you suggested it, but it ended up
causing nothing to be displayed, and I unfortunately didn't have time
right then to dig much further.

Rob however re-found this issue today, and I've been digging a bit
more. At least with the HiKey board, it seem the trouble is when the
IN_FENCE_FD is added to the pset, the atomic commit calls start to
fail. I dug in and it seems we're catching in the kernel on the  if
(file->f_op != _file_fops) check in sync_file_fdget().

I'm now trying to trace back to where the in fence was provided from
to see what might be going wrong there.

Curious if this is anything you ran across in your attempts?

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

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

[bugzilla-daemon]

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

--- Comment #7 from L.S.S.  ---
And I just crashed my system the same usual way. With those parameters set
there are some additional outputs besides the usual ones.

Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:handle_cursor_update.isra.22 [amdgpu]]
handle_cursor_update: crtc_id=0 with size 128 to 128
Feb 13 11:31:55 linuxsys kernel: [drm:dm_plane_helper_prepare_fb [amdgpu]] No
FB bound
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:handle_cursor_update.isra.22 [amdgpu]]
handle_cursor_update: crtc_id=0 with size 0 to 0
Feb 13 11:31:55 linuxsys kernel: [drm:dm_plane_helper_prepare_fb [amdgpu]] No
FB bound
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:handle_cursor_update.isra.22 [amdgpu]]
handle_cursor_update: crtc_id=0 with size 128 to 128
Feb 13 11:31:55 linuxsys kernel: [drm:best_encoder [amdgpu]] Finding the best
encoder
Feb 13 11:31:55 linuxsys kernel: [drm:best_encoder [amdgpu]] Finding the best
encoder
Feb 13 11:31:55 linuxsys kernel: [drm:update_stream_scaling_settings [amdgpu]]
Destination Rectangle x:0  y:0  width:1920  height:1080
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting mode_changed to 0
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:0,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:best_encoder [amdgpu]] Finding the best
encoder
Feb 13 11:31:55 linuxsys kernel: [drm:best_encoder [amdgpu]] Finding the best
encoder
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_planes_state.part.28 [amdgpu]]
Disabling DRM plane: 36 on DRM crtc 43
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:0,
mode_changed:0,active_changed:1,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Disabling
DRM crtc: 43
Feb 13 11:31:55 linuxsys kernel: [drm:update_stream_scaling_settings [amdgpu]]
Destination Rectangle x:0  y:0  width:1920  height:1080
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting mode_changed to 0
Feb 13 11:31:55 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:0,
mode_changed:0,active_changed:1,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:1,
mode_changed:0,active_changed:1,connectors_changed:0
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
Atomic commit: RESET. crtc id 0:[0ce1e17c]
Feb 13 11:31:55 linuxsys kernel: [drm] dc_commit_state: 0 streams
Feb 13 11:31:55 linuxsys kernel: [drm] hwss_edp_backlight_control: backlight
action: Off
Feb 13 11:31:55 linuxsys kernel: [drm] hwss_edp_backlight_control: backlight
action: Off
Feb 13 11:31:55 linuxsys kernel: [drm:amdgpu_vm_init [amdgpu]] VM update mode
is SDMA
Feb 13 11:31:55 linuxsys kernel: [drm] hwss_edp_backlight_control: backlight
action: Off
Feb 13 11:31:55 linuxsys kernel: [drm] hwss_edp_power_control: Panel Power
action: Off
Feb 13 11:31:56 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting mode_changed to 0
Feb 13 11:31:56 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:56 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting mode_changed to 0
Feb 13 11:31:56 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:56 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting mode_changed to 0
Feb 13 11:31:56 linuxsys kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]]
amdgpu_crtc id:0 crtc_state_flags: enable:1, active:0, planes_changed:1,
mode_changed:0,active_changed:0,connectors_changed:0
Feb 13 11:31:56 linuxsys kernel: [drm:dm_update_crtcs_state [amdgpu]] Mode
change not required, setting 

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

[bugzilla-daemon]

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

--- Comment #6 from L.S.S.  ---
Created attachment 137308
  --> https://bugs.freedesktop.org/attachment.cgi?id=137308=edit
dmesg output with amdgpu.dc_log=1 and drm.debug=6, right after login.

I'm not sure to what extent is a "full" dmesg. Attached is the dmesg I exported
right after startup, with the above parameters passed.

-- 
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] virgl: fix caps ioctl size check.

[Stéphane Marchesin]

On Mon, Feb 12, 2018 at 4:26 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The size check seems backwards, if userspace gives us a size
> larger it is probably asking for a newer version of the caps,
> so we just fill in the caps version we have at the smaller
> size, and it can work it out from there.
>
> Userspace will probably still need a fallback as old
> kernel are out there.
>
> Cc: 
> Signed-off-by: Dave Airlie 

Reviewed-by: Stéphane Marchesin 

Thanks!

> ---
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 5720a0d4ac0a..5d5f79508100 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -497,7 +497,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device 
> *dev,
> }
>
> size = vgdev->capsets[found_valid].max_size;
> -   if (args->size > size) {
> +   if (size > args->size) {
> spin_unlock(>display_info_lock);
> return -EINVAL;
> }
> --
> 2.14.3
>
> ___
> 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] virgl: fix caps ioctl size check.

[Dave Airlie]

From: Dave Airlie 

The size check seems backwards, if userspace gives us a size
larger it is probably asking for a newer version of the caps,
so we just fill in the caps version we have at the smaller
size, and it can work it out from there.

Userspace will probably still need a fallback as old
kernel are out there.

Cc: 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 5720a0d4ac0a..5d5f79508100 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -497,7 +497,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
}
 
size = vgdev->capsets[found_valid].max_size;
-   if (args->size > size) {
+   if (size > args->size) {
spin_unlock(>display_info_lock);
return -EINVAL;
}
-- 
2.14.3

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

Re: [PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension

[Dylan Baker]

Quoting Keith Packard (2018-02-09 20:45:15)
> This extension adds a single function to query the current GPU
> timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
> function is needed to complete the implementation of
> GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
> timestamps.
> 
> Signed-off-by: Keith Packard 
> ---
>  include/vulkan/vulkan.h |  6 ++
>  src/Makefile.am |  1 +
>  src/amd/vulkan/Makefile.am  |  3 +++
>  src/amd/vulkan/meson.build  |  8 
>  src/amd/vulkan/radv_device.c|  8 
>  src/amd/vulkan/radv_extensions.py   |  1 +
>  src/intel/Makefile.vulkan.am|  7 +++
>  src/intel/vulkan/anv_extensions.py  |  1 +
>  src/intel/vulkan/anv_gem.c  | 13 +
>  src/intel/vulkan/anv_private.h  |  1 +
>  src/intel/vulkan/genX_query.c   | 15 +++
>  src/intel/vulkan/meson.build| 12 ++--
>  src/vulkan/meson.build  |  1 +
>  src/vulkan/registry/vk_mesa_query_timestamp.xml | 22 ++
>  14 files changed, 89 insertions(+), 10 deletions(-)
>  create mode 100644 src/vulkan/registry/vk_mesa_query_timestamp.xml
> 
> diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
> index d3e2e246cf3..5523eb7586f 100644
> --- a/include/vulkan/vulkan.h
> +++ b/include/vulkan/vulkan.h
> @@ -7025,6 +7025,12 @@ VKAPI_ATTR VkResult VKAPI_CALL 
> vkGetMemoryHostPointerPropertiesEXT(
>  VkMemoryHostPointerPropertiesEXT*   
> pMemoryHostPointerProperties);
>  #endif
>  
> +typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(VkDevice 
> device, uint64_t *timestamp);
> +
> +VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
> +VkDevice_device,
> +uint64_t*timestamp);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 014ffaf3e29..74ff305d7c6 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -68,6 +68,7 @@ endif
>  
>  EXTRA_DIST += vulkan/registry/vk.xml
>  EXTRA_DIST += vulkan/registry/vk_android_native_buffer.xml
> +EXTRA_DIST += vulkan/registry/vk_mesa_query_timestamp.xml
>  
>  if HAVE_AMD_DRIVERS
>  SUBDIRS += amd
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index 94ece06e99e..0626fa2b3b3 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -129,12 +129,14 @@ libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
>  
>  vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
>  vk_android_native_buffer_xml = 
> $(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
> +vk_mesa_query_timestamp_xml = 
> $(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamps.xml
>  
>  radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
> $(vulkan_api_xml)
> $(MKDIR_GEN)
> $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
> --xml $(vulkan_api_xml) \
> --xml $(vk_android_native_buffer_xml) \
> +   --xml $(vk_mesa_query_timestamp_xml) \
> --outdir $(builddir)
>  radv_entrypoints.h: radv_entrypoints.c
>  
> @@ -144,6 +146,7 @@ radv_extensions.c: radv_extensions.py \
> $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
> --xml $(vulkan_api_xml) \
> --xml $(vk_android_native_buffer_xml) \
> +   --xml $(vk_mesa_query_timestamp_xml) \
> --out $@
>  
>  vk_format_table.c: vk_format_table.py \
> diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
> index 0b92a1763a1..34f578476c0 100644
> --- a/src/amd/vulkan/meson.build
> +++ b/src/amd/vulkan/meson.build
> @@ -20,10 +20,10 @@
>  
>  radv_entrypoints = custom_target(
>'radv_entrypoints.[ch]',
> -  input : ['radv_entrypoints_gen.py', vk_api_xml],
> +  input : ['radv_entrypoints_gen.py', vk_api_xml, 
> vk_android_native_buffer_xml, vk_mesa_query_timestamp_xml],

some of these lines look a little long, 
input : [
'radv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml,
vk_mesa_query_timestamp_xml,
],

>output : ['radv_entrypoints.h', 'radv_entrypoints.c'],
>command : [
> -prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--outdir',
> +prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
> '--xml', '@INPUT3@', '--outdir',
>  meson.current_build_dir()
>],
>depend_files : files('radv_extensions.py'),
> @@ -31,10 +31,10 @@ radv_entrypoints = custom_target(
>  
>  radv_extensions_c = custom_target(
>'radv_extensions.c',
> -  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml],
> +  input : ['radv_extensions.py', vk_api_xml, 

Re: [PATCH 3/7] vulkan: Add EXT_acquire_xlib_display

[Dylan Baker]

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

You could simplify this to
with_xlib_lease = with_platform_x11 and with_platform_display

> +elif with_xlib_lease == 'true'

We should probably error here if we don't have the correct platforms.

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

[Bug 68857] [cypress] SNU OpenCL NAS Parallel Benchmarks don't work

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

Summary|SNU OpenCL NAS Parallel |[cypress] SNU OpenCL NAS
   |Benchmarks don't work   |Parallel Benchmarks don't
   ||work

-- 
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 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.li...@gmail.com

--- Comment #4 from Andy Furniss  ---
I filed a "game hangs" llvm regression here -

https://bugs.llvm.org/show_bug.cgi?id=36332

-- 
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 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

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

--- Comment #3 from Bas Nieuwenhuizen  ---
There is a git mirror for LLVM:

https://github.com/llvm-mirror/llvm

wrt the nir crash I doubt that is due to LLVM, might be because we only enabled
compute shaders for nir somewhat recently.

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

Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Emil Velikov  writes:

> A few top level comments:

Thanks much for looking over this code. I realize it's a large amount of
change and hence more work to review.

>  - using card/primary node and (missing) authentication
> Current code opens the primary node when VK_KHR_display is available.
> Thus running a platform=drm,x11,wayland build will fail, as the client
> is not authenticated with the X/WL server.

this is really mostly there to make it easy to test the KHR_display
backend without needing any further code. I added this only recently for
this purpose. I'm not sure how we should be selecting for opening the
primary device; perhaps another extension that adds a block in the pNext
chain to look for?

I don't know if you saw the first version of this series, but I had
specified a new extension which provided the device FD from the
application, letting you pass in whatever you could open (including a
leased FD from X or a primary opened from the application). That seems
like it could use some design ideas so we can make this do what we
want.

One option would be to remove the primary device code from the drivers
once the leasing code is added so that the only way to use KHR_display
is by leasing resources from the window system?

The radv driver goes a bit further and checks with the kernel to see if
rendering will work. For anv, the ioctls necessary for drawing are
permitting on a non-authenticated node. Both drivers work fine for
direct and X as-is, but I'm not very happy with having a random app with
the primary device open as that seems like a mistake waiting to happen.

>  - reuse "drm" as a shorthand for the "display"
> We've been using drm for egl/gbm, va/drm, etc, one less platform plus
> no equivalent in either of egl/va/...

Yeah, anything that supports drm can support display. I'll review the
build process and try to simplify it further.

>  - remove conditional compilation based on library version/features.
> Eg. checks like the following should be avoided.
> #if DRM_EVENT_CONTEXT_VERSION

Should I just have the build depend on a recent enough version of the library?

>  - use drmModeAddFB2 (or the withModifiers version even) over drmModeAddFB
> Might help with the XXX just above it ;-)

It won't help with that -- I just need more information from the
driver. However, that information could come back as a format instead of
depth/bpp, which would mean using drmModeAddFB2 instead of
drmModeAddFB. Thanks for reminding me of this XXX.  wsi_create_*_image
gets a VkSwapchainCreateInfoKHR which has a VkFormat inside. Is that
sufficient to compute a fourcc format for AddFB2? I think I could
probably guess depth/bpp from it and be right most of the time?

>  - the spec says we're at VK_KHR_display rev 21, while the code advertises 
> rev1
> Extension('VK_KHR_display',   1,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),

Thanks. The version of the spec I've got (1.0.49) says it's already at
rev 23!

>  - there are plenty of unnecessary of headers #include(d)

As is often the case. I can go trim things down.

>  - we could simplify the ifdef spaghetti by making
> wsi_*_{init,finish}_wsi empty stubs
> Definitely something that can be done, independently of your work.

That would be lovely.

-- 
-keith


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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Eric Engestrom  writes:

> copy/paste error: s/drm/display/

That's actually intentional -- any system which supports 'drm' can
support the display backend as it's based on that. Maybe it should use a
different test? (note that I haven't been using the autotools backend
recently, so it may not be great at this point. At least my current tree
builds?)

>> +if with_platform_display
>> +  radv_flags += [
>> +'-DVK_USE_PLATFORM_DISPLAY_KHR',
>> +  ]
>
> Nit: this can be a simple
>   radv_flags += '-DVK_USE_PLATFORM_DISPLAY_KHR'
>
>> +if with_platform_display
>> +  vulkan_wsi_args += [
>> +'-DVK_USE_PLATFORM_DISPLAY_KHR',
>> +  ]
>
> Ditto:
>   vulkan_wsi_args += '-DVK_USE_PLATFORM_DISPLAY_KHR'


Oh, good point -- I'd split out the RANDR and DISPLAY bits but didn't
simplify the meson stuff.

> Nit: src/amd/vulkan/ uses tabs for indent, you used spaces.

Thanks; I'll reconfigure my environment so that it uses tabs in that
directory, and re-indent the changes.

>> +#define MM_PER_PIXEL (1.0/96.0 * 25.4)
>
> unused

Good catch; those got left in both anv and radv directories after some
refactoring.

>> +#if 0
>
> `#if DEBUG` maybe?

Could do; I could also just strip out the printf debugging, but when
you're doing timing-sensitive stuff at that level, printf debugging is
pretty useful.

>> +#define wsi_display_debug(...) fprintf(stderr, __VA_ARGS__)
>> +#define wsi_display_debug_code(...) __VA_ARGS__
>
> that 2nd one is unused

It gets used in a later patch.

>> +   if (wsi) {
>
> if (!wsi) return;
> and carry on without the extra indent

Yeah, would probably look cleaner.

> I don't know enough for this to be an actual review though, but the rest
> of this file looks reasonable to me :)

Thanks for reviewing the basic formatting and structure though; I
totally missed the tabs/spaces issue.

-- 
-keith


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

Re: [PATCH hwc v2 3/6] drm_hwcomposer: Submit in-fence to DRM

[Rob Herring]

On Wed, Sep 27, 2017 at 1:55 PM, Sean Paul  wrote:
> On Wed, Sep 27, 2017 at 7:58 AM, Robert Foss  
> wrote:
>> Add support for in-fences through the IN_FENCE_FD property. In-fences signal
>> when their associated buffer may be read by DRM/KMS.
>>
>> Signed-off-by: Robert Foss 
>> ---
>>  drmdisplaycompositor.cpp | 35 ---
>>  1 file changed, 16 insertions(+), 19 deletions(-)
>>
>> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
>> index bd670cf..71c0451 100644
>> --- a/drmdisplaycompositor.cpp
>> +++ b/drmdisplaycompositor.cpp
>> @@ -529,6 +529,7 @@ int 
>> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>>  std::vector _layers = comp_plane.source_layers();
>>
>>  int fb_id = -1;
>> +int fence_fd = -1;
>>  DrmHwcRect display_frame;
>>  DrmHwcRect source_crop;
>>  uint64_t rotation = 0;
>> @@ -547,30 +548,12 @@ int 
>> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>>  break;
>>}
>>DrmHwcLayer  = layers[source_layers.front()];
>> -  if (!test_only && layer.acquire_fence.get() >= 0) {
>> -int acquire_fence = layer.acquire_fence.get();
>> -int total_fence_timeout = 0;
>> -for (int i = 0; i < kAcquireWaitTries; ++i) {
>> -  int fence_timeout = kAcquireWaitTimeoutMs * (1 << i);
>> -  total_fence_timeout += fence_timeout;
>> -  ret = sync_wait(acquire_fence, fence_timeout);
>> -  if (ret)
>> -ALOGW("Acquire fence %d wait %d failed (%d). Total time %d",
>> -  acquire_fence, i, ret, total_fence_timeout);
>> -  else
>> -break;
>> -}
>> -if (ret) {
>> -  ALOGE("Failed to wait for acquire %d/%d", acquire_fence, ret);
>> -  break;
>> -}
>> -layer.acquire_fence.Close();
>> -  }
>>if (!layer.buffer) {
>>  ALOGE("Expected a valid framebuffer for pset");
>>  break;
>>}
>>fb_id = layer.buffer->fb_id;
>> +  fence_fd = layer.acquire_fence.get();
>>display_frame = layer.display_frame;
>>source_crop = layer.source_crop;
>>if (layer.blending == DrmHwcBlending::kPreMult)
>> @@ -587,7 +570,21 @@ int 
>> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>>  rotation |= 1 << DRM_ROTATE_180;
>>else if (layer.transform & DrmHwcTransform::kRotate270)
>>  rotation |= 1 << DRM_ROTATE_270;
>> +
>> +  if (fence_fd != -1) {
>
> nit: if (fence_fd < 0)

Your nit is a bug. :) We're checking for if a valid fd. I think this
may be John's issue with needing a glFinish().

A fix is coming.

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

[PATCH v3 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Kieran Bingham 
---
v2:
 - Update missing edid-i2c address setting
 - Split out DT bindings
 - Rename and move the I2C default addresses to their own section

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 ++--
 2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..04e6759ee45b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -93,6 +93,11 @@
 #define ADV7511_REG_CHIP_ID_HIGH   0xf5
 #define ADV7511_REG_CHIP_ID_LOW0xf6
 
+/* Hardware defined default addresses for i2c register maps */
+#define ADV7511_CEC_I2C_ADDR_DEFAULT   0x3c
+#define ADV7511_EDID_I2C_ADDR_DEFAULT  0x3f
+#define ADV7511_PACKET_I2C_ADDR_DEFAULT0x38
+
 #define ADV7511_CSC_ENABLE BIT(7)
 #define ADV7511_CSC_UPDATE_MODEBIT(5)
 
@@ -322,6 +327,7 @@ struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
struct i2c_client *i2c_cec;
+   struct i2c_client *i2c_packet;
 
struct regmap *regmap;
struct regmap *regmap_cec;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..5e61b928c9c0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
unsigned int edid_i2c_addr =
-   (adv7511->i2c_main->addr << 1) + 4;
+   (adv7511->i2c_edid->addr << 1);
 
__adv7511_power_on(adv7511);
 
@@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
 {
int ret;
 
-   adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
-adv->i2c_main->addr - 1);
+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_CEC_I2C_ADDR_DEFAULT);
if (!adv->i2c_cec)
-   return -ENOMEM;
+   return -EINVAL;
i2c_set_clientdata(adv->i2c_cec, adv);
 
adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
-   unsigned int main_i2c_addr = i2c->addr << 1;
-   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
 
@@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
goto uninit_regulators;
 
-   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
-   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-main_i2c_addr - 0xa);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
-main_i2c_addr - 2);
-
adv7511_packet_disable(adv7511, 0x);
 
-   adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
+   adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+   ADV7511_EDID_I2C_ADDR_DEFAULT);
if (!adv7511->i2c_edid) {
-   ret = -ENOMEM;
+   ret = -EINVAL;
goto uninit_regulators;
}
 
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+adv7511->i2c_edid->addr << 1);
+
ret = adv7511_init_cec_regmap(adv7511);
if (ret)
goto err_i2c_unregister_edid;
 
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
+adv7511->i2c_cec->addr << 1);
+
+   adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+   ADV7511_PACKET_I2C_ADDR_DEFAULT);
+   if (!adv7511->i2c_packet) {
+   ret = -EINVAL;
+   goto err_unregister_cec;
+   }
+
+   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
+adv7511->i2c_packet->addr << 1);
+
  

[PATCH v3 2/5] dt-bindings: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
---
v2:
 - Fixed up reg: property description to account for multiple optional
   addresses.
 - Minor reword to commit message to account for DT only change
 - Collected Robs RB tag

v3:
 - Split map register addresses into individual declarations.

 .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..3f85c351dd39 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -14,7 +14,13 @@ Required properties:
"adi,adv7513"
"adi,adv7533"
 
-- reg: I2C slave address
+- reg: I2C slave addresses
+  The ADV7511 internal registers are split into four pages exposed through
+  different I2C addresses, creating four register maps. Each map has it own
+  I2C address and acts as a standard slave device on the I²C bus. The main
+  address is mandatory, others are optional and revert to defaults if not
+  specified.
+
 
 The ADV7511 supports a large number of input data formats that differ by their
 color depth, color format, clock mode, bit justification and random
@@ -70,6 +76,9 @@ Optional properties:
   rather than generate its own timings for HDMI output.
 - clocks: from common clock binding: reference to the CEC clock.
 - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
 
 Required nodes:
 
@@ -88,7 +97,12 @@ Example
 
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the i2c
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39>, <0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;
-- 
2.7.4

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

[PATCH v3 4/5] media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - Split out DT bindings from driver updates
 - Return -EINVAL on error paths from adv76xx_dummy_client()

 drivers/media/i2c/adv7604.c | 62 +
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 1544920ec52d..872e124793f8 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2734,6 +2734,27 @@ static const struct v4l2_ctrl_config 
adv76xx_ctrl_free_run_color = {
 
 /* --- */
 
+struct adv76xx_register {
+   const char *name;
+   u8 default_addr;
+};
+
+static const struct adv76xx_register adv76xx_secondary_names[] = {
+   [ADV76XX_PAGE_IO] = { "main", 0x4c },
+   [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
+   [ADV76XX_PAGE_CEC] = { "cec", 0x40 },
+   [ADV76XX_PAGE_INFOFRAME] = { "infoframe", 0x3e },
+   [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
+   [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
+   [ADV76XX_PAGE_AFE] = { "afe", 0x26 },
+   [ADV76XX_PAGE_REP] = { "rep", 0x32 },
+   [ADV76XX_PAGE_EDID] = { "edid", 0x36 },
+   [ADV76XX_PAGE_HDMI] = { "hdmi", 0x34 },
+   [ADV76XX_PAGE_TEST] = { "test", 0x30 },
+   [ADV76XX_PAGE_CP] = { "cp", 0x22 },
+   [ADV7604_PAGE_VDP] = { "vdp", 0x24 },
+};
+
 static int adv76xx_core_init(struct v4l2_subdev *sd)
 {
struct adv76xx_state *state = to_state(sd);
@@ -2834,13 +2855,26 @@ static void adv76xx_unregister_clients(struct 
adv76xx_state *state)
 }
 
 static struct i2c_client *adv76xx_dummy_client(struct v4l2_subdev *sd,
-   u8 addr, u8 io_reg)
+  unsigned int i)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   struct adv76xx_state *state = to_state(sd);
+   struct adv76xx_platform_data *pdata = >pdata;
+   unsigned int io_reg = 0xf2 + i;
+   struct i2c_client *new_client;
+
+   if (pdata && pdata->i2c_addresses[i])
+   new_client = i2c_new_dummy(client->adapter,
+  pdata->i2c_addresses[i]);
+   else
+   new_client = i2c_new_secondary_device(client,
+   adv76xx_secondary_names[i].name,
+   adv76xx_secondary_names[i].default_addr);
 
-   if (addr)
-   io_write(sd, io_reg, addr << 1);
-   return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+   if (new_client)
+   io_write(sd, io_reg, new_client->addr << 1);
+
+   return new_client;
 }
 
 static const struct adv76xx_reg_seq adv7604_recommended_settings_afe[] = {
@@ -3115,20 +3149,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state->pdata.int1_config = ADV76XX_INT1_CONFIG_DISABLED;
 
-   /* Use the default I2C addresses. */
-   state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CEC] = 0x40;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_INFOFRAME] = 0x3e;
-   state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38;
-   state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_AFE] = 0x26;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_REP] = 0x32;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_EDID] = 0x36;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_HDMI] = 0x34;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_TEST] = 0x30;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CP] = 0x22;
-   state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24;
-
/* Hardcode the remaining platform data fields. */
state->pdata.disable_pwrdnb = 0;
state->pdata.disable_cable_det_rst = 0;
@@ -3478,11 +3498,9 @@ static int adv76xx_probe(struct i2c_client *client,
if (!(BIT(i) & state->info->page_mask))
continue;
 
-   state->i2c_clients[i] =
-   adv76xx_dummy_client(sd, state->pdata.i2c_addresses[i],
-0xf2 + i);
+   state->i2c_clients[i] = adv76xx_dummy_client(sd, 

[PATCH v3 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

From: Kieran Bingham 

The r8a7792 Wheat board has two ADV7513 devices sharing a single i2c
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.

The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into account the fault whereby the
devices reset the addresses.

This results in an address conflict between the device using the default
addresses, and the other device if it is in low-power-mode.

Repair this issue by moving both devices away from the default address
definitions.

Signed-off-by: Kieran Bingham 

---
v2:
 - Addition to series

v3:
 - Split map register addresses into individual declarations.

 arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts 
b/arch/arm/boot/dts/r8a7792-wheat.dts
index b9471b67b728..42fff8837eab 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -240,9 +240,16 @@
status = "okay";
clock-frequency = <40>;
 
+   /*
+* The adv75xx resets its addresses to defaults during low power power
+* mode. Because we have two ADV7513 devices on the same bus, we must
+* change both of them away from the defaults so that they do not
+* conflict.
+*/
hdmi@3d {
compatible = "adi,adv7513";
-   reg = <0x3d>;
+   reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
@@ -272,7 +279,8 @@
 
hdmi@39 {
compatible = "adi,adv7513";
-   reg = <0x39>;
+   reg = <0x39>, <0x29>, <0x49>, <0x59>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.7.4

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

[PATCH v3 0/5] Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

Back in 2014, Jean-Michel provided patches [0] to implement a means of
describing software defined I2C addresses for devices through the DT nodes.

The patch to implement the function "i2c_new_secondary_device()" was integrated,
but the corresponding driver update didn't get applied.

This short series re-bases Jean-Michel's patch to mainline for the ADV7604 
driver
in linux-media, and also provides a patch for the ADV7511 DRM Bridge driver 
taking
the same approach.

This series allows us to define the I2C address allocations of these devices in
the device tree for the Renesas D3 platform where these two devices reside on
the same bus and conflict with each other presently..

[0] https://lkml.org/lkml/2014/10/22/468
[1] https://lkml.org/lkml/2014/10/22/469

v2:
 - dt bindings split from driver changes
 - fixed up dt binding property descriptions
 - Update missing edid-i2c address setting (adv7511)
 - Provide update for r8a7792 DTB to account for address conflict

v3:
 - Split map register addresses into individual declarations across all uses


Jean-Michel Hautbois (2):
  dt-bindings: media: adv7604: Add support for i2c_new_secondary_device
  media: adv7604: Add support for i2c_new_secondary_device

Kieran Bingham (3):
  dt-bindings: adv7511: Add support for i2c_new_secondary_device
  [RFT] ARM: dts: wheat: Fix ADV7513 address usage
  drm: adv7511: Add support for i2c_new_secondary_device

 .../bindings/display/bridge/adi,adv7511.txt| 18 ++-
 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-
 arch/arm/boot/dts/r8a7792-wheat.dts| 12 -
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  6 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 42 +--
 drivers/media/i2c/adv7604.c| 62 ++
 6 files changed, 115 insertions(+), 43 deletions(-)

-- 
2.7.4

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

[PATCH v3 1/5] dt-bindings: media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 

---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - DT Binding update separated from code change
 - Minor reword to commit message to account for DT only change.
 - Collected Rob's RB tag.

v3:
 - Split map register addresses into individual declarations.

 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 9cbd92eb5d05..ebb5f070c05b 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -13,7 +13,11 @@ Required Properties:
 - "adi,adv7611" for the ADV7611
 - "adi,adv7612" for the ADV7612
 
-  - reg: I2C slave address
+  - reg: I2C slave addresses
+The ADV76xx has up to thirteen 256-byte maps that can be accessed via the
+main I²C ports. Each map has it own I²C address and acts as a standard
+slave device on the I²C bus. The main address is mandatory, others are
+optional and revert to defaults if not specified.
 
   - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
 detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -35,6 +39,11 @@ Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
   - default-input: Select which input is selected after reset.
+  - reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are :
+ "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
+ "rep", "edid", "hdmi", "test", "cp", "vdp"
 
 Optional Endpoint Properties:
 
@@ -52,7 +61,12 @@ Example:
 
hdmi_receiver@4c {
compatible = "adi,adv7611";
-   reg = <0x4c>;
+   /*
+* The edid page will be accessible @ 0x66 on the i2c bus. All
+* other maps will retain their default addresses.
+*/
+   reg = <0x4c>, <0x66>;
+   reg-names "main", "edid";
 
reset-gpios = < 0 GPIO_ACTIVE_LOW>;
hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
-- 
2.7.4

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

[PATCH v2 4/4] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index().  There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_vblank.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 32d9bcf5be7f..a3a1bce87468 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -120,7 +120,7 @@ static u32 __get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
 
-   if (crtc->funcs->get_vblank_counter)
+   if (crtc && crtc->funcs->get_vblank_counter)
return crtc->funcs->get_vblank_counter(crtc);
}
 
@@ -318,7 +318,7 @@ static void __disable_vblank(struct drm_device *dev, 
unsigned int pipe)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
 
-   if (crtc->funcs->disable_vblank) {
+   if (crtc && crtc->funcs->disable_vblank) {
crtc->funcs->disable_vblank(crtc);
return;
}
@@ -918,7 +918,7 @@ static int __enable_vblank(struct drm_device *dev, unsigned 
int pipe)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
 
-   if (crtc->funcs->enable_vblank)
+   if (crtc && crtc->funcs->enable_vblank)
return crtc->funcs->enable_vblank(crtc);
}
 
-- 
2.15.0

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

[PATCH v2 2/4] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa58d3c2..ec503d416062 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1082,10 +1082,12 @@ static bool drm_dp_port_setup_pdt(struct 
drm_dp_mst_port *port)
lct = drm_dp_calculate_rad(port, rad);
 
port->mstb = drm_dp_add_mst_branch_device(lct, rad);
-   port->mstb->mgr = port->mgr;
-   port->mstb->port_parent = port;
+   if (port->mstb) {
+   port->mstb->mgr = port->mgr;
+   port->mstb->port_parent = port;
 
-   send_link = true;
+   send_link = true;
+   }
break;
}
return send_link;
-- 
2.15.0

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

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #12 from Harry Wentland  ---
Looks like the conversation steered away from audio. 

Please use a new ticket or comment on existing tickets dealing with wrong
modes, such as https://bugs.freedesktop.org/show_bug.cgi?id=105046.

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

[PATCH v2 3/4] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL.  A check for this added right after
the call to drm_cvt_mode() in this particular area of code.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_edid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd537914575..23c9977d8999 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2083,6 +2083,8 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
if (hsize == 1366 && vsize == 768 && vrefresh_rate == 60) {
mode = drm_cvt_mode(dev, 1366, 768, vrefresh_rate, 0, 0,
false);
+   if (!mode)
+   return NULL;
mode->hdisplay = 1366;
mode->hsync_start = mode->hsync_start - 1;
mode->hsync_end = mode->hsync_end - 1;
-- 
2.15.0

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

[PATCH v2 1/4] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  2 helper
functions where added for pointer manipulation (drm_minor_get_slot()
and drm_minor_set_minor()) along with checks for valid pointers for
struct drm_device variables throughout this module.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_drv.c | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..dee6a4470e2c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -99,10 +99,36 @@ static struct drm_minor **drm_minor_get_slot(struct 
drm_device *dev,
case DRM_MINOR_CONTROL:
return >control;
default:
+   DRM_ERROR("Error in %s: Invalid dev, type = %d\n",
+ __func__, type);
return NULL;
}
 }
 
+static inline int drm_minor_set_minor(struct drm_device *dev,
+ unsigned int type,
+ struct drm_minor *minor)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+   int retval = -ENODEV;
+
+   if (slot) {
+   retval = 0;
+   *slot = minor;
+   }
+   return retval;
+}
+
+static inline struct drm_minor *drm_minor_get_minor(struct drm_device *dev,
+   unsigned int type)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+
+   if (slot)
+   return *slot;
+   return NULL;
+}
+
 static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 {
struct drm_minor *minor;
@@ -137,8 +163,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned 
int type)
goto err_index;
}
 
-   *drm_minor_get_slot(dev, type) = minor;
-   return 0;
+   r = drm_minor_set_minor(dev, type, minor);
+   if (r == 0)
+   return r;
 
 err_index:
spin_lock_irqsave(_minor_lock, flags);
@@ -155,6 +182,9 @@ static void drm_minor_free(struct drm_device *dev, unsigned 
int type)
unsigned long flags;
 
slot = drm_minor_get_slot(dev, type);
+   if (!slot)
+   return;
+
minor = *slot;
if (!minor)
return;
@@ -177,7 +207,7 @@ static int drm_minor_register(struct drm_device *dev, 
unsigned int type)
 
DRM_DEBUG("\n");
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_minor(dev, type);
if (!minor)
return 0;
 
@@ -209,7 +239,7 @@ static void drm_minor_unregister(struct drm_device *dev, 
unsigned int type)
struct drm_minor *minor;
unsigned long flags;
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_minor(dev, type);
if (!minor || !device_is_registered(minor->kdev))
return;
 
-- 
2.15.0

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

[PATCH v2 0/4] Parfait changes

[Joe Moriarty]

The following patch(s) are bugs found by the static compiler
'Parfait'.  Care was taken to make sure false positive results
were removed from this patchset.

Parfait Overview


https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13

v1:
Initial release

v2:
- Split original v1 patch into 4 separate patches per request
from Jani Nikula
- Fixed system hang during boot up on test machine.


Joe Moriarty (4):
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

 drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
 drivers/gpu/drm/drm_drv.c | 38 +++
 drivers/gpu/drm/drm_edid.c|  2 ++
 drivers/gpu/drm/drm_vblank.c  |  6 +++---
 4 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.15.0

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

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

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 03:12:38PM +0100, Hans de Goede wrote:
> Make intel_bios_cleanup function free the DSI VBT data structures which
> are memdup-ed by parse_mipi_config() and parse_mipi_sequence().
> 
> Signed-off-by: Hans de Goede 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_bios.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index f9550507bb9f..18110bbd9ee2 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1629,6 +1629,12 @@ void intel_bios_cleanup(struct drm_i915_private 
> *dev_priv)
>   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
>   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
>   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
> + kfree(dev_priv->vbt.dsi.data);
> + dev_priv->vbt.dsi.data = NULL;
> + kfree(dev_priv->vbt.dsi.pps);
> + dev_priv->vbt.dsi.pps = NULL;
> + kfree(dev_priv->vbt.dsi.config);
> + dev_priv->vbt.dsi.config = NULL;
>  }
>  
>  /**
> -- 
> 2.14.3

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

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

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 03:12:37PM +0100, Hans de Goede wrote:
> Add an intel_bios_cleanup() function to act as counterpart of
> intel_bios_init() and move the cleanup of vbt related resources there,
> putting it in the same file as the allocation.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   | 14 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 21 +
>  3 files changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e9f1daf258fe..7f094bbc2a7f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1446,19 +1446,7 @@ void i915_driver_unload(struct drm_device *dev)
>  
>   intel_modeset_cleanup(dev);
>  
> - /*
> -  * free the memory space allocated for the child device
> -  * config parsed from VBT
> -  */
> - if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
> - kfree(dev_priv->vbt.child_dev);
> - dev_priv->vbt.child_dev = NULL;
> - dev_priv->vbt.child_dev_num = 0;
> - }
> - kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
> - dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
> - kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
> - dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
> + intel_bios_cleanup(dev_priv);
>  
>   vga_switcheroo_unregister_client(pdev);
>   vga_client_register(pdev, NULL, NULL, NULL);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d6b5ac2a563d..1cccea1b87bc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3675,6 +3675,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
> *dev_priv);
>  
>  /* intel_bios.c */
>  void intel_bios_init(struct drm_i915_private *dev_priv);
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
>  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 4e74aa2f16bc..f9550507bb9f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1610,6 +1610,27 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
>   pci_unmap_rom(pdev, bios);
>  }
>  
> +/**
> + * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
> + * @dev_priv: i915 device instance
> + */
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv)
> +{
> + /*
> +  * free the memory space allocated for the child device
> +  * config parsed from VBT
> +  */
> + if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {

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

With that
Reviewed-by: Ville Syrjälä 

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

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

[Bug 103736] Sudden system freezes, GPU fault detected

[bugzilla-daemon]

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

--- Comment #9 from Ernst Sjöstrand  ---
I get

[  133.978908] amdgpu :09:00.0: GPU fault detected: 147 0x00198802
[  133.978911] amdgpu :09:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0053
[  133.978912] amdgpu :09:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02188002
[  133.978914] amdgpu :09:00.0: VM fault (0x02, vmid 1) at page 5242883,
read from 'TC4' (0x54433400) (392)

or from another boot

[  204.841497] amdgpu :09:00.0: GPU fault detected: 147 0x00188402
[  204.841501] amdgpu :09:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0053
[  204.841502] amdgpu :09:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0A084002
[  204.841504] amdgpu :09:00.0: VM fault (0x02, vmid 5) at page 5242883,
read from '' (0x) (132)


When I try to launch steam. It never gets to draw any UI, the computer just
freezes.
This happens with both 4.13(-ubuntu33) and 4.15.2 kernel with Mesa/LLVM from
git (padoka).
When I reverted to Mesa 17.2.8 + LLVM 5.0.0 I could launch steam again.

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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Tom St Denis]

On 12/02/18 12:16 PM, Christian König wrote:

Am 12.02.2018 um 17:40 schrieb Tom St Denis:

On 09/02/18 01:44 PM, Christian König wrote:

Am 09.02.2018 um 19:19 schrieb Tom St Denis:

On 09/02/18 01:17 PM, Christian König wrote:

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not 
sure if that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


I supposed there is a race on the kmap'ed memory which is why I 
added a ptr check.  Not perfect but since it's a debugfs entry 
probably better than it needs to be.


I think you can drop that, kmap can only return NULL on 32bit systems 
when we ran out of vmap area and then you can basically call panic() 
as well.


The question is if setting page->mapping during allocation has some 
undesired side effect.



Haven't noticed anything with piglit or other FOSS GL games.

Is there a specific test you'd like me to consider?


Try to restrict VRAM/GTT/memory in general and run something which needs 
a lot of CPU access to BOs. When it affects anything then the CPU page 
table unmap of BOs during eviction.



Limiting vram to 256M seems to be fine for both my iGPU and dGPU 
(thought it drops heaven from 40fps to about 3fps hehehe).


Trying to play with gttsize=256M seems to have broken things I get:


[  165.080976] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* 
amdgpu_cs_list_validate(validated) failed.
[  165.081163] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory 
for command submission!


and it seems heaven is blocked.  There are fences being submitted (and 
signalled) but nothing is being drawn.


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

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

[Alex Deucher]

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner  wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner  wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem you're trying to
>> > > solve on amdgpu thats with or without your patch set and the above
>> > > "trigger" too
>> > >
>> > > Is anything else required to trigger it, I started multiple DRI_PRIME
>> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
>> > > the 12 seconds and I couldn't reproduce it
>> >
>> > The discrete GPU needs to runtime suspend, that's the trigger,
>> > so no DRI_PRIME executables should be running.  Just let it
>> > autosuspend after boot.  Do you see "waiting 12 sec" messages
>> > in dmesg?  If not it's not autosuspending.
>>
>> Yes I'm seeing those messages, I'm just not seeing the hangs
>>
>> I've attached the dmesg in case you're interested
>
> Okay the reason you're not seeing deadlocks is because the output poll
> worker is not enabled.  And the output poll worker is not enabled
> because your discrete GPU doesn't have any outputs:
>
> [0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>
> The outputs are only polled if there are connectors which have the
> DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> And that only ever seems to be the case for VGA and DVI.
>
> We know based on bugzilla reports that hybrid graphics laptops do exist
> which poll outputs with radeon and nouveau.  If there are no laptops
> supported by amdgpu whose discrete GPU has polled connectors, then
> patch [5/5] would be unnecessary.  That is for Alex to decide.

Most hybrid laptops don't have display connectors on the dGPU and we
only use polling on analog connectors, so you are not likely to run
into this on recent laptops.  That said, I don't know if there is some
OEM system out there with a VGA port on the dGPU in a hybrid laptop.
I guess another option is to just disable polling on hybrid laptops.

Alex

>
> However that is very good to know, so thanks a lot for your testing
> efforts, much appreciated!
>
> Kind regards,
>
> Lukas
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Lukas Wunner]

On Mon, Feb 12, 2018 at 05:50:12PM +, Chris Wilson wrote:
> Quoting Lyude Paul (2018-02-12 17:46:11)
> > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > > Introduce a helper to determine if the current task is an output poll
> > > worker.
> > > 
> > > This allows us to fix a long-standing deadlock in several DRM drivers
> > > wherein the ->runtime_suspend callback waits for the output poll worker
> > > to finish and the worker in turn calls a ->detect callback which waits
> > > for runtime suspend to finish.  The ->detect callback is invoked from
> > > multiple call sites and waiting for runtime suspend to finish is the
> > > correct thing to do except if it's executing in the context of the
> > > worker.
> > > 
> > > Cc: Dave Airlie 
> > > Cc: Ben Skeggs 
> > > Cc: Alex Deucher 
> > > Signed-off-by: Lukas Wunner 
> > > ---
> > >  drivers/gpu/drm/drm_probe_helper.c | 14 ++
> > >  include/drm/drm_crtc_helper.h  |  1 +
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 555fbe54d6e2..019881d15ce1 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > > *work)
> > >   schedule_delayed_work(delayed_work,
> > > DRM_OUTPUT_POLL_PERIOD);
> > >  }
> > >  
> > > +/**
> > > + * drm_kms_helper_is_poll_worker - is %current task an output poll 
> > > worker?
> > > + *
> > > + * Determine if %current task is an output poll worker.  This can be used
> > > + * to select distinct code paths for output polling versus other 
> > > contexts.
> > > + */
> > > +bool drm_kms_helper_is_poll_worker(void)
> > > +{
> > > + struct work_struct *work = current_work();
> > > +
> > > + return work && work->func == output_poll_execute;
> 
> What ensures that work is accessible? Does this need rcu_read_lock
> protection or more?

The work_struct exists as long this kthread is working on it.
Since this is called by the kthread itself, it is guaranteed to exist.
So there's no protection needed.

Thanks,

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

Re: [PATCH v2 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

Hi Lars,

Thanks for your review!

On 12/02/18 18:24, Lars-Peter Clausen wrote:
> On 02/12/2018 07:11 PM, Kieran Bingham wrote:
> [...]
>> +/*
>> + * The adv75xx resets its addresses to defaults during low power power
>> + * mode. Because we have two ADV7513 devices on the same bus, we must
>> + * change both of them away from the defaults so that they do not
>> + * conflict.
>> + */
>>  hdmi@3d {
>>  compatible = "adi,adv7513";
>> -reg = <0x3d>;
>> +reg = <0x3d 0x2d 0x4d, 0x5d>;
> 
> To have the correct semantics this should be:
>   reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;>
> It is a set of 4 single cell addresses. The other thing is a single 4 cell
> address. It will get compiled to the same bytes, but the DT tools should
> complain about it, because it doesn't match #address-cells.

Not to mention the spurious comma's!!! (at least I marked the patch RFT :D)

I'll resend a v2.1 RFT here, and update my local changes (with the same fault,
sans comma) to my other DT files!

Thanks for the fast review.

--
Kieran


> 
>> +reg-names = "main", "cec", "edid", "packet";
>>  
>>  adi,input-depth = <8>;
>>  adi,input-colorspace = "rgb";
>> @@ -272,7 +279,8 @@
>>  
>>  hdmi@39 {
>>  compatible = "adi,adv7513";
>> -reg = <0x39>;
>> +reg = <0x39 0x29 0x49, 0x59>;
> 
> Same here.
> 
>> +reg-names = "main", "cec", "edid", "packet";
>>  
>>  adi,input-depth = <8>;
>>  adi,input-colorspace = "rgb";
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Lars-Peter Clausen]

On 02/12/2018 07:11 PM, Kieran Bingham wrote:
[...]
> + /*
> +  * The adv75xx resets its addresses to defaults during low power power
> +  * mode. Because we have two ADV7513 devices on the same bus, we must
> +  * change both of them away from the defaults so that they do not
> +  * conflict.
> +  */
>   hdmi@3d {
>   compatible = "adi,adv7513";
> - reg = <0x3d>;
> + reg = <0x3d 0x2d 0x4d, 0x5d>;

To have the correct semantics this should be:
reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;

It is a set of 4 single cell addresses. The other thing is a single 4 cell
address. It will get compiled to the same bytes, but the DT tools should
complain about it, because it doesn't match #address-cells.

> + reg-names = "main", "cec", "edid", "packet";
>  
>   adi,input-depth = <8>;
>   adi,input-colorspace = "rgb";
> @@ -272,7 +279,8 @@
>  
>   hdmi@39 {
>   compatible = "adi,adv7513";
> - reg = <0x39>;
> + reg = <0x39 0x29 0x49, 0x59>;

Same here.

> + reg-names = "main", "cec", "edid", "packet";
>  
>   adi,input-depth = <8>;
>   adi,input-colorspace = "rgb";
> 

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

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #5 from Michael Zapf  ---
Created attachment 137305
  --> https://bugs.freedesktop.org/attachment.cgi?id=137305=edit
dmesg output after turning the monitor back on

The turn-off event occured at time [75.336273].

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

[PATCH v2 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Kieran Bingham 

---
v2:
 - Update missing edid-i2c address setting
 - Split out DT bindings
 - Rename and move the I2C default addresses to their own section

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 ++--
 2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..04e6759ee45b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -93,6 +93,11 @@
 #define ADV7511_REG_CHIP_ID_HIGH   0xf5
 #define ADV7511_REG_CHIP_ID_LOW0xf6
 
+/* Hardware defined default addresses for i2c register maps */
+#define ADV7511_CEC_I2C_ADDR_DEFAULT   0x3c
+#define ADV7511_EDID_I2C_ADDR_DEFAULT  0x3f
+#define ADV7511_PACKET_I2C_ADDR_DEFAULT0x38
+
 #define ADV7511_CSC_ENABLE BIT(7)
 #define ADV7511_CSC_UPDATE_MODEBIT(5)
 
@@ -322,6 +327,7 @@ struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
struct i2c_client *i2c_cec;
+   struct i2c_client *i2c_packet;
 
struct regmap *regmap;
struct regmap *regmap_cec;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..5e61b928c9c0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
unsigned int edid_i2c_addr =
-   (adv7511->i2c_main->addr << 1) + 4;
+   (adv7511->i2c_edid->addr << 1);
 
__adv7511_power_on(adv7511);
 
@@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
 {
int ret;
 
-   adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
-adv->i2c_main->addr - 1);
+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_CEC_I2C_ADDR_DEFAULT);
if (!adv->i2c_cec)
-   return -ENOMEM;
+   return -EINVAL;
i2c_set_clientdata(adv->i2c_cec, adv);
 
adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
-   unsigned int main_i2c_addr = i2c->addr << 1;
-   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
 
@@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
goto uninit_regulators;
 
-   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
-   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-main_i2c_addr - 0xa);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
-main_i2c_addr - 2);
-
adv7511_packet_disable(adv7511, 0x);
 
-   adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
+   adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+   ADV7511_EDID_I2C_ADDR_DEFAULT);
if (!adv7511->i2c_edid) {
-   ret = -ENOMEM;
+   ret = -EINVAL;
goto uninit_regulators;
}
 
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+adv7511->i2c_edid->addr << 1);
+
ret = adv7511_init_cec_regmap(adv7511);
if (ret)
goto err_i2c_unregister_edid;
 
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
+adv7511->i2c_cec->addr << 1);
+
+   adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+   ADV7511_PACKET_I2C_ADDR_DEFAULT);
+   if (!adv7511->i2c_packet) {
+   ret = -EINVAL;
+   goto err_unregister_cec;
+   }
+
+   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
+adv7511->i2c_packet->addr << 1);
+
 

[PATCH v2 1/5] dt-bindings: media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 

---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - DT Binding update separated from code change
 - Minor reword to commit message to account for DT only change.
 - Collected Rob's RB tag.

 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 9cbd92eb5d05..b64e313dcc66 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -13,7 +13,11 @@ Required Properties:
 - "adi,adv7611" for the ADV7611
 - "adi,adv7612" for the ADV7612
 
-  - reg: I2C slave address
+  - reg: I2C slave addresses
+The ADV76xx has up to thirteen 256-byte maps that can be accessed via the
+main I²C ports. Each map has it own I²C address and acts as a standard
+slave device on the I²C bus. The main address is mandatory, others are
+optional and revert to defaults if not specified.
 
   - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
 detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -35,6 +39,11 @@ Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
   - default-input: Select which input is selected after reset.
+  - reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are :
+ "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
+ "rep", "edid", "hdmi", "test", "cp", "vdp"
 
 Optional Endpoint Properties:
 
@@ -52,7 +61,12 @@ Example:
 
hdmi_receiver@4c {
compatible = "adi,adv7611";
-   reg = <0x4c>;
+   /*
+* The edid page will be accessible @ 0x66 on the i2c bus. All
+* other maps will retain their default addresses.
+*/
+   reg = <0x4c 0x66>;
+   reg-names "main", "edid";
 
reset-gpios = < 0 GPIO_ACTIVE_LOW>;
hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
-- 
2.7.4

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

[PATCH v2 2/5] dt-bindings: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
---
v2:
 - Fixed up reg: property description to account for multiple optional
   addresses.
 - Minor reword to commit message to account for DT only change
 - Collected Robs RB tag

 .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..f1b5466b1ca7 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -14,7 +14,13 @@ Required properties:
"adi,adv7513"
"adi,adv7533"
 
-- reg: I2C slave address
+- reg: I2C slave addresses
+  The ADV7511 internal registers are split into four pages exposed through
+  different I2C addresses, creating four register maps. Each map has it own
+  I2C address and acts as a standard slave device on the I²C bus. The main
+  address is mandatory, others are optional and revert to defaults if not
+  specified.
+
 
 The ADV7511 supports a large number of input data formats that differ by their
 color depth, color format, clock mode, bit justification and random
@@ -70,6 +76,9 @@ Optional properties:
   rather than generate its own timings for HDMI output.
 - clocks: from common clock binding: reference to the CEC clock.
 - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
 
 Required nodes:
 
@@ -88,7 +97,12 @@ Example
 
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the i2c
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39 0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;
-- 
2.7.4

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

[PATCH v2 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

From: Kieran Bingham 

The r8a7792 Wheat board has two ADV7513 devices sharing a single i2c
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.

The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into account the fault whereby the
devices reset the addresses.

This results in an address conflict between the device using the default
addresses, and the other device if it is in low-power-mode.

Repair this issue by moving both devices away from the default address
definitions.

Signed-off-by: Kieran Bingham 
---
 arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts 
b/arch/arm/boot/dts/r8a7792-wheat.dts
index b9471b67b728..c94f330392ee 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -240,9 +240,16 @@
status = "okay";
clock-frequency = <40>;
 
+   /*
+* The adv75xx resets its addresses to defaults during low power power
+* mode. Because we have two ADV7513 devices on the same bus, we must
+* change both of them away from the defaults so that they do not
+* conflict.
+*/
hdmi@3d {
compatible = "adi,adv7513";
-   reg = <0x3d>;
+   reg = <0x3d 0x2d 0x4d, 0x5d>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
@@ -272,7 +279,8 @@
 
hdmi@39 {
compatible = "adi,adv7513";
-   reg = <0x39>;
+   reg = <0x39 0x29 0x49, 0x59>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.7.4

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

[PATCH v2 0/5] Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

Back in 2014, Jean-Michel provided patches [0] to implement a means of
describing software defined I2C addresses for devices through the DT nodes.

The patch to implement the function "i2c_new_secondary_device()" was integrated,
but the corresponding driver update didn't get applied.

This short series re-bases Jean-Michel's patch to mainline for the ADV7604 
driver
in linux-media, and also provides a patch for the ADV7511 DRM Bridge driver 
taking
the same approach.

This series allows us to define the I2C address allocations of these devices in
the device tree for the Renesas D3 platform where these two devices reside on
the same bus and conflict with each other presently..

[0] https://lkml.org/lkml/2014/10/22/468
[1] https://lkml.org/lkml/2014/10/22/469

v2:
 - dt bindings split from driver changes
 - fixed up dt binding property descriptions
 - Update missing edid-i2c address setting (adv7511)
 - Provide update for r8a7792 DTB to account for address conflict

Jean-Michel Hautbois (2):
  dt-bindings: media: adv7604: Add support for i2c_new_secondary_device
  media: adv7604: Add support for i2c_new_secondary_device

Kieran Bingham (3):
  dt-bindings: adv7511: Add support for i2c_new_secondary_device
  [RFT] ARM: dts: wheat: Fix ADV7513 address usage
  drm: adv7511: Add support for i2c_new_secondary_device

 .../bindings/display/bridge/adi,adv7511.txt| 18 ++-
 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-
 arch/arm/boot/dts/r8a7792-wheat.dts| 12 -
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  6 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 42 +--
 drivers/media/i2c/adv7604.c| 62 ++
 6 files changed, 115 insertions(+), 43 deletions(-)

-- 
2.7.4

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

[PATCH v2 4/5] media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - Split out DT bindings from driver updates
 - Return -EINVAL on error paths from adv76xx_dummy_client()

 drivers/media/i2c/adv7604.c | 62 +
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 1544920ec52d..872e124793f8 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2734,6 +2734,27 @@ static const struct v4l2_ctrl_config 
adv76xx_ctrl_free_run_color = {
 
 /* --- */
 
+struct adv76xx_register {
+   const char *name;
+   u8 default_addr;
+};
+
+static const struct adv76xx_register adv76xx_secondary_names[] = {
+   [ADV76XX_PAGE_IO] = { "main", 0x4c },
+   [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
+   [ADV76XX_PAGE_CEC] = { "cec", 0x40 },
+   [ADV76XX_PAGE_INFOFRAME] = { "infoframe", 0x3e },
+   [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
+   [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
+   [ADV76XX_PAGE_AFE] = { "afe", 0x26 },
+   [ADV76XX_PAGE_REP] = { "rep", 0x32 },
+   [ADV76XX_PAGE_EDID] = { "edid", 0x36 },
+   [ADV76XX_PAGE_HDMI] = { "hdmi", 0x34 },
+   [ADV76XX_PAGE_TEST] = { "test", 0x30 },
+   [ADV76XX_PAGE_CP] = { "cp", 0x22 },
+   [ADV7604_PAGE_VDP] = { "vdp", 0x24 },
+};
+
 static int adv76xx_core_init(struct v4l2_subdev *sd)
 {
struct adv76xx_state *state = to_state(sd);
@@ -2834,13 +2855,26 @@ static void adv76xx_unregister_clients(struct 
adv76xx_state *state)
 }
 
 static struct i2c_client *adv76xx_dummy_client(struct v4l2_subdev *sd,
-   u8 addr, u8 io_reg)
+  unsigned int i)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   struct adv76xx_state *state = to_state(sd);
+   struct adv76xx_platform_data *pdata = >pdata;
+   unsigned int io_reg = 0xf2 + i;
+   struct i2c_client *new_client;
+
+   if (pdata && pdata->i2c_addresses[i])
+   new_client = i2c_new_dummy(client->adapter,
+  pdata->i2c_addresses[i]);
+   else
+   new_client = i2c_new_secondary_device(client,
+   adv76xx_secondary_names[i].name,
+   adv76xx_secondary_names[i].default_addr);
 
-   if (addr)
-   io_write(sd, io_reg, addr << 1);
-   return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+   if (new_client)
+   io_write(sd, io_reg, new_client->addr << 1);
+
+   return new_client;
 }
 
 static const struct adv76xx_reg_seq adv7604_recommended_settings_afe[] = {
@@ -3115,20 +3149,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state->pdata.int1_config = ADV76XX_INT1_CONFIG_DISABLED;
 
-   /* Use the default I2C addresses. */
-   state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CEC] = 0x40;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_INFOFRAME] = 0x3e;
-   state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38;
-   state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_AFE] = 0x26;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_REP] = 0x32;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_EDID] = 0x36;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_HDMI] = 0x34;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_TEST] = 0x30;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CP] = 0x22;
-   state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24;
-
/* Hardcode the remaining platform data fields. */
state->pdata.disable_pwrdnb = 0;
state->pdata.disable_cable_det_rst = 0;
@@ -3478,11 +3498,9 @@ static int adv76xx_probe(struct i2c_client *client,
if (!(BIT(i) & state->info->page_mask))
continue;
 
-   state->i2c_clients[i] =
-   adv76xx_dummy_client(sd, state->pdata.i2c_addresses[i],
-0xf2 + i);
+   state->i2c_clients[i] = adv76xx_dummy_client(sd, 

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

[Chris Wilson]

Quoting Lyude Paul (2018-02-12 17:46:11)
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
> > 
> > Cc: Dave Airlie 
> > Cc: Ben Skeggs 
> > Cc: Alex Deucher 
> > Signed-off-by: Lukas Wunner 
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 14 ++
> >  include/drm/drm_crtc_helper.h  |  1 +
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 555fbe54d6e2..019881d15ce1 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > *work)
> >   schedule_delayed_work(delayed_work,
> > DRM_OUTPUT_POLL_PERIOD);
> >  }
> >  
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.
> 
> > +bool drm_kms_helper_is_poll_worker(void)
> > +{
> > + struct work_struct *work = current_work();
> > +
> > + return work && work->func == output_poll_execute;

What ensures that work is accessible? Does this need rcu_read_lock
protection or more?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Lyude Paul]

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> Cc: Dave Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 14 ++
>  include/drm/drm_crtc_helper.h  |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 555fbe54d6e2..019881d15ce1 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> *work)
>   schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + */
For this, it would be worth explicitly noting in the comments herethat this
should be called by DRM drivers in order to prevent racing with hotplug
polling workers, so that new drivers in the future can avoid implementing this
race condition in their driver.

> +bool drm_kms_helper_is_poll_worker(void)
> +{
> + struct work_struct *work = current_work();
> +
> + return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Lyude Paul]

This patchset is a no-brainer for me. I'm ashamed to say I think I might have
seen this issue before, but polling gets used so rarely nowadays it slipped
under the rug by accident.

Anyway, for the whole series  (except patch #2, which I will respond to with a
short comment in just a moment):

Reviewed-by: Lyude Paul 

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
> 
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
>  drivers/gpu/drm/drm_probe_helper.c | 14 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c | 74 +
> -
>  include/drm/drm_crtc_helper.h  |  1 +
>  include/linux/workqueue.h  |  1 +
>  kernel/workqueue.c | 16 ++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

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

--- Comment #2 from Gregor Münch  ---
Im using pre-compiled llvm binaries- thus I have no packages to try in between.
I know how to do a bisect with git but I somehow fail to do the same with svn.
Maybe solution is actually easy -if someone could guide me here I think I
provide a bisect result during this week.

I tried today with nir backend and here it is crashing right away on game start
(and even gives some output):
Unknown intrinsic: intrinsic store_shared (ssa_45, ssa_46) () (0, 1) /* base=0
*/ /* wrmask=x */
Unknown intrinsic: intrinsic store_shared (ssa_73, ssa_74) () (0, 1) /* base=0
*/ /* wrmask=x */
Unknown intrinsic: vec1 32 ssa_75 = intrinsic load_shared (ssa_46) () (0) /*
base=0 */
Unknown intrinsic: vec1 32 ssa_76 = intrinsic load_shared (ssa_74) () (0) /*
base=0 */
/run/media/greg/Steam_Linux/steamapps/common/ShadowOfMordor/ShadowOfMordor.sh:
Zeile 167:  6992 Speicherzugriffsfehler  (Speicherabzug geschrieben)
${GAME_LAUNCH_PREFIX} "${GAMEROOT}/bin/${FERAL_GAME_NAME}" "$@"

It was previously working great with nir before.

Forgot to add:
OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI / DRM 3.25.0 /
4.15.0-2-amd-staging-drm-next-git, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel
(git-9b9a89cd79)

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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

On Sat, Feb 10, 2018 at 09:43:59AM +, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-09 17:55:38)
> > On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi  wrote:
> > > Rodrigo Vivi  writes:
> > > So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> > > after that and the result is this:
> > >
> > >
> > > [   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
> > > Scheduling 10s
> > > [   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> > > ...
> > > a bunch more of Work busy
> > > ...
> > > [   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> > 
> > This like ("Work busy!") is intel_psr_flush() noticing that
> > work_busy() returns true (which it does indeed do when the work is
> > scheduled for the future).  But this means that intel_psr_flush()
> > wants to keep PSR off for a little bit (10s with your patch applied)
> > because the screen isn't idle.
> > 
> > > [   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work 
> > > running
> > 
> > And here's intel_psr_work() turning PSR back on 3ms later.
> > 
> > So I think you're seeing exactly the bug I described.

Well, not in the way you described though.

As we can see on the log work running get executed only 10 seconds after
intel_psr_enable wanted. None of the thousand flushes happening there will
trigger psr activate before the wanted 10s.

So the hack indeed work as expected.

Given that description I proved that it works as expected and move away.
But since you insisted I step back and re-read your patch like if you had
never mentioned the hack on intel_psr_enable ever, but only focusing
on the regular calls from intel_psr_flush and you are right,
we do have a bug that would affect VLV/CHV here.

In the current code the psr_activate can happen any moment from 0ms to 100ms
after the flush.

This 100ms would just reduce the amount of fast exit-activate cases,
but not eliminate the possibility of enabling before 100ms.

On core platforms it shouldn't be any problem because HW tracking would
take care of waiting the extra idle frames.

This could be a particular problem for VLV/CHV platforms where I believe
we should wait few frames before really activating it back.

So, probably we can go ahead with your patch so we get this covered for
VLV/CHV, but I'd like a version without mentioning the intel_psr_enable
case that is already proven work as expected.

But meanwhile I will check back on the hack and see if we can already
remove that since many things got fixed and improved around eDP link training
and psr itself.

Also I will discuss with DK and check the possibility of a immediate activate
on platforms with HW tracking. Specially now that we are moving towards more
use of HW tracking.

In this case we would reduce this scheduled/timer based solution only for 
VLV/CHV.

And then on VLV/CHV front there are even more issues to sync with VBLANK etc in
a platform that probably went to the market without any single unit with PSR 
panels
that was to expensive when those platforms got released.

I even consider totally removing VLV/CHV code completely.

> 
> It's also evident in the tests that PSR isn't being disabled as
> often/quick as we need for frontbuffer updates to be seen.

Yeap, it is evident we have many bugs there, but I'm afraid this is not
the answer for the lag.
DK found some promising ones...

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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Christian König]

Am 12.02.2018 um 17:40 schrieb Tom St Denis:

On 09/02/18 01:44 PM, Christian König wrote:

Am 09.02.2018 um 19:19 schrieb Tom St Denis:

On 09/02/18 01:17 PM, Christian König wrote:

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not 
sure if that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


I supposed there is a race on the kmap'ed memory which is why I 
added a ptr check.  Not perfect but since it's a debugfs entry 
probably better than it needs to be.


I think you can drop that, kmap can only return NULL on 32bit systems 
when we ran out of vmap area and then you can basically call panic() 
as well.


The question is if setting page->mapping during allocation has some 
undesired side effect.



Haven't noticed anything with piglit or other FOSS GL games.

Is there a specific test you'd like me to consider?


Try to restrict VRAM/GTT/memory in general and run something which needs 
a lot of CPU access to BOs. When it affects anything then the CPU page 
table unmap of BOs during eviction.


Christian.



Tom


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

Re: [PATCH] drm: Use idr_init_base(1) when using id==0 for invalid

[Ville Syrjälä]

On Mon, Feb 12, 2018 at 02:55:33PM +, Chris Wilson wrote:
> Use the new idr_init_base() function to create an IDR that knows id==0
> is never allocated as it maps to an invalid identifier. By knowing that
> id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
> of having to start each lookup from the zeroth leaf as id==0 is always
> unused (and thus the tree-of-bitmaps indicate that is the first
> available).
> 
> References: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Christian Konig 
> Cc: Dave Airlie 

Yep, looks like all of these pass start==1 to idr_alloc().
Reviewed-by: Ville Syrjälä 

Looks like at least tile_idr and crtc_idr could use this as well,
although I suppose they're not hit nearly as hard as the gem stuff.
Also someone should really s/crtc_idr/obj_id_idr/ or something
along those lines.

> ---
> Note this requires 4.16-rc1.
> ---
>  drivers/gpu/drm/drm_gem.c | 4 ++--
>  drivers/gpu/drm/drm_syncobj.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 01f8d9481211..4975ba9a7bc8 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -98,7 +98,7 @@ drm_gem_init(struct drm_device *dev)
>   struct drm_vma_offset_manager *vma_offset_manager;
>  
>   mutex_init(>object_name_lock);
> - idr_init(>object_name_idr);
> + idr_init_base(>object_name_idr, 1);
>  
>   vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
>   if (!vma_offset_manager) {
> @@ -776,7 +776,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
>  void
>  drm_gem_open(struct drm_device *dev, struct drm_file *file_private)
>  {
> - idr_init(_private->object_idr);
> + idr_init_base(_private->object_idr, 1);
>   spin_lock_init(_private->table_lock);
>  }
>  
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 0b7b0d1ad2d5..d4f4ce484529 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -546,7 +546,7 @@ static int drm_syncobj_export_sync_file(struct drm_file 
> *file_private,
>  void
>  drm_syncobj_open(struct drm_file *file_private)
>  {
> - idr_init(_private->syncobj_idr);
> + idr_init_base(_private->syncobj_idr, 1);
>   spin_lock_init(_private->syncobj_table_lock);
>  }
>  
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Tejun Heo]

Hello,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Introduce a helper to retrieve the current task's work struct if it is
> a workqueue worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for a specific worker to
> finish and that worker in turn calls a function which waits for runtime
> suspend to finish.  That function is invoked from multiple call sites
> and waiting for runtime suspend to finish is the correct thing to do
> except if it's executing in the context of the worker.
> 
> Cc: Tejun Heo 
> Cc: Lai Jiangshan 
> Cc: Dave Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Signed-off-by: Lukas Wunner 

I wonder whether it's too generic a name but there are other functions
named in a similar fashion and AFAICS current_work isn't used by
anyone in the tree, so it seems okay.

Acked-by: Tejun Heo 

Please feel free to route as you see fit.

Thanks.

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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #10 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Ah. None ~ just your average HDMI to HDMI cable.

-- 
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 105036] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #5 from kyle.de...@mykolab.com ---
Created attachment 137304
  --> https://bugs.freedesktop.org/attachment.cgi?id=137304=edit
journalctl output for drm with amdgpu.dc_log=1 and drm.debug=6

-- 
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 105036] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #4 from kyle.de...@mykolab.com ---
Created attachment 137303
  --> https://bugs.freedesktop.org/attachment.cgi?id=137303=edit
journalctl output for amdgpu with amdgpu.dc_log=1 and drm.debug=6

-- 
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 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Kyle De'Vir from comment #8)
> What do you mean by dongle? Wifi?

A display dongle (e.g., DP to HDMI adapter).

-- 
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 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #8 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274131
  --> https://bugzilla.kernel.org/attachment.cgi?id=274131=edit
dmesg log with amdgpu.dc_log=1 and drm.debug=6

My monitor is an AOC I2379VHE. It's attached via a HDMI cable.

What do you mean by dongle? Wifi?

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #4 from Michael Zapf  ---
No problem, here's xrandr at first:

-
before:

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y
axis) 546mm x 352mm
   1920x1200 59.95*+
   1920x1080 60.0050.0059.94  
   1600x1200 60.00  
   1680x1050 59.88  
   1600x1000 60.01  
   1280x1024 75.02  
   1440x900  59.95  
   1280x960  60.00  
   1280x800  59.95  
   1152x864  75.00  
   1280x720  60.0050.0059.94  
   1024x768  75.0360.00  
   832x624   74.55  
   800x600   75.0060.32  
   720x576   50.00  
   720x480   60.0059.94  
   640x480   75.0060.0059.94  
   720x400   70.08  
DVI-D-0 disconnected (normal left inverted right x axis y axis)
-

turn off, turn on: (should wait for at least 2 secs before turning on)

Screen 0: minimum 320 x 200, current 1368 x 768, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 connected primary 1368x768+0+0 (normal left inverted right x axis y
axis) 0mm x 0mm
   1368x768  59.88* 
   1280x800  59.81  
   1280x720  59.86  
   1024x768  60.00  
   1024x576  59.90  
   960x540   59.63  
   800x600   60.32  
   800x450   59.82  
   700x450   59.88  
   640x480   59.94  
   684x384   59.8859.85  
   640x400   59.8859.98  
   640x360   59.8659.83  
   512x384   60.00  
   512x288   60.0059.92  
   480x270   59.6359.82  
   400x300   60.32  
   320x240   60.05  
DVI-D-0 disconnected (normal left inverted right x axis y axis)

-- 
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 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #11 from Maximilian Böhm  ---
I feel your pain, I’m experiencing something similar here:
RX 580 → HDMI @ FullHD → Marantz NR1504 → [EDID-Fake-Plug]
RX 580 → DP @ UHD → Dell P2715Q.

Sometimes, when I turn the monitor off and on again, my desktop resolution is
reduced to 2048x1536 (this is not even 16:9) and I have no other option than
rebooting to get 3840x2160 again. This was new coming with the DC patches but
does not happen every time I turn the monitor off and on again, rather rarely,
but is endlessly annoying.

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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Tom St Denis]

On 09/02/18 01:44 PM, Christian König wrote:

Am 09.02.2018 um 19:19 schrieb Tom St Denis:

On 09/02/18 01:17 PM, Christian König wrote:

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not sure 
if that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


I supposed there is a race on the kmap'ed memory which is why I added 
a ptr check.  Not perfect but since it's a debugfs entry probably 
better than it needs to be.


I think you can drop that, kmap can only return NULL on 32bit systems 
when we ran out of vmap area and then you can basically call panic() as 
well.


The question is if setting page->mapping during allocation has some 
undesired side effect.



Haven't noticed anything with piglit or other FOSS GL games.

Is there a specific test you'd like me to consider?

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

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

FFAB  changed:

   What|Removed |Added

 Attachment #136521|0   |1
is obsolete||
 Attachment #136522|0   |1
is obsolete||

--- Comment #42 from FFAB  ---
Created attachment 137302
  --> https://bugs.freedesktop.org/attachment.cgi?id=137302=edit
dmesg, kernel 4-16-rc1, booting with kernelparameter iommu=soft

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

Re: [Mesa-dev] [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Emil Velikov]

Hi Keith,

A few top level comments:

 - using card/primary node and (missing) authentication
Current code opens the primary node when VK_KHR_display is available.
Thus running a platform=drm,x11,wayland build will fail, as the client
is not authenticated with the X/WL server.

 - reuse "drm" as a shorthand for the "display"
We've been using drm for egl/gbm, va/drm, etc, one less platform plus
no equivalent in either of egl/va/...

 - remove conditional compilation based on library version/features.
Eg. checks like the following should be avoided.
#if DRM_EVENT_CONTEXT_VERSION

 - use drmModeAddFB2 (or the withModifiers version even) over drmModeAddFB
Might help with the XXX just above it ;-)

 - the spec says we're at VK_KHR_display rev 21, while the code advertises rev1
Extension('VK_KHR_display',   1,
'VK_USE_PLATFORM_DISPLAY_KHR'),

 - there are plenty of unnecessary of headers #include(d)

 - we could simplify the ifdef spaghetti by making
wsi_*_{init,finish}_wsi empty stubs
Definitely something that can be done, independently of your work.

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

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

--- Comment #41 from FFAB  ---
Created attachment 137301
  --> https://bugs.freedesktop.org/attachment.cgi?id=137301=edit
booting without additional kernel parameter

-- 
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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

--- Comment #40 from FFAB  ---
Upstream kernel test - kernel 4.16-rc1


Installation, on which upstream kernel was installed:

ubuntu 16.04.3, kernel 4.13.0-32, updated 2018-02-12

1. booting without any workaround parameters
2. booting with kernel parameter iommu=soft

boot-time 45sec
login o.k.

 "sudo lshw -short", missing line: 
/0/100/3.1/0 display Topaz XT [Radeon R7 M260/M265] 

attachments: 2018_02_02_dmesg_4.16-rc1.txt,  
2018_02_12_dmesg_4.16-rc1_iommu_soft.txt

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #3 from Harry Wentland  ---
Can you attach a full dmesg log from boot until this issue occurs, with kernel
options amdgpu.dc_log=1 and drm.debug=6?

Can you also paste what 'xrandr' outputs before and after this happens?

I wonder if EDID read fails for whatever reason.

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

Re: [PATCH] drm/pl111: Fix regression from fbdev CMA helper

[Noralf Trønnes]

Den 12.02.2018 16.53, skrev Linus Walleij:

On Mon, Feb 12, 2018 at 3:01 PM, Noralf Trønnes  wrote:

Den 12.02.2018 14.42, skrev Noralf Trønnes:

Den 12.02.2018 13.40, skrev Linus Walleij:

 drm_mode_config_reset(dev);
   -drm_fb_cma_fbdev_init(dev, 32, 0);
+drm_fb_cma_fbdev_init(dev, 32, 1);
 drm_kms_helper_poll_init(dev);

(...)


I forgot to look at the change, and I don't understand how this broke
anything,

My wrong.

I had some old codepaths in my out-of-tree stuff (sorry
the only thing that makes the hardware work...).

I was using the old drm_fbdev_cma_init() which isn't
as helpful as the new drm_fb_cma_fbdev_init() but
as the old function is still there it all just "worked"
except for this...

Theres is some confusion with these similarly named
functions :D


Yeah, that's my doing :-/
I have yet to do the final cleanup to remove struct drm_fbdev_cma.
If the generic fbdev emulation that I'm working on turns out good,
then it's possible to entirely drop fbdev code from many drivers.
Hence the waiting.


Sorry for the fuzz, I fixed my patch set to use the new
function now.


No problem.

Noralf.



Let's just drop this patch.

Yours,
Linus Walleij



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

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

[bugzilla-daemon]

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

--- Comment #5 from Harry Wentland  ---
Can you attach a full dmesg log with amdgpu.dc_log=1 and drm.debug=6 passed as
kernel options?

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

Re: [PATCH] drm/pl111: Fix regression from fbdev CMA helper

[Linus Walleij]

On Mon, Feb 12, 2018 at 3:01 PM, Noralf Trønnes  wrote:
> Den 12.02.2018 14.42, skrev Noralf Trønnes:
>> Den 12.02.2018 13.40, skrev Linus Walleij:

>>> drm_mode_config_reset(dev);
>>>   -drm_fb_cma_fbdev_init(dev, 32, 0);
>>> +drm_fb_cma_fbdev_init(dev, 32, 1);
>>> drm_kms_helper_poll_init(dev);

(...)

> I forgot to look at the change, and I don't understand how this broke
> anything,

My wrong.

I had some old codepaths in my out-of-tree stuff (sorry
the only thing that makes the hardware work...).

I was using the old drm_fbdev_cma_init() which isn't
as helpful as the new drm_fb_cma_fbdev_init() but
as the old function is still there it all just "worked"
except for this...

Theres is some confusion with these similarly named
functions :D

Sorry for the fuzz, I fixed my patch set to use the new
function now.

Let's just drop this patch.

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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

Harry Wentland (harry.wentl...@amd.com) changed:

   What|Removed |Added

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

--- Comment #7 from Harry Wentland (harry.wentl...@amd.com) ---
Please capture dmesg again with amdgpu.dc_log=1 and drm.debug=6 kernel options.

What monitor are you using? Is it connected via a dongle?

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #2 from Michael Zapf  ---
I got 3 systems where this issue occurs:

1. Monitor HP LP2475w connected via HDMI through a Pioneer AV receiver
(VSX-330) to an AMD Radeon RX480. (New DC was needed to get HDMI Audio.)

2. Similar monitor, directly connected via HDMI to AMD RX 580

3. UHD monitor, connected via DisplayPort to a RX 460.

I'm sitting at 1., can add more information to 2. and 3. when I return to my
second apartment resp. my office tomorrow.

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

> > I was more thinking about a struct containing enough info to allow the
> > proxy on the host side find the buffer, something like:
> > 
> > struct {
> >enum type { stdvga, virtio-cpu, ... }
> >pcislot device;
> >union {
> >   int stdvga_pcibar_offset;
> >   int virtio_gpu_resource_id;
> >}
> > }
> > 
> > So when the guest proxy gets a message with a fd referencing a buffer it
> > would have to figure where the buffer is, rewrite the message into the
> > struct above for the host proxy.  The host proxy would rewrite the
> > message again for the server.
> 
> What I don't understand yet is how we can keep the buffer descriptions
> together with the protocol data that references them.
> 
> With SCM_RIGHTS, the FDs are placed in the ancillary data that "travels"
> together with the protocol data that references them.

Place the buffer description into the wayland extension protocol messages?

i.e. have some wl_virt_proxy protocol extension.  Then, for the stdvga case:

  (1) client sends wl_drm/create_prime_buffer request to the guest proxy
  (2) guest proxy rewrites this into wl_virt_proxy/create_buffer, or
  maybe a create_stdvga_buffer request, carrying all the information
  listed above, and sends it to the host proxy.
  (3) host proxy rewrites it again into a wl_shm_pool/create_buffer and
  forwards it to the server.

cheers,
  Gerd

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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Eric Engestrom]

On Friday, 2018-02-09 20:45:10 -0800, Keith Packard wrote:
> This adds support for the KHR_display extension to the anv and radv
> Vulkan drivers. The drivers now attempt to open the master DRM node
> when the KHR_display extension is requested so that the common winsys
> code can perform the necessary operations.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac   |1 +
>  meson.build|4 +-
>  src/amd/vulkan/Makefile.am |8 +
>  src/amd/vulkan/Makefile.sources|3 +
>  src/amd/vulkan/meson.build |7 +
>  src/amd/vulkan/radv_device.c   |   28 +-
>  src/amd/vulkan/radv_extensions.py  |7 +-
>  src/amd/vulkan/radv_private.h  |2 +
>  src/amd/vulkan/radv_wsi.c  |3 +-
>  src/amd/vulkan/radv_wsi_display.c  |  143 
>  src/intel/Makefile.sources |3 +
>  src/intel/Makefile.vulkan.am   |7 +
>  src/intel/vulkan/anv_device.c  |   18 +-
>  src/intel/vulkan/anv_extensions.py |1 +
>  src/intel/vulkan/anv_extensions_gen.py |5 +-
>  src/intel/vulkan/anv_wsi.c |3 +-
>  src/intel/vulkan/anv_wsi_display.c |  129 +++
>  src/intel/vulkan/meson.build   |7 +
>  src/vulkan/Makefile.am |7 +
>  src/vulkan/Makefile.sources|4 +
>  src/vulkan/wsi/meson.build |   10 +
>  src/vulkan/wsi/wsi_common.c|   19 +-
>  src/vulkan/wsi/wsi_common.h|5 +-
>  src/vulkan/wsi/wsi_common_display.c| 1368 
> 
>  src/vulkan/wsi/wsi_common_display.h|   72 ++
>  src/vulkan/wsi/wsi_common_private.h|   10 +
>  26 files changed, 1858 insertions(+), 16 deletions(-)
>  create mode 100644 src/amd/vulkan/radv_wsi_display.c
>  create mode 100644 src/intel/vulkan/anv_wsi_display.c
>  create mode 100644 src/vulkan/wsi/wsi_common_display.c
>  create mode 100644 src/vulkan/wsi/wsi_common_display.h
> 
> diff --git a/configure.ac b/configure.ac
> index 8ed606c7694..46318365603 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1849,6 +1849,7 @@ fi
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> +AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')

copy/paste error: s/drm/display/

>  AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
> 'surfaceless')
>  AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
>  
> diff --git a/meson.build b/meson.build
> index b39e2f8ab96..aeb7f5e2917 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -239,11 +239,12 @@ with_platform_wayland = false
>  with_platform_x11 = false
>  with_platform_drm = false
>  with_platform_surfaceless = false
> +with_platform_display = false
>  egl_native_platform = ''
>  _platforms = get_option('platforms')
>  if _platforms == 'auto'
>if system_has_kms_drm
> -_platforms = 'x11,wayland,drm,surfaceless'
> +_platforms = 'x11,wayland,drm,surfaceless,display'
>elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
>  _platforms = 'x11,surfaceless'
>else
> @@ -257,6 +258,7 @@ if _platforms != ''
>with_platform_wayland = _split.contains('wayland')
>with_platform_drm = _split.contains('drm')
>with_platform_surfaceless = _split.contains('surfaceless')
> +  with_platform_display = _split.contains('display')
>egl_native_platform = _split[0]
>  endif
>  
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index 61025968942..061b8144b88 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -76,6 +76,14 @@ VULKAN_LIB_DEPS = \
>   $(DLOPEN_LIBS) \
>   -lm
>  
> +if HAVE_PLATFORM_DISPLAY
> +AM_CPPFLAGS += \
> + -DVK_USE_PLATFORM_DISPLAY_KHR
> +
> +VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
> +
> +endif
> +
>  if HAVE_PLATFORM_X11
>  AM_CPPFLAGS += \
>   $(XCB_DRI3_CFLAGS) \
> diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
> index a510d88d965..618a6cdaed0 100644
> --- a/src/amd/vulkan/Makefile.sources
> +++ b/src/amd/vulkan/Makefile.sources
> @@ -78,6 +78,9 @@ VULKAN_WSI_WAYLAND_FILES := \
>  VULKAN_WSI_X11_FILES := \
>   radv_wsi_x11.c
>  
> +VULKAN_WSI_DISPLAY_FILES := \
> + radv_wsi_display.c
> +
>  VULKAN_GENERATED_FILES := \
>   radv_entrypoints.c \
>   radv_entrypoints.h \
> diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
> index 0a7b7c0bf3c..b7bb1075e7d 100644
> --- a/src/amd/vulkan/meson.build
> +++ b/src/amd/vulkan/meson.build
> @@ -112,6 +112,13 @@ if with_platform_wayland
>libradv_files += files('radv_wsi_wayland.c')
>  endif
>  
> +if with_platform_display
> +  radv_flags += [
> +

[Bug 105036] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #3 from Harry Wentland  ---
What monitor are you using?

Please recapture the journalctl with these options for the Linux kernel:
amdgpu.dc_log=1 drm.debug=6

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #1 from Harry Wentland  ---
What monitor do you use and is it connected via DisplayPort, HDMI, or DVI?

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

[PATCH] drm/amdgpu: replace iova debugfs file with iomem (v3)

[Tom St Denis]

From: Christian König 

This allows access to pages allocated through the driver with optional
IOMMU mapping.

v2: Fix number of bytes copied and add write method
v3: drop check for kmap return

Original-by: Christian König 
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 102 +---
 1 file changed, 81 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b372d8d650a5..1338c908056f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,98 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 
 #endif
 
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
 {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
-   // always return 8 bytes
-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
 
-   // only accept page addresses
-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iomem_write(struct file *f, const char __user *buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
dom = iommu_get_domain_for_dev(adev->dev);
-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
 
-   r = copy_to_user(buf, , 8);
-   if (r)
-   return -EFAULT;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
 
-   return 8;
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_from_user(ptr, buf, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
 }
 
-static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
+   .write = amdgpu_iomem_write,
.llseek = default_llseek
 };
 
@@ -1973,7 +2033,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
 #endif
-   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
 };
 
 #endif
-- 
2.14.3

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

[PATCH] drm: Use idr_init_base(1) when using id==0 for invalid

[Chris Wilson]

Use the new idr_init_base() function to create an IDR that knows id==0
is never allocated as it maps to an invalid identifier. By knowing that
id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
of having to start each lookup from the zeroth leaf as id==0 is always
unused (and thus the tree-of-bitmaps indicate that is the first
available).

References: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Christian Konig 
Cc: Dave Airlie 
---
Note this requires 4.16-rc1.
---
 drivers/gpu/drm/drm_gem.c | 4 ++--
 drivers/gpu/drm/drm_syncobj.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 01f8d9481211..4975ba9a7bc8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -98,7 +98,7 @@ drm_gem_init(struct drm_device *dev)
struct drm_vma_offset_manager *vma_offset_manager;
 
mutex_init(>object_name_lock);
-   idr_init(>object_name_idr);
+   idr_init_base(>object_name_idr, 1);
 
vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
if (!vma_offset_manager) {
@@ -776,7 +776,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
 void
 drm_gem_open(struct drm_device *dev, struct drm_file *file_private)
 {
-   idr_init(_private->object_idr);
+   idr_init_base(_private->object_idr, 1);
spin_lock_init(_private->table_lock);
 }
 
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0b7b0d1ad2d5..d4f4ce484529 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -546,7 +546,7 @@ static int drm_syncobj_export_sync_file(struct drm_file 
*file_private,
 void
 drm_syncobj_open(struct drm_file *file_private)
 {
-   idr_init(_private->syncobj_idr);
+   idr_init_base(_private->syncobj_idr, 1);
spin_lock_init(_private->syncobj_table_lock);
 }
 
-- 
2.16.1

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/12/2018 03:27 PM, Gerd Hoffmann wrote:

On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:

Hi,


can we reach agreement on whether vsock should be involved in this?


I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol.  Use a wayland protocol extension to
reference the buffers in stdvga / ivshmem / virtio-gpu.  Only the two
proxies need to understand the extension, the client <=> guest proxy and
host proxy <=> server communication would be standard wayland protocol.


Thanks for the ideas. What I haven't understood yet is how you see the
actual passing of buffers via vsock. Are you thinking of using ancillary
data to pass FDs, or something else?


I was more thinking about a struct containing enough info to allow the
proxy on the host side find the buffer, something like:

struct {
   enum type { stdvga, virtio-cpu, ... }
   pcislot device;
   union {
  int stdvga_pcibar_offset;
  int virtio_gpu_resource_id;
   }
}

So when the guest proxy gets a message with a fd referencing a buffer it
would have to figure where the buffer is, rewrite the message into the
struct above for the host proxy.  The host proxy would rewrite the
message again for the server.


What I don't understand yet is how we can keep the buffer descriptions 
together with the protocol data that references them.


With SCM_RIGHTS, the FDs are placed in the ancillary data that "travels" 
together with the protocol data that references them.


With the present series, the DRM_IOCTL_VIRTGPU_WINSRV_TX ioctl struct has 
a field for the protocol data and an array of FDs.


How are you proposing to pass instances of that struct from above along 
the protocol data that refers to them?


Thanks,

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
> On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
> >Hi,
> > 
> > > can we reach agreement on whether vsock should be involved in this?
> > 
> > I think the best approach would be to have guest proxy and host proxy
> > use vsock for the wayland protocol.  Use a wayland protocol extension to
> > reference the buffers in stdvga / ivshmem / virtio-gpu.  Only the two
> > proxies need to understand the extension, the client <=> guest proxy and
> > host proxy <=> server communication would be standard wayland protocol.
> 
> Thanks for the ideas. What I haven't understood yet is how you see the
> actual passing of buffers via vsock. Are you thinking of using ancillary
> data to pass FDs, or something else?

I was more thinking about a struct containing enough info to allow the
proxy on the host side find the buffer, something like:

   struct {
  enum type { stdvga, virtio-cpu, ... }
  pcislot device;
  union {
 int stdvga_pcibar_offset;
 int virtio_gpu_resource_id;
  }
   }

So when the guest proxy gets a message with a fd referencing a buffer it
would have to figure where the buffer is, rewrite the message into the
struct above for the host proxy.  The host proxy would rewrite the
message again for the server.

cheers,
  Gerd

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

Re: [PATCH] drm/pl111: Fix regression from fbdev CMA helper

[Noralf Trønnes]

Den 12.02.2018 14.42, skrev Noralf Trønnes:


Den 12.02.2018 13.40, skrev Linus Walleij:

Commit d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
refactored the driver to use fbdev handling in the core, but
mistakedly limited the number of maximum connections to 0.

Predictably, zero possible connections also gives zero
framebuffers when using the system. So let's bump it to 1 so
we get our framebuffer back.

Cc: Noralf Trønnes 
Cc: Eric Anholt 
Fixes: d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
Signed-off-by: Linus Walleij 
---
  drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c

index acb738c69873..306ac7cabd90 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -138,7 +138,7 @@ static int pl111_modeset_init(struct drm_device 
*dev)

    drm_mode_config_reset(dev);
  -    drm_fb_cma_fbdev_init(dev, 32, 0);
+    drm_fb_cma_fbdev_init(dev, 32, 1);
    drm_kms_helper_poll_init(dev);


Sorry about that.

I don't know how bridges work, but since it doesn't work this means that
there's no connector available at this point?

This is the arg docs:

 * @max_conn_count: Maximum number of connectors.
 *  @dev->mode_config.num_connector is used if this is 
zero.


Anyways:
Acked-by: Noralf Trønnes 



I forgot to look at the change, and I don't understand how this broke 
anything,


drm/pl111: Use drm_fb_cma_fbdev_init/fini():

@@ -137,8 +138,7 @@ static int pl111_modeset_init(struct drm_device *dev)

 drm_mode_config_reset(dev);

-    priv->fbdev = drm_fbdev_cma_init(dev, 32,
-                     dev->mode_config.num_connector);
+    drm_fb_cma_fbdev_init(dev, 32, 0);

 drm_kms_helper_poll_init(dev);

New max_conn_count setting:

int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int 
preferred_bpp,

              unsigned int max_conn_count)
{
    return drm_fb_cma_fbdev_init_with_funcs(dev, preferred_bpp,
                        max_conn_count, NULL);
}

int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
    unsigned int preferred_bpp, unsigned int max_conn_count,
    const struct drm_framebuffer_funcs *funcs)
{
...
    if (!max_conn_count)
        max_conn_count = dev->mode_config.num_connector;

Noralf.

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:

   Hi,


can we reach agreement on whether vsock should be involved in this?


I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol.  Use a wayland protocol extension to
reference the buffers in stdvga / ivshmem / virtio-gpu.  Only the two
proxies need to understand the extension, the client <=> guest proxy and
host proxy <=> server communication would be standard wayland protocol.


Thanks for the ideas. What I haven't understood yet is how you see the 
actual passing of buffers via vsock. Are you thinking of using ancillary 
data to pass FDs, or something else?


Thanks,

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

Re: [PATCH] drm/pl111: Fix regression from fbdev CMA helper

[Noralf Trønnes]

Den 12.02.2018 13.40, skrev Linus Walleij:

Commit d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
refactored the driver to use fbdev handling in the core, but
mistakedly limited the number of maximum connections to 0.

Predictably, zero possible connections also gives zero
framebuffers when using the system. So let's bump it to 1 so
we get our framebuffer back.

Cc: Noralf Trønnes 
Cc: Eric Anholt 
Fixes: d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
Signed-off-by: Linus Walleij 
---
  drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index acb738c69873..306ac7cabd90 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -138,7 +138,7 @@ static int pl111_modeset_init(struct drm_device *dev)
  
  	drm_mode_config_reset(dev);
  
-	drm_fb_cma_fbdev_init(dev, 32, 0);

+   drm_fb_cma_fbdev_init(dev, 32, 1);
  
  	drm_kms_helper_poll_init(dev);
  


Sorry about that.

I don't know how bridges work, but since it doesn't work this means that
there's no connector available at this point?

This is the arg docs:

 * @max_conn_count: Maximum number of connectors.
 *  @dev->mode_config.num_connector is used if this is 
zero.


Anyways:
Acked-by: Noralf Trønnes 

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

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

[Imre Deak]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

In i915 polling is on during runtime suspend only if there are outputs
without hotplug interrupt support. A special case is when an output has
working HPD interrupts when in D0, but no interrupts when runtime
suspended. For these we start polling (from a scheduled work) in the
runtime suspend hook and stop it in the runtime resume hook (again from
a scheduled work).

Imo whether to leave polling on or not for the above purpose is a policy
question (configurable with the drm_kms_helper.poll param).

--Imre

> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
>  drivers/gpu/drm/drm_probe_helper.c | 14 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c | 74 
> +-
>  include/drm/drm_crtc_helper.h  |  1 +
>  include/linux/workqueue.h  |  1 +
>  kernel/workqueue.c | 16 ++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> ___
> 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

[RFC PATCH gabbayo] drm/amdgpu: amdkfd_fence_ops can be static

[kbuild test robot]

Fixes: 447ed3ae9ceb ("drm/amdgpu: Add KFD eviction fence")
Signed-off-by: Fengguang Wu 
---
 amdgpu_amdkfd_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index 8343e99..372578a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -29,7 +29,7 @@
 #include 
 #include "amdgpu_amdkfd.h"
 
-const struct dma_fence_ops amdkfd_fence_ops;
+static const struct dma_fence_ops amdkfd_fence_ops;
 static atomic_t fence_seq = ATOMIC_INIT(0);
 
 /* Eviction Fence
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/pl111: Fix regression from fbdev CMA helper

[Linus Walleij]

Commit d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
refactored the driver to use fbdev handling in the core, but
mistakedly limited the number of maximum connections to 0.

Predictably, zero possible connections also gives zero
framebuffers when using the system. So let's bump it to 1 so
we get our framebuffer back.

Cc: Noralf Trønnes 
Cc: Eric Anholt 
Fixes: d18df744de1a ("drm/pl111: Use drm_fb_cma_fbdev_init/fini()")
Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index acb738c69873..306ac7cabd90 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -138,7 +138,7 @@ static int pl111_modeset_init(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   drm_fb_cma_fbdev_init(dev, 32, 0);
+   drm_fb_cma_fbdev_init(dev, 32, 1);
 
drm_kms_helper_poll_init(dev);
 
-- 
2.14.3

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

Applied "spi: kconfig: Remove AVR32 dep. from SPI_ATMEL" to the spi tree

[Mark Brown]

The patch

   spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From e3d001a0c29d6c9a87dd9e86bcb84fc66c2ddbe8 Mon Sep 17 00:00:00 2001
From: Ulf Magnusson 
Date: Thu, 8 Feb 2018 23:00:16 +0100
Subject: [PATCH] spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").

Signed-off-by: Ulf Magnusson 
Signed-off-by: Mark Brown 
---
 drivers/spi/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b81..6fb0347a24f2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -72,10 +72,10 @@ config SPI_ARMADA_3700
 config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on HAS_DMA
-   depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
+   depends on (ARCH_AT91 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
- many AT32 (AVR32) and AT91 (ARM) chips.
+ many AT91 (ARM) chips.
 
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
-- 
2.16.1

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

  Hi,

> can we reach agreement on whether vsock should be involved in this?

I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol.  Use a wayland protocol extension to
reference the buffers in stdvga / ivshmem / virtio-gpu.  Only the two
proxies need to understand the extension, the client <=> guest proxy and
host proxy <=> server communication would be standard wayland protocol.

cheers,
  Gerd

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

  Hi,

> >(a) software rendering: client allocates shared memory buffer, renders
> >into it, then passes a file handle for that shmem block together
> >with some meta data (size, format, ...) to the wayland server.
> > 
> >(b) gpu rendering: client opens a render node, allocates a buffer,
> >asks the cpu to renders into it, exports the buffer as dma-buf
> >(DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> >(again including meta data of course).
> > 
> > Is that correct?
> 
> Both are correct descriptions of typical behaviors. But it isn't spec'ed
> anywhere who has to do the buffer allocation.

Well, according to Pekka's reply it is spec'ed that way, for the
existing buffer types.  So for server allocated buffers you need
(a) a wayland protocol extension and (b) support for the extension
in the clients.

> That's to say that if we cannot come up with a zero-copy solution for
> unmodified clients, we should at least support zero-copy for cooperative
> clients.

"cooperative clients" == "client which has support for the wayland
protocol extension", correct?

> > > Creation of shareable buffer by guest
> > > -
> > > 
> > > 1. Client requests virtio driver to create a buffer suitable for sharing
> > > with host (DRM_VIRTGPU_RESOURCE_CREATE)
> > 
> > client or guest proxy?
> 
> As per the above, the GUI toolkit could have been modified so the client
> directly creates a shareable buffer, and renders directly to it without any
> extra copies.
> 
> If clients cannot be modified, then it's the guest proxy what has to create
> the shareable buffer and keep it in sync with the client's non-shareable
> buffer at the right times, by intercepting wl_surface.commit messages and
> copying buffer contents.

Ok.

> > > 4. QEMU maps that buffer to the guest's address space
> > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
> > 
> > That part is problematic.  The host can't simply allocate something in
> > the physical address space, because most physical address space
> > management is done by the guest.  All pci bars are mapped by the guest
> > firmware for example (or by the guest OS in case of hotplug).
> 
> How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have
> expected that callers of that ioctl have enough knowledge to be able to
> choose a physical address that won't conflict with the guest's kernel.

Depends on the kind of region.  Guest RAM is allocated and mapped by
qemu, guest firmware can query qemu about RAM mappings using a special
interface, then create a e820 memory map for the guest os.  PCI device
bars are mapped according to the pci config space registers, which in
turn are initialized by the guest firmware, so it is basically in the
guests hand where they show up.

> I see that the ivshmem device in QEMU registers the memory region in BAR 2
> of a PCI device instead. Would that be better in your opinion?

Yes.

> > > 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
> > > resource, sends data + FDs to the compositor with SCM_RIGHTS
> > 
> > BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
> > does the wayland protocol allow for offsets in buffer meta data, so you
> > can place multiple buffers in a single shmem block?
> 
> The latter:
> https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool

Ah, good, that makes it alot easier.

So, yes, using ivshmem would be one option.  Tricky part here is the
buffer management though.  It's just a raw piece of memory.  The guest
proxy could mmap the pci bar and manage it.  But then it is again either
unmodified guest + copying the data, or modified client (which requests
buffers from guest proxy) for zero-copy.

Another idea would be extending stdvga.  Basically qemu would have to
use shmem as backing storage for vga memory instead of anonymous memory,
so it would be very  simliar to ivshmem on the host side.  But on the
guest side we have a drm driver for it (bochs-drm).  So clients can
allocate dumb drm buffers for software rendering, and the buffer would
already be backed by a host shmem segment.  Given that wayland already
supports drm buffers for 3d rendering that could work without extending
the wayland protocol.  The client proxy would have to translate the drm
buffer into an pci bar offset and pass it to the host side.  The host
proxy could register the pci bar as wl_shm_pool, then just pass through
the offset to reference the individual buffers.

Drawback of both approaches would be that software rendering and gpu
rendering would use quite different code paths.

We also need a solution for the keymap shmem block.  I guess the keymap
doesn't change all that often, so maybe it is easiest to just copy it
over (host proxy -> guest proxy) instead of trying to map the host shmem
into the guest?

cheers,
  Gerd

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

[bugzilla-daemon]

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

--- Comment #6 from arne_woer...@yahoo.com ---
FYI:
neither
(A) a new BIOS (Gigabyte F2A88XM-D3H, BIOS F10a 02/23/2016 (before it was F9))
nor
(B) turning off IOMMU support in the BIOS
nor
(C) kernel parameters "intremap=off amd_iommu=off"
helped...

-arne

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

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

Hi Ville,

On 12/01/18 20:08, Hans Verkuil wrote:
> On 01/12/2018 07:12 PM, Hans Verkuil wrote:
>> On 01/12/2018 06:52 PM, Ville Syrjälä wrote:
>>> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote:
 On 01/12/2018 05:30 PM, Ville Syrjälä wrote:
> On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
>> Hi Ville,
>>
>> For some strange reason your email disappeared from the Cc list. Perhaps 
>> it's the
>> ä that confuses something somewhere.
>>
>> So I'll just forward this directly to you.
>>
>> Can you please take a look? This patch series has been in limbo for too 
>> long.
>
> IIRC last I looked we still had some ragistration race to deal with.
> Was that fixed?

 That was fixed in v5.

>
> Also I think we got stuck on leaving the zombie device lingering around
> when the display is disconnected. I couldn't understand why that is
> at all useful since you anyway remove the device eventually.

 It's not a zombie device. If you disconnect and reconnect the display then 
 the
 application using the CEC device will see the display disappear and 
 reappear
 as expected.

 It helps if you think of the normal situation (as is present in most ARM 
 SoCs)
 where CEC is integral to the HDMI transmitter. I.e. it is not 
 functionality that
 can be removed. So the cec device is always there and an application opens 
 the
 device and can use it, regardless of whether a display is connected or not.

 If a display is detected, the EDID will be read and the CEC physical 
 address is
 set. The application is informed of that through an event and the CEC 
 adapter
 can be used. If the HPD disappears the physical address is reset to 
 f.f.f.f and
 again the application is informed. And in fact it still has to be able to 
 use
 the CEC adapter even if there is no HPD since some displays turn off the 
 HPD when
 in standby, but CEC can still be used to power them up again.
>>>
>>> Hmm. So you're saying there are DP devices out there that release HPD
>>> but still respond to DPCD accesses? That sounds... wrong.
>>
>> Not quite. To be precise: there are HDMI displays that release HPD when in 
>> standby
>> but still respond to CEC commands.
>>
>> Such displays are still being made today so if you are building a product 
>> like
>> a media streaming box, then this is something to take into account.
>>
>> However, for this specific case (CEC tunneling) it is a non-issue since the
>> DP CEC protocol simply doesn't support sending CEC commands without HPD.
>>
>>> In general I don't think we can assume that a device has retained its
>>> state if it has deasserted HPD, thus we have to reconfigure everything
>>> again anyway.
>>>

 Now consider a future Intel NUC with an HDMI connector on the backplane and
 working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): 
 the
 CEC support is always there (it's built in), but only becomes visible to 
 the
 kernel when you connect a display. You don't want the cec device to 
 disappear
 whenever you unplug the display, that makes no sense. Applications would
 loose the CEC configuration and have to close and reopen (when it 
 reappears)
 the cec device for no good reason since it is built in.
>>>
>>> If the application can't remember its settings across a disconnect it
>>> sounds broken anwyay. This would anyway happen when you disconenct the
>>> entire dongle.
>>
>> Huh?
>>
>>>

 The same situation is valid when using a USB-C to HDMI adapter: 
 disconnecting
 or reconnecting a display should not lead to the removal of the CEC device.
 Only when an adapter with different CEC capabilities is detected is there a
 need to actually unregister the CEC device.

 All this is really a workaround of the fact that when the HPD disappears 
 the
 DP-to-HDMI adapter (either external or built-in) also disappears from the
 topology, even though it is physically still there.
>>>
>>> The dongles I've seen do not disappear. The downstream hpd is
>>> signalled with short hpd pulses + SINK_COUNT instead.
>>>
>>> But I've not actually seen a dongle that implements the
>>> BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would
>>> actually do. The spec does say they should default to using long
>>> hpd for downstream hpd handling.
>>
>> I did a few more experiments and it appears that someone somewhere keeps
>> track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter
>> it still appears in i915_display_info. At least until something else is
>> connected. I basically need to hook into the DP branch detection.
>>
>> Something to look at this weekend.
> 
> I found a better place to do the CEC (un)registration: a long HPD pulse
> indicates that the DPCD registers have 

[PATCH 24/24] drm/omap: cleanup color space conversion

[Tomi Valkeinen]

The setup code for color space conversion is a bit messy. This patch
cleans it up.

For some reason the TRM uses values in YCrCb order, which is also used
in the current driver, whereas everywhere else it's YCbCr (which also
matches YUV order). This patch changes the tables to use the common
order to avoid confusion.

The tables are split into separate lines, and comments added for
clarity.

WB color conversion registers are similar but different than non-WB, but
the same function was used to write both. It worked fine because the
coef table was adjusted accordingly, but that was rather confusing. This
patch adds a separate function to write the WB values so that the coef
table can be written in an understandable way.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 59 +++--
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index ff09e2be470f..697274317f7c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -345,11 +345,6 @@ static const struct {
},
 };
 
-struct color_conv_coef {
-   int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
-   int full_range;
-};
-
 static unsigned long dispc_fclk_rate(void);
 static unsigned long dispc_core_clk_rate(void);
 static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
@@ -841,9 +836,18 @@ static void dispc_ovl_set_scale_coef(enum omap_plane_id 
plane, int fir_hinc,
}
 }
 
+struct csc_coef_yuv2rgb {
+   int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
+   bool full_range;
+};
+
+struct csc_coef_rgb2yuv {
+   int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
+   bool full_range;
+};
 
 static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
-   const struct color_conv_coef *ct)
+   const struct csc_coef_yuv2rgb *ct)
 {
 #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
 
@@ -853,7 +857,24 @@ static void dispc_ovl_write_color_conv_coef(enum 
omap_plane_id plane,
dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->bcr, ct->by));
dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->bcb));
 
-   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
+
+#undef CVAL
+}
+
+static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv *ct)
+{
+   const enum omap_plane_id plane = OMAP_DSS_WB;
+
+#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,  ct->yr));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct->crg));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct->cbr));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
+
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
 
 #undef CVAL
 }
@@ -862,20 +883,28 @@ static void dispc_setup_color_conv_coef(void)
 {
int i;
int num_ovl = dispc_get_num_ovls();
-   const struct color_conv_coef ctbl_bt601_5_ovl = {
-   /* YUV -> RGB */
-   298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
+
+   /* YUV -> RGB, ITU-R BT.601, limited range */
+   const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+   298,0,  409,/* ry, rcb, rcr */
+   298, -100, -208,/* gy, gcb, gcr */
+   298,  516,0,/* by, bcb, bcr */
+   false,  /* limited range */
};
-   const struct color_conv_coef ctbl_bt601_5_wb = {
-   /* RGB -> YUV */
-   66, 129, 25, 112, -94, -18, -38, -74, 112, 0,
+
+   /* RGB -> YUV, ITU-R BT.601, limited range */
+   const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
+66, 129,  25,  /* yr,   yg,  yb */
+   -38, -74, 112,  /* cbr, cbg, cbb */
+   112, -94, -18,  /* crr, crg, crb */
+   false,  /* limited range */
};
 
for (i = 1; i < num_ovl; i++)
-   dispc_ovl_write_color_conv_coef(i, _bt601_5_ovl);
+   dispc_ovl_write_color_conv_coef(i, _yuv2rgb_bt601_lim);
 
if (dispc.feat->has_writeback)
-   dispc_ovl_write_color_conv_coef(OMAP_DSS_WB, _bt601_5_wb);
+   dispc_wb_write_color_conv_coef(_rgb2yuv_bt601_lim);
 }
 
 static void dispc_ovl_set_ba0(enum omap_plane_id plane, u32 paddr)
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 23/24] drm/omap: Allow HDMI audio setup even if we do not have video configured

[Tomi Valkeinen]

From: Jyri Sarha 

Allow HDMI audio setup even if we do not have video configured. Audio
will get configured at the same time with video if the video is
configured soon enough. If it is not the audio DMA will timeout in
couple of seconds and audio playback will be aborted.

Signed-off-by: Jyri Sarha 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 33 ++---
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 37 -
 2 files changed, 30 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index ae6401c569c4..9d5c921cbf7b 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -598,21 +598,16 @@ static int hdmi_audio_startup(struct device *dev,
  void (*abort_cb)(struct device *dev))
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret = 0;
 
mutex_lock(>lock);
 
-   if (!hdmi_mode_has_audio(>cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
-   }
+   WARN_ON(hd->audio_abort_cb != NULL);
 
hd->audio_abort_cb = abort_cb;
 
-out:
mutex_unlock(>lock);
 
-   return ret;
+   return 0;
 }
 
 static int hdmi_audio_shutdown(struct device *dev)
@@ -633,12 +628,14 @@ static int hdmi_audio_start(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(>cfg));
-
spin_lock_irqsave(>audio_playing_lock, flags);
 
-   if (hd->display_enabled)
+   if (hd->display_enabled) {
+   if (!hdmi_mode_has_audio(>cfg))
+   DSSERR("%s: Video mode does not support audio\n",
+  __func__);
hdmi_start_audio_stream(hd);
+   }
hd->audio_playing = true;
 
spin_unlock_irqrestore(>audio_playing_lock, flags);
@@ -669,17 +666,15 @@ static int hdmi_audio_config(struct device *dev,
 
mutex_lock(>lock);
 
-   if (!hdmi_mode_has_audio(>cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
+   if (hd->display_enabled) {
+   ret = hdmi4_audio_config(>core, >wp, dss_audio,
+hd->cfg.vm.pixelclock);
+   if (ret)
+   goto out;
}
 
-   ret = hdmi4_audio_config(>core, >wp, dss_audio,
-hd->cfg.vm.pixelclock);
-   if (!ret) {
-   hd->audio_configured = true;
-   hd->audio_config = *dss_audio;
-   }
+   hd->audio_configured = true;
+   hd->audio_config = *dss_audio;
 out:
mutex_unlock(>lock);
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 9571be938d81..33297d282a61 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -593,21 +593,16 @@ static int hdmi_audio_startup(struct device *dev,
  void (*abort_cb)(struct device *dev))
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret = 0;
 
mutex_lock(>lock);
 
-   if (!hdmi_mode_has_audio(>cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
-   }
+   WARN_ON(hd->audio_abort_cb != NULL);
 
hd->audio_abort_cb = abort_cb;
 
-out:
mutex_unlock(>lock);
 
-   return ret;
+   return 0;
 }
 
 static int hdmi_audio_shutdown(struct device *dev)
@@ -628,12 +623,14 @@ static int hdmi_audio_start(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(>cfg));
-
spin_lock_irqsave(>audio_playing_lock, flags);
 
-   if (hd->display_enabled)
+   if (hd->display_enabled) {
+   if (!hdmi_mode_has_audio(>cfg))
+   DSSERR("%s: Video mode does not support audio\n",
+  __func__);
hdmi_start_audio_stream(hd);
+   }
hd->audio_playing = true;
 
spin_unlock_irqrestore(>audio_playing_lock, flags);
@@ -645,7 +642,8 @@ static void hdmi_audio_stop(struct device *dev)
struct omap_hdmi *hd = dev_get_drvdata(dev);
unsigned long flags;
 
-   WARN_ON(!hdmi_mode_has_audio(>cfg));
+   if (!hdmi_mode_has_audio(>cfg))
+   DSSERR("%s: Video mode does not support audio\n", __func__);
 
spin_lock_irqsave(>audio_playing_lock, flags);
 
@@ -664,18 +662,15 @@ static int hdmi_audio_config(struct device *dev,
 
mutex_lock(>lock);
 
-   if (!hdmi_mode_has_audio(>cfg) || !hd->display_enabled) {
-   ret = -EPERM;
-   goto out;
+   if (hd->display_enabled) {
+   ret = hdmi5_audio_config(>core, >wp, 

[PATCH 13/24] drm/omap: remove leftover enums

[Tomi Valkeinen]

A few enums are not used anywhere, so remove them.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index ac8ca37ff889..51aefd80bcd4 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -159,21 +159,6 @@ enum omap_overlay_caps {
OMAP_DSS_OVL_CAP_REPLICATION = 1 << 5,
 };
 
-enum omap_dss_clk_source {
-   OMAP_DSS_CLK_SRC_FCK = 0,   /* OMAP2/3: DSS1_ALWON_FCLK
-* OMAP4: DSS_FCLK */
-   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,   /* OMAP3: DSI1_PLL_FCLK
-* OMAP4: PLL1_CLK1 */
-   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI, /* OMAP3: DSI2_PLL_FCLK
-* OMAP4: PLL1_CLK2 */
-   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC,  /* OMAP4: PLL2_CLK1 */
-   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI,/* OMAP4: PLL2_CLK2 */
-};
-
-enum omap_hdmi_flags {
-   OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 << 0,
-};
-
 enum omap_dss_output_id {
OMAP_DSS_OUTPUT_DPI = 1 << 0,
OMAP_DSS_OUTPUT_DBI = 1 << 1,
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 22/24] drm/omap: fix maximum sizes

[Tomi Valkeinen]

We define max width and height in mode_config to 2048. These maximums
affect many things, which are independent and depend on platform. We
need to do more fine grained checks in the code paths for each
component, and so the maximum values in mode_config should just be "big
enough" to cover all use cases.

Change the maximum width & height to 8192.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 5a27a47b628e..2df125369781 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -412,11 +412,14 @@ static int omap_modeset_init(struct drm_device *dev)
dev->mode_config.min_width = 8;
dev->mode_config.min_height = 2;
 
-   /* note: eventually will need some cpu_is_omapXYZ() type stuff here
-* to fill in these limits properly on different OMAP generations..
+   /*
+* Note: these values are used for multiple independent things:
+* connector mode filtering, buffer sizes, crtc sizes...
+* Use big enough values here to cover all use cases, and do more
+* specific checking in the respective code paths.
 */
-   dev->mode_config.max_width = 2048;
-   dev->mode_config.max_height = 2048;
+   dev->mode_config.max_width = 8192;
+   dev->mode_config.max_height = 8192;
 
dev->mode_config.funcs = _mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helper_funcs;
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 20/24] drm/omap: fix scaling limits for WB

[Tomi Valkeinen]

WB has additional scaling limits when the output color format is one of
the YUV formats. These limits are not handled at the moment, causing
bad scaling and/or NULL dereference crash.

This patchs adds the check so that dispc returns an error for bad
scaling request.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 3d804187df13..2d19852553f5 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2381,7 +2381,8 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long 
pclk, unsigned long lclk,
 #define DIV_FRAC(dividend, divisor) \
((dividend) * 100 / (divisor) - ((dividend) / (divisor) * 100))
 
-static int dispc_ovl_calc_scaling(unsigned long pclk, unsigned long lclk,
+static int dispc_ovl_calc_scaling(enum omap_plane_id plane,
+   unsigned long pclk, unsigned long lclk,
enum omap_overlay_caps caps,
const struct videomode *vm,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2389,7 +2390,8 @@ static int dispc_ovl_calc_scaling(unsigned long pclk, 
unsigned long lclk,
int *x_predecim, int *y_predecim, u16 pos_x,
enum omap_dss_rotation_type rotation_type, bool mem_to_mem)
 {
-   const int maxdownscale = dispc.feat->max_downscale;
+   int maxhdownscale = dispc.feat->max_downscale;
+   int maxvdownscale = dispc.feat->max_downscale;
const int max_decim_limit = 16;
unsigned long core_clk = 0;
int decim_x, decim_y, ret;
@@ -2397,6 +2399,20 @@ static int dispc_ovl_calc_scaling(unsigned long pclk, 
unsigned long lclk,
if (width == out_width && height == out_height)
return 0;
 
+   if (plane == OMAP_DSS_WB) {
+   switch (fourcc) {
+   case DRM_FORMAT_NV12:
+   maxhdownscale = maxvdownscale = 2;
+   break;
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_UYVY:
+   maxhdownscale = 2;
+   maxvdownscale = 4;
+   break;
+   default:
+   break;
+   }
+   }
if (!mem_to_mem && (pclk == 0 || vm->pixelclock == 0)) {
DSSERR("cannot calculate scaling settings: pclk is zero\n");
return -EINVAL;
@@ -2414,8 +2430,8 @@ static int dispc_ovl_calc_scaling(unsigned long pclk, 
unsigned long lclk,
2 : max_decim_limit;
}
 
-   decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxdownscale);
-   decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxdownscale);
+   decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxhdownscale);
+   decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxvdownscale);
 
if (decim_x > *x_predecim || out_width > width * 8)
return -EINVAL;
@@ -2514,7 +2530,7 @@ static int dispc_ovl_setup_common(enum omap_plane_id 
plane,
if (!dispc_ovl_color_mode_supported(plane, fourcc))
return -EINVAL;
 
-   r = dispc_ovl_calc_scaling(pclk, lclk, caps, vm, in_width,
+   r = dispc_ovl_calc_scaling(plane, pclk, lclk, caps, vm, in_width,
in_height, out_width, out_height, fourcc,
_taps, _predecim, _predecim, pos_x,
rotation_type, mem_to_mem);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 17/24] drm/omap: fix WBDELAYCOUNT for HDMI

[Tomi Valkeinen]

For HDMI, WBDELAYCOUNT starts counting at the start of vsync, not at the
start of vfp.

This patch adjusts the wbdelay for HDMI accordingly.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 7f9186894bd5..669ee9df224b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2712,8 +2712,12 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
} else {
int wbdelay;
 
-   wbdelay = min(vm->vfront_porch +
- vm->vsync_len + vm->vback_porch, (u32)255);
+   if (channel_in == DSS_WB_TV_MGR)
+   wbdelay = min(vm->vsync_len + vm->vback_porch,
+   (u32)255);
+   else
+   wbdelay = min(vm->vfront_porch +
+   vm->vsync_len + vm->vback_porch, (u32)255);
 
/* WBDELAYCOUNT */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), wbdelay, 7, 0);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 19/24] drm/omap: fix WB height with interlace

[Tomi Valkeinen]

When using WB capture from interlaced source, we need to halve the
picture heights correctly.

Unfortunately the current dispc_ovl_setup_common() doesn't deal with
interlace very neatly, so the end result is a bit messy.

Signed-off-by: Tomi Valkeinen 
Acked-by: Benoit Parrot 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 99bbc97d0de4..3d804187df13 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2496,18 +2496,19 @@ static int dispc_ovl_setup_common(enum omap_plane_id 
plane,
out_width = out_width == 0 ? width : out_width;
out_height = out_height == 0 ? height : out_height;
 
-   if (ilace && height == out_height)
-   fieldmode = true;
-
-   if (ilace) {
-   if (fieldmode)
-   in_height /= 2;
-   pos_y /= 2;
-   out_height /= 2;
-
-   DSSDBG("adjusting for ilace: height %d, pos_y %d, "
-   "out_height %d\n", in_height, pos_y,
-   out_height);
+   if (plane != OMAP_DSS_WB) {
+   if (ilace && height == out_height)
+   fieldmode = true;
+
+   if (ilace) {
+   if (fieldmode)
+   in_height /= 2;
+   pos_y /= 2;
+   out_height /= 2;
+
+   DSSDBG("adjusting for ilace: height %d, pos_y %d, 
out_height %d\n",
+   in_height, pos_y, out_height);
+   }
}
 
if (!dispc_ovl_color_mode_supported(plane, fourcc))
@@ -2667,6 +2668,9 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
enum omap_overlay_caps caps =
OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
 
+   if (vm->flags & DISPLAY_FLAGS_INTERLACED)
+   in_height /= 2;
+
DSSDBG("dispc_wb_setup, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
"rot %d\n", wi->paddr, wi->p_uv_addr, in_width,
in_height, wi->width, wi->height, wi->fourcc, wi->rotation);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 15/24] drm/omap: Add pclk setting case when channel is DSS_WB

[Tomi Valkeinen]

From: Benoit Parrot 

In dispc_set_ovl_common() we need to initialize pclk to a valid
value when we use WB in capture mode (i.e. mem_2_mem is false).
Otherwise dispc_ovl_calc_scaling() fails.

Signed-off-by: Benoit Parrot 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 30bcee6580f5..5e7bdff2821d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2488,6 +2488,10 @@ static int dispc_ovl_setup_common(enum omap_plane_id 
plane,
unsigned long pclk = dispc_plane_pclk_rate(plane);
unsigned long lclk = dispc_plane_lclk_rate(plane);
 
+   /* when setting up WB, dispc_plane_pclk_rate() returns 0 */
+   if (plane == OMAP_DSS_WB)
+   pclk = vm->pixelclock;
+
if (paddr == 0 && rotation_type != OMAP_DSS_ROT_TILER)
return -EINVAL;
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 21/24] drm/omap: add writeback funcs to dispc_ops

[Tomi Valkeinen]

Add writeback specific dispc functions to dispc_ops so that omapdrm can
use them.  Also move 'enum dss_writeback_channel' to the public
omapdss.h for omapdrm.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 19 +++
 drivers/gpu/drm/omapdrm/dss/dss.h | 19 ---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 19 +++
 3 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 2d19852553f5..ff09e2be470f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -698,7 +698,7 @@ static u32 dispc_mgr_get_sync_lost_irq(enum omap_channel 
channel)
return mgr_desc[channel].sync_lost_irq;
 }
 
-u32 dispc_wb_get_framedone_irq(void)
+static u32 dispc_wb_get_framedone_irq(void)
 {
return DISPC_IRQ_FRAMEDONEWB;
 }
@@ -730,12 +730,12 @@ static void dispc_mgr_go(enum omap_channel channel)
mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
 }
 
-bool dispc_wb_go_busy(void)
+static bool dispc_wb_go_busy(void)
 {
return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
 }
 
-void dispc_wb_go(void)
+static void dispc_wb_go(void)
 {
enum omap_plane_id plane = OMAP_DSS_WB;
bool enable, go;
@@ -2668,7 +2668,7 @@ static int dispc_ovl_setup(enum omap_plane_id plane,
return r;
 }
 
-int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
+static int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
bool mem_to_mem, const struct videomode *vm,
enum dss_writeback_channel channel_in)
 {
@@ -2750,6 +2750,11 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
return 0;
 }
 
+static bool dispc_has_writeback(void)
+{
+   return dispc.feat->has_writeback;
+}
+
 static int dispc_ovl_enable(enum omap_plane_id plane, bool enable)
 {
DSSDBG("dispc_enable_plane %d, %d\n", plane, enable);
@@ -4553,6 +4558,12 @@ static const struct dispc_ops dispc_ops = {
.ovl_enable = dispc_ovl_enable,
.ovl_setup = dispc_ovl_setup,
.ovl_get_color_modes = dispc_ovl_get_color_modes,
+
+   .wb_get_framedone_irq = dispc_wb_get_framedone_irq,
+   .wb_setup = dispc_wb_setup,
+   .has_writeback = dispc_has_writeback,
+   .wb_go_busy = dispc_wb_go_busy,
+   .wb_go = dispc_wb_go,
 };
 
 /* DISPC HW IP initialisation */
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 19143ab5393c..e2e679544e41 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -97,17 +97,6 @@ enum dss_dsi_content_type {
DSS_DSI_CONTENT_GENERIC,
 };
 
-enum dss_writeback_channel {
-   DSS_WB_LCD1_MGR =   0,
-   DSS_WB_LCD2_MGR =   1,
-   DSS_WB_TV_MGR = 2,
-   DSS_WB_OVL0 =   3,
-   DSS_WB_OVL1 =   4,
-   DSS_WB_OVL2 =   5,
-   DSS_WB_OVL3 =   6,
-   DSS_WB_LCD3_MGR =   7,
-};
-
 enum dss_clk_source {
DSS_CLK_SRC_FCK = 0,
 
@@ -380,14 +369,6 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
 void dispc_set_tv_pclk(unsigned long pclk);
 
-u32 dispc_wb_get_framedone_irq(void);
-bool dispc_wb_go_busy(void);
-void dispc_wb_go(void);
-void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
-int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
-   bool mem_to_mem, const struct videomode *vm,
-   enum dss_writeback_channel channel_in);
-
 #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
 static inline void dss_collect_irq_stats(u32 irqstatus, unsigned int *irq_arr)
 {
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 51aefd80bcd4..2139735878c8 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -618,6 +618,17 @@ void omapdss_set_is_initialized(bool set);
 struct device_node *dss_of_port_get_parent_device(struct device_node *port);
 u32 dss_of_port_get_port_number(struct device_node *port);
 
+enum dss_writeback_channel {
+   DSS_WB_LCD1_MGR =   0,
+   DSS_WB_LCD2_MGR =   1,
+   DSS_WB_TV_MGR = 2,
+   DSS_WB_OVL0 =   3,
+   DSS_WB_OVL1 =   4,
+   DSS_WB_OVL2 =   5,
+   DSS_WB_OVL3 =   6,
+   DSS_WB_LCD3_MGR =   7,
+};
+
 struct dss_mgr_ops {
int (*connect)(enum omap_channel channel,
struct omap_dss_device *dst);
@@ -700,6 +711,14 @@ struct dispc_ops {
enum omap_channel channel);
 
const u32 *(*ovl_get_color_modes)(enum omap_plane_id plane);
+
+   u32 (*wb_get_framedone_irq)(void);
+   int (*wb_setup)(const struct omap_dss_writeback_info *wi,
+   bool mem_to_mem, const struct videomode *vm,
+   enum