[Bug 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

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

--- Comment #4 from Carlo Caione  ---
Great, thank you.

Any special reason why you decided to disable the DC support for pre-VEGA
ASICs?

-- 
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] cma: Take __GFP_NOWARN into account in cma_alloc()

[Jaewon Kim]

Hello

2017-10-04 21:54 GMT+09:00 Boris Brezillon :
> cma_alloc() unconditionally prints an INFO message when the CMA
> allocation fails. Make this message conditional on the non-presence of
> __GFP_NOWARN in gfp_mask.
>
> Signed-off-by: Boris Brezillon 
> ---
> Hello,
>
> This patch aims at removing INFO messages that are displayed when the
> VC4 driver tries to allocate buffer objects. From the driver perspective
> an allocation failure is acceptable, and the driver can possibly do
> something to make following allocation succeed (like flushing the VC4
> internal cache).
When I made the patch, there was no GFP.
In my opinion, it is a good idea removing log in case of __GFP_NOWARN.
>
> Also, I don't understand why this message is only an INFO message, and
> not a WARN (pr_warn()). Please let me know if you have good reasons to
> keep it as an unconditional pr_info().
Thank to Michal Hocko, I changed to pr_info rather than just printk in
my first patch code.
https://marc.info/?l=linux-mm&m=148300462103801&w=2
I thought it is just info. It can be pr_warn if need.

Thank you
Jaewon Kim
>
> Thanks,
>
> Boris
> ---
>  mm/cma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index c0da318c020e..022e52bd8370 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
> unsigned int align,
>
> trace_cma_alloc(pfn, page, count, align);
>
> -   if (ret) {
> +   if (ret && !(gfp_mask & __GFP_NOWARN)) {
> pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
> __func__, count, ret);
> cma_debug_show_areas(cma);
> --
> 2.11.0
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] cma: Take __GFP_NOWARN into account in cma_alloc()

[Anshuman Khandual]

On 10/04/2017 06:24 PM, Boris Brezillon wrote:
> cma_alloc() unconditionally prints an INFO message when the CMA
> allocation fails. Make this message conditional on the non-presence of
> __GFP_NOWARN in gfp_mask.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Hello,
> 
> This patch aims at removing INFO messages that are displayed when the
> VC4 driver tries to allocate buffer objects. From the driver perspective
> an allocation failure is acceptable, and the driver can possibly do
> something to make following allocation succeed (like flushing the VC4
> internal cache).
> 
> Also, I don't understand why this message is only an INFO message, and
> not a WARN (pr_warn()). Please let me know if you have good reasons to
> keep it as an unconditional pr_info()

Making it conditional (__GFP_NOWARN based what you already have) with
pr_warn() message makes more sense.

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

[PATCH] drm/i915: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Thomas Gleixner 
Signed-off-by: Kees Cook 
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callback argument type") in v4.14-rc3, but should be otherwise
stand-alone.
---
 drivers/gpu/drm/i915/selftests/mock_engine.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c 
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index fc0fd7498689..331c2b09869e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -32,9 +32,9 @@ static struct mock_request *first_request(struct mock_engine 
*engine)
link);
 }
 
-static void hw_delay_complete(unsigned long data)
+static void hw_delay_complete(struct timer_list *t)
 {
-   struct mock_engine *engine = (typeof(engine))data;
+   struct mock_engine *engine = from_timer(engine, t, hw_delay);
struct mock_request *request;
 
spin_lock(&engine->hw_lock);
@@ -161,9 +161,7 @@ struct intel_engine_cs *mock_engine(struct drm_i915_private 
*i915,
 
/* fake hw queue */
spin_lock_init(&engine->hw_lock);
-   setup_timer(&engine->hw_delay,
-   hw_delay_complete,
-   (unsigned long)engine);
+   timer_setup(&engine->hw_delay, hw_delay_complete, 0);
INIT_LIST_HEAD(&engine->hw_queue);
 
return &engine->base;
-- 
2.7.4


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

Re: [PATCH 09/12] of: overlay: avoid race condition between applying multiple overlays

[Frank Rowand]

On 10/04/17 08:19, Rob Herring wrote:
> On Mon, Oct 2, 2017 at 10:53 PM,   wrote:
>> From: Frank Rowand 
>>
>> The process of applying an overlay consists of:
>>   - unflatten an overlay FDT (flattened device tree) into an
>> EDT (expanded device tree)
>>   - fixup the phandle values in the overlay EDT to fit in a
>> range above the phandle values in the live device tree
>>   - create the overlay changeset to reflect the contents of
>> the overlay EDT
>>   - apply the overlay changeset, to modify the live device tree,
>> potentially changing the maximum phandle value in the live
>> device tree
>>
>> There is currently no protection against two overlay applies
>> concurrently determining what range of phandle values are in use
>> in the live device tree, and subsequently changing that range.
>> Add a mutex to prevent multiple overlay applies from occurring
>> simultaneously.
>>
>> Ignoring 2 checkpatch warnings: Prefer using '"%s...", __func__'
>> so that the WARN() string will be more easily grepped.
>>
>> Signed-off-by: Frank Rowand 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c |  7 +++
>>  drivers/of/overlay.c | 22 ++
>>  drivers/of/unittest.c| 21 +
>>  include/linux/of.h   | 19 +++
>>  4 files changed, 69 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
>> b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> index 7a7be0515bfd..c99f7924b1c6 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> @@ -221,6 +221,11 @@ static void __init tilcdc_convert_slave_node(void)
>> goto out;
>> }
>>
>> +   /*
>> +* protect from of_resolve_phandles() through of_overlay_apply()
>> +*/
>> +   of_overlay_mutex_lock();
>> +
> 
> We can't be relying on callers to get the locking right...

Agreed.


> 
>> overlay = tilcdc_get_overlay(&kft);
>> if (!overlay)
>> goto out;
>> @@ -256,6 +261,8 @@ static void __init tilcdc_convert_slave_node(void)
>> pr_info("%s: ti,tilcdc,slave node successfully converted\n",
>> __func__);
>>  out:
>> +   of_overlay_mutex_unlock();
>> +
>> kfree_table_free(&kft);
>> of_node_put(i2c);
>> of_node_put(slave);
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index a0d3222febdc..4ed372af6ce7 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -71,6 +71,28 @@ static int build_changeset_next_level(struct 
>> overlay_changeset *ovcs,
>> const struct device_node *overlay_node,
>> bool is_symbols_node);
>>
>> +/*
>> + * of_resolve_phandles() finds the largest phandle in the live tree.
>> + * of_overlay_apply() may add a larger phandle to the live tree.
>> + * Do not allow race between two overlays being applied simultaneously:
>> + *mutex_lock(&of_overlay_phandle_mutex)
>> + *of_resolve_phandles()
>> + *of_overlay_apply()
>> + *mutex_unlock(&of_overlay_phandle_mutex)
> 
> Why do these need to be separate functions? I think I mentioned it
> before, but essentially overlay_data_add() should be part of the
> overlay API. We may need to allow for callers to do each step, but
> generally I think the interface should just be "apply this fdt blob".

Yes, that is where I want to end up.

> 
> Rob
> 

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

Re: [PATCH 00/12] of: overlay: clean up device tree overlay code

[Jyri Sarha]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 10/05/17 09:53, Tomi Valkeinen wrote:
> On 04/10/17 17:56, Rob Herring wrote:
>> On Mon, Oct 2, 2017 at 10:53 PM,   wrote:
>>> From: Frank Rowand 
>>>
>>> I have found the device tree overlay code to be difficult to read and
>>> maintain.  This patch series attempts to improve that situation.
>>>
>>> The cleanup includes some changes visible to users of overlays.  The
>>> only in kernel user of overlays is fixed up for those changes.  The
>>> in kernel user is:
>>>
>>>drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>
>> At what point can we remove this? I'm assuming at some point users
>> will need to update their dtb's for other reasons and this becomes
>> obsolete.
> 
> To be honest, I have no idea, or how to find that out.
> 

I think the first approach could be setting the DRM_TILCDC_SLAVE_COMPAT
default to n and listen if there is any reports about breakage.

> Do we need to get rid of it? Afaik, we haven't do much (or any?)
> maintenance on tilcdc_slave_compat.c since it was written, so from our
> perspective it's been a minimal burden. Is it creating burden for others?
> 
> Is the approach done with tilcdc_slave_compat.c something that's not
> recommended? I'm sure similar situations happen with other drivers too,
> and I think it's a good idea to have a recommended way of keeping
> compatibility.
> 

For tilcdc I would say that we soon need a similar mechanism to get rid
off tilcdc internal panel driver and to start using generic panel
drivers instead. That is, if we want to keep the kernel compatible with
old devicetree blobs.

Best regards,
Jyri

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

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

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #2 from Chris Wilson  ---
Just your regular invalid negative test.

-- 
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/gem-cma-helper: Change the level of the allocation failure message

[Eric Engestrom]

On Wednesday, 2017-10-04 22:28:54 +, Eric Anholt wrote:
> Boris Brezillon  writes:
> 
> > drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> > allocate the amount of memory we requested. This can lead to annoying
> > error messages when CMA is only one possible source of memory for the BO
> > allocation.
> >
> > Turn this error message into a debug one and add a __must_check specifier
> > to make sure all callers are checking the return value.
> >
> > Signed-off-by: Boris Brezillon 
> 
> The __must_check seems unnecessary to me -- you're definitely going to
> be doing something with the return value, because otherwise why did you
> call the object allocate function?

Indeed, `__must_check` (aka `warn_unused_result`) only makes sure the
return value is not discarded, which will probably always be true here.

> The `warn_unused_result` attribute causes a warning to be emitted if
> a caller of the function with this attribute does not use its return
> value.

I think we need a sparse attribute to check that the return value is
IS_ERR()-checked?
(not volunteering, I have no idea how to add a sparse attribute :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem-cma-helper: Change the level of the allocation failure message

[Boris Brezillon]

On Thu, 5 Oct 2017 09:48:24 +0100
Eric Engestrom  wrote:

> On Wednesday, 2017-10-04 22:28:54 +, Eric Anholt wrote:
> > Boris Brezillon  writes:
> >   
> > > drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> > > allocate the amount of memory we requested. This can lead to annoying
> > > error messages when CMA is only one possible source of memory for the BO
> > > allocation.
> > >
> > > Turn this error message into a debug one and add a __must_check specifier
> > > to make sure all callers are checking the return value.
> > >
> > > Signed-off-by: Boris Brezillon   
> > 
> > The __must_check seems unnecessary to me -- you're definitely going to
> > be doing something with the return value, because otherwise why did you
> > call the object allocate function?  
> 
> Indeed, `__must_check` (aka `warn_unused_result`) only makes sure the
> return value is not discarded, which will probably always be true here.

I agree, this __must_check is not really useful here.

> 
> > The `warn_unused_result` attribute causes a warning to be emitted if
> > a caller of the function with this attribute does not use its return
> > value.  
> 
> I think we need a sparse attribute to check that the return value is
> IS_ERR()-checked?

Can we just turn the dev_err() into dev_dbg() for now? The 'force
callers to check IS_ERR()' is kind of orthogonal to the change I'm
doing here.

> (not volunteering, I have no idea how to add a sparse attribute :)

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

Re: [PATCH] drm/gem-cma-helper: Change the level of the allocation failure message

[Eric Engestrom]

On Thursday, 2017-10-05 10:57:47 +0200, Boris Brezillon wrote:
> On Thu, 5 Oct 2017 09:48:24 +0100
> Eric Engestrom  wrote:
> 
> > On Wednesday, 2017-10-04 22:28:54 +, Eric Anholt wrote:
> > > Boris Brezillon  writes:
> > >   
> > > > drm_gem_cma_create() prints an error message when dma_alloc_wc() fails 
> > > > to
> > > > allocate the amount of memory we requested. This can lead to annoying
> > > > error messages when CMA is only one possible source of memory for the BO
> > > > allocation.
> > > >
> > > > Turn this error message into a debug one and add a __must_check 
> > > > specifier
> > > > to make sure all callers are checking the return value.
> > > >
> > > > Signed-off-by: Boris Brezillon   
> > > 
> > > The __must_check seems unnecessary to me -- you're definitely going to
> > > be doing something with the return value, because otherwise why did you
> > > call the object allocate function?  
> > 
> > Indeed, `__must_check` (aka `warn_unused_result`) only makes sure the
> > return value is not discarded, which will probably always be true here.
> 
> I agree, this __must_check is not really useful here.
> 
> > 
> > > The `warn_unused_result` attribute causes a warning to be emitted if
> > > a caller of the function with this attribute does not use its return
> > > value.  
> > 
> > I think we need a sparse attribute to check that the return value is
> > IS_ERR()-checked?
> 
> Can we just turn the dev_err() into dev_dbg() for now? The 'force
> callers to check IS_ERR()' is kind of orthogonal to the change I'm
> doing here.

Definitely, the function you're touching just happens to be a user of
this potential new attribute.

IMO just drop the header part of the change, and this is
Reviewed-by: Eric Engestrom 

On the sparse attribute discussion, anyone knows someone with experience
doing that?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Pekka Paalanen]

On Tue, 29 Aug 2017 10:32:11 +0300
Peter Ujfalusi  wrote:

> Hi
> 
> The series adds support for changing the order of the displays defined by DT
> display aliases.
> 
> The motivation to do such a thing is that for example the fb emulation is
> treating the first display/crtc as the 'main' display and will create the
> fb emulation based on the first display's properties.
> There are many custom applications using DRM directly and they assume that the
> first connector is the 'main' display.
> Afaik weston provides no means either to change the 'main/preferred' display.

Hi,

that's because Weston does not have a concept of main or preferred
display to begin with.

If what you refer to involves running Weston with the fbdev-backend,
then Weston has nothing to do with the issue. Weston only
uses /dev/fb0, whatever that might be and however that might work, as
set up by the kernel.


Thanks,
pq

> 
> It should be the work of user space application (except the fb emulation) to
> somehow deal with the 'main' display selection for their needs, but
> unfortunately they are not capable of diong so for some reason.
> 
> We have boards with LCD panel and HDMI for example and in DT the LCD is set as
> display0, but in certain useage scenarios it is desired to have the HDMI as 
> the
> 'main' display instead of the LCD.
> 
> With the kernel cmd line parameter it is possible to change the pre defined
> order without recompiling the kernel/DT.
> 
> If the board have two active displays:
> 0 - LCD
> 1 - HDMI
> then:
> omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
> omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
> omapdrm.displays=0 - only the LCD is enabled
> omapdrm.displays=1 - only the HDMI is enabled
> omapdrm.displays=-1 - disable all displays
> 
> The first 6 patch of the series is doing some generic clean up and prepares 
> the
> code so the display ordering is going to be easy to add.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (7):
>   drm/omap: Use devm_kzalloc() to allocate omap_drm_private
>   drm/omap: Allocate drm_device earlier and unref it as last step
>   drm/omap: Manage the usable omap_dss_device list within
> omap_drm_private
>   drm/omap: Separate the dssdevs array setup from the connect function
>   drm/omap: Do dss_device (display) ordering in omap_drv.c
>   drm/omap: dss: Remove display ordering from dss/display.c
>   drm/omap: Add kernel parameter to specify the desired display order
> 
>  drivers/gpu/drm/omapdrm/dss/display.c |  15 +--
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   3 -
>  drivers/gpu/drm/omapdrm/omap_drv.c| 244 
> --
>  drivers/gpu/drm/omapdrm/omap_drv.h|   3 +
>  4 files changed, 183 insertions(+), 82 deletions(-)
> 



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

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Tomi Valkeinen]

Hi,


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 05/10/17 12:56, Pekka Paalanen wrote:

> that's because Weston does not have a concept of main or preferred
> display to begin with.
> 
> If what you refer to involves running Weston with the fbdev-backend,
> then Weston has nothing to do with the issue. Weston only
> uses /dev/fb0, whatever that might be and however that might work, as
> set up by the kernel.

No, it's with DRM backend.

If I recall right, the problem is that when you open a window, it opens
on the first display (first DRM connector). Or (again, if I recall
right), if the mouse pointer is on a particular display, then the window
opens there. So no means to say "run this application and put its
windows on the HDMI display".

 Tomi

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

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Pekka Paalanen]

On Thu, 5 Oct 2017 13:01:50 +0300
Tomi Valkeinen  wrote:

> Hi,
> 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 05/10/17 12:56, Pekka Paalanen wrote:
> 
> > that's because Weston does not have a concept of main or preferred
> > display to begin with.
> > 
> > If what you refer to involves running Weston with the fbdev-backend,
> > then Weston has nothing to do with the issue. Weston only
> > uses /dev/fb0, whatever that might be and however that might work, as
> > set up by the kernel.  
> 
> No, it's with DRM backend.
> 
> If I recall right, the problem is that when you open a window, it opens
> on the first display (first DRM connector). Or (again, if I recall
> right), if the mouse pointer is on a particular display, then the window
> opens there. So no means to say "run this application and put its
> windows on the HDMI display".

Hi Tomi,

in Weston, the initial window placement is essentially random. There is
some guessing based on the current pointer location, but as there could
be several pointers, that's not reliable either. When there is no
pointer to guess from and Weston needs to pick an output, it simply
picks the first in a list. We might as well randomize it too, since all
outputs are equal in the current design. Only luck guarantees the order
in the output list.

If an application wants to show up on a specific output, there is
currently no Wayland extension that I recall to allow that, aside from
IVI-shell/LayerManager infrastructure. If you really need something on
a specific output, one way is to write a new protocol extension that
suits your use case, especially if your use case is not a normal PC
desktop.

If your use case is a normal PC desktop, then you could participate in
the xdg-shell protocol suite development to get a desktop standard for
initial window placement. That would probably be preceded by designing
a protocol extension that would let clients meaningfully choose an
initial output to begin with.

There is also the option of writing your own shell plugin to Weston, to
give you exactly the window management behaviour you want, including
the choice of the output.

The very least, there was some work towards configuring the output
layout in weston.ini that is still unfinished, which might perhaps
provide a workaround similar to changing connector ordering but with
only half the luck required. There is already a way to turn a connector
off in weston.ini, and my current work is aiming to allow
force-enabling disconnected connectors as well.

Changing connector ordering in the kernel to get Weston to do something
it has never deliberately intended in the first place is just wrong, so
please do not use Weston as a justification for this kernel module
parameter.


Thanks,
pq


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

[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-10-05:
One bugfix in sun4i for 4.14

Cheers, Daniel
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:

  Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-10-05

for you to fetch changes up to cb1dab0e01969d63717c7464cb5d75c77a39bf02:

  drm/sun4i: hdmi: Disable clks in bind function error path and unbind function 
(2017-10-02 21:58:47 +0200)


One bugfix in sun4i for 4.14


Chen-Yu Tsai (1):
  drm/sun4i: hdmi: Disable clks in bind function error path and unbind 
function

 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

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

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Tomi Valkeinen]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 05/10/17 13:43, Pekka Paalanen wrote:

> in Weston, the initial window placement is essentially random. There is
> some guessing based on the current pointer location, but as there could
> be several pointers, that's not reliable either. When there is no
> pointer to guess from and Weston needs to pick an output, it simply
> picks the first in a list. We might as well randomize it too, since all
> outputs are equal in the current design. Only luck guarantees the order
> in the output list.

Please don't make our lives harder, just because =). As you explain
above, it is not random at the moment.

I understand relying on the above logic is not very good, and it can
change in the future, but as you explain below, we're not in a position
where we have a good way to deal with the use case at the moment.

> If an application wants to show up on a specific output, there is
> currently no Wayland extension that I recall to allow that, aside from
> IVI-shell/LayerManager infrastructure. If you really need something on
> a specific output, one way is to write a new protocol extension that
> suits your use case, especially if your use case is not a normal PC
> desktop.

Yes, we really need something on a specific user-defined output. One of
the use cases is a board with an LCD with touchscreen and an HDMI. No
mouse. So the pointer is never on the HDMI. We may want to launch a
"view-only" application shown on the HDMI.

Or, we may have a mouse, and use the HDMI as the "main screen", which
means that our launcher application is shown on the HDMI instead of the LCD.

Or we may not have any mouse/touchscreen at all (although if I recall
right, this needs a hack in weston to get it start), and we want to
launch applications on specific screen.

Just a few examples.

And yes, if you create a real product, perhaps IVI-shell or such is the
way to go. Our use is more of a development/demo cases, although I don't
see why they would not be usable in a real product too.

I think just having an env variable, which gives a hint to weston about
on which display the window should be openend, would cover our use cases.

> If your use case is a normal PC desktop, then you could participate in
> the xdg-shell protocol suite development to get a desktop standard for
> initial window placement. That would probably be preceded by designing
> a protocol extension that would let clients meaningfully choose an
> initial output to begin with.
> 
> There is also the option of writing your own shell plugin to Weston, to
> give you exactly the window management behaviour you want, including
> the choice of the output.
> 
> The very least, there was some work towards configuring the output
> layout in weston.ini that is still unfinished, which might perhaps
> provide a workaround similar to changing connector ordering but with
> only half the luck required. There is already a way to turn a connector
> off in weston.ini, and my current work is aiming to allow
> force-enabling disconnected connectors as well.
> 
> Changing connector ordering in the kernel to get Weston to do something
> it has never deliberately intended in the first place is just wrong, so
> please do not use Weston as a justification for this kernel module
> parameter.

Weston was just one piece of the puzzle. If it was just Weston, I guess
we'd have looked at patching Weston instead of the kernel.

As the cover letter says, it's also about the fb emulation and custom
DRM apps. It seems quite common for these applications to just pick the
first connector. And the series also gives features for debugging,
testing, and disabling displays altogether.

The series is an RFC, and kind of feels like a hack. I think the order
of the DRM connectors should be considered random, in a perfect world.
Still, this series fixes real issues without the need to go fix every
broken/not-finished legacy and non-legacy app out there that uses DRM,
and gives us some debug/test functionality.

 Tomi

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

[PATCH v2] drm/gem-cma-helper: Change the level of the allocation failure message

[Boris Brezillon]

drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
allocate the amount of memory we requested. This can lead to annoying
error messages when CMA is only one possible source of memory for the BO
allocation. Turn this error message into a debug one.

Signed-off-by: Boris Brezillon 
Reviewed-by: Daniel Vetter 
Reviewed-by: Eric Engestrom 
---
Changes in v2:
- Remove __must_check attribute
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 373e33f22be4..020e7668dfab 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -112,7 +112,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
drm_device *drm,
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
  GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
-   dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
+   dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
size);
ret = -ENOMEM;
goto error;
-- 
2.11.0

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

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Pekka Paalanen]

On Thu, 5 Oct 2017 14:24:27 +0300
Tomi Valkeinen  wrote:

> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 05/10/17 13:43, Pekka Paalanen wrote:
> 
> > in Weston, the initial window placement is essentially random. There is
> > some guessing based on the current pointer location, but as there could
> > be several pointers, that's not reliable either. When there is no
> > pointer to guess from and Weston needs to pick an output, it simply
> > picks the first in a list. We might as well randomize it too, since all
> > outputs are equal in the current design. Only luck guarantees the order
> > in the output list.  
> 
> Please don't make our lives harder, just because =). As you explain
> above, it is not random at the moment.
> 
> I understand relying on the above logic is not very good, and it can
> change in the future, but as you explain below, we're not in a position
> where we have a good way to deal with the use case at the moment.

As long as you are aware it can break any time. *I* won't break it just
for the sake of it. :-)

But I also don't intend to make sure the behaviour stays the same.

> > If an application wants to show up on a specific output, there is
> > currently no Wayland extension that I recall to allow that, aside from
> > IVI-shell/LayerManager infrastructure. If you really need something on
> > a specific output, one way is to write a new protocol extension that
> > suits your use case, especially if your use case is not a normal PC
> > desktop.  
> 
> Yes, we really need something on a specific user-defined output. One of
> the use cases is a board with an LCD with touchscreen and an HDMI. No
> mouse. So the pointer is never on the HDMI. We may want to launch a
> "view-only" application shown on the HDMI.
> 
> Or, we may have a mouse, and use the HDMI as the "main screen", which
> means that our launcher application is shown on the HDMI instead of the LCD.
> 
> Or we may not have any mouse/touchscreen at all (although if I recall
> right, this needs a hack in weston to get it start), and we want to
> launch applications on specific screen.
> 
> Just a few examples.

Right, all those point in the direction of a custom shell plugin where
you can have your window management rules. Trying to drive window
management from outside a Wayland compositor is not a good idea...

> And yes, if you create a real product, perhaps IVI-shell or such is the
> way to go. Our use is more of a development/demo cases, although I don't
> see why they would not be usable in a real product too.

..which is why I never liked the IVI LayerManager etc. approach much.

IVI-shell is really just a wrapper that still wants you to write a
plugin to do the actual window management. On the application facing
side it removes all the desktop windowing features and literally just
offers you a window ID number to base window management on. No
provision for clients to tell the output, aside from what you can imply
with an ID.

> I think just having an env variable, which gives a hint to weston about
> on which display the window should be openend, would cover our use cases.

That is a very special environment where one could expect that to work.

That would be possible given:
- a protocol extension to relay the wanted output
- client toolkit patch to read the env var and use the protocol
  extension
- a new weston shell plugin to implement the protocol extension

If one were to write a special protocol extension just for your use
case, the extension could be dead simple.

There is another plugin in Weston, fullscreen-shell, but it is in a bit
bad shape and only supports a single client at a time, but allows
explicit control of outputs. It has no window management as it has no
windows: you associate a wl_surface for an output, and that's it. If
you needed windows, you could use sub-surfaces.

> > If your use case is a normal PC desktop, then you could participate in
> > the xdg-shell protocol suite development to get a desktop standard for
> > initial window placement. That would probably be preceded by designing
> > a protocol extension that would let clients meaningfully choose an
> > initial output to begin with.
> > 
> > There is also the option of writing your own shell plugin to Weston, to
> > give you exactly the window management behaviour you want, including
> > the choice of the output.
> > 
> > The very least, there was some work towards configuring the output
> > layout in weston.ini that is still unfinished, which might perhaps
> > provide a workaround similar to changing connector ordering but with
> > only half the luck required. There is already a way to turn a connector
> > off in weston.ini, and my current work is aiming to allow
> > force-enabling disconnected connectors as well.
> > 
> > Changing connector ordering in the kernel to get Weston to do something
> > it has never deliberately intended in the first

[PATCH] drm/i915/selftests: fix check for intel IOMMU

[Arnd Bergmann]

An earlier bugfix tried to work around this build failure:

drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device':
drivers/gpu/drm/i915/selftests/mock_gem_device.c:151:20: error: 'struct 
dev_archdata' has no member named 'iommu'

Checking for CONFIG_IOMMU_API is not sufficient as a compile-time
test since that may be enabled in configurations that have neither
INTEL_IOMMU not AMD_IOMMU enabled. This changes the check to
INTEL_IOMMU instead, as this is the only case we actually care about.

Fixes: f46f156ea770 ("drm/i915/selftests: Only touch archdata.iommu when it 
exists")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 2388424a14da..3b7877884dd1 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -146,7 +146,7 @@ struct drm_i915_private *mock_gem_device(void)
dev_set_name(&pdev->dev, "mock");
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
 
-#if IS_ENABLED(CONFIG_IOMMU_API)
+#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
/* hack to disable iommu for the fake device; force identity mapping */
pdev->dev.archdata.iommu = (void *)-1;
 #endif
-- 
2.9.0

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

[PATCH] drm/i915: avoid potential uninitialized variable use

[Arnd Bergmann]

One of the recent changes introduced a warning about
undefined behavior in the sanity checking:

drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_hdmi_level':
drivers/gpu/drm/i915/intel_ddi.c:654:6: error: 'n_hdmi_entries' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

It seems that the new cnl specific get_buf_trans functions
can return uninitialized data if the voltage level is set
to an unexpected value. This changes the code to always return
'1' in that error case, which seems like the safest choice
as we use one less than the number as an array index later on.

Fixes: cc9cabfdec38 ("drm/i915/cnl: Move voltage check into ddi buf trans 
functions.")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/intel_ddi.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 93cbbcbbc193..d0b786078bea 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -602,8 +602,10 @@ cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, 
int *n_entries)
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
return cnl_ddi_translations_hdmi_1_05V;
-   } else
+   } else {
+   *n_entries = 1;
MISSING_CASE(voltage);
+   }
return NULL;
 }
 
@@ -621,8 +623,10 @@ cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
int *n_entries)
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_1_05V);
return cnl_ddi_translations_dp_1_05V;
-   } else
+   } else {
+   *n_entries = 1;
MISSING_CASE(voltage);
+   }
return NULL;
 }
 
@@ -641,8 +645,10 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
} else if (voltage == VOLTAGE_INFO_1_05V) {
*n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_1_05V);
return cnl_ddi_translations_edp_1_05V;
-   } else
+   } else {
+   *n_entries = 1;
MISSING_CASE(voltage);
+   }
return NULL;
} else {
return cnl_get_buf_trans_dp(dev_priv, n_entries);
-- 
2.9.0

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

[PATCH] drm/rockchip: add PINCTRL dependency for LVDS

[Arnd Bergmann]

The new driver fails to build when CONFIG_PINCTRL is disabled:

drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 
'rockchip_lvds_grf_config':
drivers/gpu/drm/rockchip/rockchip_lvds.c:229:39: error: dereferencing pointer 
to incomplete type 'struct dev_pin_info'
   if (lvds->pins && !IS_ERR(lvds->pins->default_state))

This adds the respective Kconfig dependency.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/rockchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a27b9c..3c70c6224bd2 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -60,6 +60,7 @@ config ROCKCHIP_INNO_HDMI
 config ROCKCHIP_LVDS
bool "Rockchip LVDS support"
depends on DRM_ROCKCHIP
+   depends on PINCTRL
help
  Choose this option to enable support for Rockchip LVDS controllers.
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
-- 
2.9.0

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

[PATCH] drm/omap: displays: panel-dpi: add backlight dependency

[Arnd Bergmann]

The new backlight code causes a link failure when backlight
support itself is disabled:

drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text+0x35c): undefined reference to `of_find_backlight_by_node'

This adds a Kconfig dependency like we have for the other OMAP
display targets.

Fixes: 39135a305a0f ("drm/omap: displays: panel-dpi: Support for handling 
backlight devices")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/displays/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig 
b/drivers/gpu/drm/omapdrm/displays/Kconfig
index c226da145fb3..a349cb61961e 100644
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -35,6 +35,7 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
 
 config DRM_OMAP_PANEL_DPI
tristate "Generic DPI panel"
+   depends on BACKLIGHT_CLASS_DEVICE
help
  Driver for generic DPI panels.
 
-- 
2.9.0

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

Re: [PATCH] drm/i915/selftests: fix check for intel IOMMU

[Chris Wilson]

Quoting Arnd Bergmann (2017-10-05 13:07:22)
> An earlier bugfix tried to work around this build failure:
> 
> drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 
> 'mock_gem_device':
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:151:20: error: 'struct 
> dev_archdata' has no member named 'iommu'
> 
> Checking for CONFIG_IOMMU_API is not sufficient as a compile-time
> test since that may be enabled in configurations that have neither
> INTEL_IOMMU not AMD_IOMMU enabled. This changes the check to
> INTEL_IOMMU instead, as this is the only case we actually care about.
> 
> Fixes: f46f156ea770 ("drm/i915/selftests: Only touch archdata.iommu when it 
> exists")
> Signed-off-by: Arnd Bergmann 

I'll take your wisdom. I was lost trying to nail down exactly what
config options we needed to check and settled for something that
appeared good enough (for the small selection of configs I tested).

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

[PATCH] drm/kirin: Checking for IS_ERR() instead of NULL

[Dan Carpenter]

The of_graph_get_remote_node() function doesn't return error pointers,
it returns NULL on error so I've updated the check.

Fixes: 86418f90a4c1 ("drm: convert drivers to use of_graph_get_remote_node")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index e27352ca26c4..527aa58485fa 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -236,8 +236,8 @@ static int kirin_drm_platform_probe(struct platform_device 
*pdev)
}
 
remote = of_graph_get_remote_node(np, 0, 0);
-   if (IS_ERR(remote))
-   return PTR_ERR(remote);
+   if (!remote)
+   return -ENODEV;
 
drm_of_component_match_add(dev, &match, compare_of, remote);
of_node_put(remote);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

[Benjamin Gaignard]

2017-10-04 12:17 GMT+02:00 Mark Brown :
> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
>
>> It is entirely possible and easy in android/ueventd to create those nodes
>> under "/dev/ion/".  (assuming the heap 'subsystem' for these new devices will
>> point to 'ion').

I think it is the same problem than for webcam under v4l framework.
Each time you plug a webcam you got a v4l node but android/uevent rules
the plug order doesn't have impact.
The same think will happen for ion nodes it may be even easier because
the heap will always being created in the smae order for a given product
configuration.

>
> The reason I didn't say /dev/ion/foo initially is that if people want to
> keep the existing /dev/ion around for compatibility reasons then the
> /dev/ion name isn't available which might cause issues.  Otherwise just
> dumping everything under a directory (perhaps with a different name) was
> my first thought as well.
>
>> (Also FWIW, the SELinux permissions are also possible with the current ion
>> implementation by adding rules to disallow specific ioctls instead of adding
>> permissions to access device node as this change would do)
>
> AIUI the request is to limit access to specific heaps, and obviously not
> everyone wants to deal with SELinux at all.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] drm/ttm: allocate/free multiple pages in a single call

[Christian König]

From: Christian König 

Totally surprisingly this is more efficient than doing it page by page.

Signed-off-by: Christian König 
Acked-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index e11fd76..482dd9a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -873,15 +873,14 @@ int ttm_pool_populate(struct ttm_tt *ttm)
if (ttm->state != tt_unpopulated)
return 0;
 
-   for (i = 0; i < ttm->num_pages; ++i) {
-   ret = ttm_get_pages(&ttm->pages[i], 1,
-   ttm->page_flags,
-   ttm->caching_state);
-   if (ret != 0) {
-   ttm_pool_unpopulate(ttm);
-   return -ENOMEM;
-   }
+   ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
+   ttm->caching_state);
+   if (unlikely(ret != 0)) {
+   ttm_pool_unpopulate(ttm);
+   return ret;
+   }
 
+   for (i = 0; i < ttm->num_pages; ++i) {
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
PAGE_SIZE);
if (unlikely(ret != 0)) {
@@ -908,14 +907,14 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
unsigned i;
 
for (i = 0; i < ttm->num_pages; ++i) {
-   if (ttm->pages[i]) {
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-ttm->pages[i], PAGE_SIZE);
-   ttm_put_pages(&ttm->pages[i], 1,
- ttm->page_flags,
- ttm->caching_state);
-   }
+   if (!ttm->pages[i])
+   continue;
+
+   ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
+PAGE_SIZE);
}
+   ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
+ ttm->caching_state);
ttm->state = tt_unpopulated;
 }
 EXPORT_SYMBOL(ttm_pool_unpopulate);
-- 
2.7.4

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

[PATCH 2/6] drm/ttm: DMA map/unmap consecutive pages as a whole v2

[Christian König]

From: Christian König 

Instead of mapping them bit by bit map/unmap all consecutive
pages as in one call.

v2: test for consecutive pages instead of using compound page order.

Signed-off-by: Christian König 
Acked-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 48 +---
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 482dd9a..6c852e8 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -922,16 +922,26 @@ EXPORT_SYMBOL(ttm_pool_unpopulate);
 #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
-   unsigned i;
+   unsigned i, j;
int r;
 
r = ttm_pool_populate(&tt->ttm);
if (r)
return r;
 
-   for (i = 0; i < tt->ttm.num_pages; i++) {
+   for (i = 0; i < tt->ttm.num_pages; ++i) {
+   struct page *p = tt->ttm.pages[i];
+   size_t num_pages = 1;
+
+   for (j = i + 1; j < tt->ttm.num_pages; ++j) {
+   if (++p != tt->ttm.pages[j])
+   break;
+
+   ++num_pages;
+   }
+
tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i],
- 0, PAGE_SIZE,
+ 0, num_pages * PAGE_SIZE,
  DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, tt->dma_address[i])) {
while (i--) {
@@ -942,6 +952,11 @@ int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
ttm_pool_unpopulate(&tt->ttm);
return -EFAULT;
}
+
+   for (j = 1; j < num_pages; ++j) {
+   tt->dma_address[i + 1] = tt->dma_address[i] + PAGE_SIZE;
+   ++i;
+   }
}
return 0;
 }
@@ -949,13 +964,28 @@ EXPORT_SYMBOL(ttm_populate_and_map_pages);
 
 void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
-   unsigned i;
-   
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   if (tt->dma_address[i]) {
-   dma_unmap_page(dev, tt->dma_address[i],
-  PAGE_SIZE, DMA_BIDIRECTIONAL);
+   unsigned i, j;
+
+   for (i = 0; i < tt->ttm.num_pages;) {
+   struct page *p = tt->ttm.pages[i];
+   size_t num_pages = 1;
+
+   if (!tt->dma_address[i] || !tt->ttm.pages[i]) {
+   ++i;
+   continue;
}
+
+   for (j = i + 1; j < tt->ttm.num_pages; ++j) {
+   if (++p != tt->ttm.pages[j])
+   break;
+
+   ++num_pages;
+   }
+
+   dma_unmap_page(dev, tt->dma_address[i], num_pages * PAGE_SIZE,
+  DMA_BIDIRECTIONAL);
+
+   i += num_pages;
}
ttm_pool_unpopulate(&tt->ttm);
 }
-- 
2.7.4

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

[PATCH 3/6] drm/ttm: add transparent huge page support for cached allocations

[Christian König]

From: Christian König 

Try to allocate huge pages when it makes sense.

Signed-off-by: Christian König 
Acked-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 49 ++--
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6c852e8..e8d42d4 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -685,12 +685,24 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
 
if (pool == NULL) {
/* No pool for this memory type so free the pages */
-   for (i = 0; i < npages; i++) {
-   if (pages[i]) {
-   if (page_count(pages[i]) != 1)
-   pr_err("Erroneous page count. Leaking 
pages.\n");
-   __free_page(pages[i]);
-   pages[i] = NULL;
+   i = 0;
+   while (i < npages) {
+   unsigned order;
+
+   if (!pages[i]) {
+   ++i;
+   continue;
+   }
+
+   if (page_count(pages[i]) != 1)
+   pr_err("Erroneous page count. Leaking 
pages.\n");
+   order = compound_order(pages[i]);
+   __free_pages(pages[i], order);
+
+   order = 1 << order;
+   while (order) {
+   pages[i++] = NULL;
+   --order;
}
}
return;
@@ -740,12 +752,32 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 
/* No pool for cached pages */
if (pool == NULL) {
+   unsigned i, j;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
gfp_flags |= GFP_HIGHUSER;
 
-   for (r = 0; r < npages; ++r) {
+   i = 0;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   while (npages >= HPAGE_PMD_NR) {
+   gfp_t huge_flags = gfp_flags;
+
+   huge_flags |= GFP_TRANSHUGE;
+   huge_flags &= ~__GFP_MOVABLE;
+   p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
+   if (!p)
+   break;
+
+   for (j = 0; j < HPAGE_PMD_NR; ++j)
+   pages[i++] = p++;
+
+   npages -= HPAGE_PMD_NR;
+   }
+#endif
+
+   while (npages) {
p = alloc_page(gfp_flags);
if (!p) {
 
@@ -753,7 +785,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
 
-   pages[r] = p;
+   pages[i++] = p;
+   --npages;
}
return 0;
}
-- 
2.7.4

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

[PATCH 4/6] drm/ttm: move more logic into ttm_page_pool_get_pages

[Christian König]

From: Christian König 

Make it easier to add huge page pool.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 98 +++-
 1 file changed, 52 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index e8d42d4..a800387 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -627,19 +627,20 @@ static void ttm_page_pool_fill_locked(struct 
ttm_page_pool *pool,
 }
 
 /**
- * Cut 'count' number of pages from the pool and put them on the return list.
+ * Allocate pages from the pool and put them on the return list.
  *
- * @return count of pages still required to fulfill the request.
+ * @return zero for success or negative error code.
  */
-static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
-   struct list_head *pages,
-   int ttm_flags,
-   enum ttm_caching_state cstate,
-   unsigned count)
+static int ttm_page_pool_get_pages(struct ttm_page_pool *pool,
+  struct list_head *pages,
+  int ttm_flags,
+  enum ttm_caching_state cstate,
+  unsigned count)
 {
unsigned long irq_flags;
struct list_head *p;
unsigned i;
+   int r = 0;
 
spin_lock_irqsave(&pool->lock, irq_flags);
ttm_page_pool_fill_locked(pool, ttm_flags, cstate, count, &irq_flags);
@@ -672,7 +673,35 @@ static unsigned ttm_page_pool_get_pages(struct 
ttm_page_pool *pool,
count = 0;
 out:
spin_unlock_irqrestore(&pool->lock, irq_flags);
-   return count;
+
+   /* clear the pages coming from the pool if requested */
+   if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC) {
+   struct page *page;
+
+   list_for_each_entry(page, pages, lru) {
+   if (PageHighMem(page))
+   clear_highpage(page);
+   else
+   clear_page(page_address(page));
+   }
+   }
+
+   /* If pool didn't have enough pages allocate new one. */
+   if (count) {
+   gfp_t gfp_flags = pool->gfp_flags;
+
+   /* set zero flag for page allocation if required */
+   if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
+   gfp_flags |= __GFP_ZERO;
+
+   /* ttm_alloc_new_pages doesn't reference pool so we can run
+* multiple requests in parallel.
+**/
+   r = ttm_alloc_new_pages(pages, gfp_flags, ttm_flags, cstate,
+   count);
+   }
+
+   return r;
 }
 
 /* Put all pages in pages list to correct pool to wait for reuse */
@@ -742,18 +771,18 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct list_head plist;
struct page *p = NULL;
-   gfp_t gfp_flags = GFP_USER;
unsigned count;
int r;
 
-   /* set zero flag for page allocation if required */
-   if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
-   gfp_flags |= __GFP_ZERO;
-
/* No pool for cached pages */
if (pool == NULL) {
+   gfp_t gfp_flags = GFP_USER;
unsigned i, j;
 
+   /* set zero flag for page allocation if required */
+   if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
+   gfp_flags |= __GFP_ZERO;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
@@ -791,44 +820,21 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return 0;
}
 
-   /* combine zero flag to pool flags */
-   gfp_flags |= pool->gfp_flags;
-
/* First we take pages from the pool */
INIT_LIST_HEAD(&plist);
-   npages = ttm_page_pool_get_pages(pool, &plist, flags, cstate, npages);
+   r = ttm_page_pool_get_pages(pool, &plist, flags, cstate, npages);
+
count = 0;
-   list_for_each_entry(p, &plist, lru) {
+   list_for_each_entry(p, &plist, lru)
pages[count++] = p;
-   }
-
-   /* clear the pages coming from the pool if requested */
-   if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) {
-   list_for_each_entry(p, &plist, lru) {
-   if (PageHighMem(p))
-   clear_highpage(p);
-   else
-   clear_page(page_address(p));
-   }
-   }
 
-   /* If pool didn't have enough pages allocate new one. */
-   if (npages > 0) {
-   /* ttm_alloc_new_pages doesn't referenc

[PATCH 5/6] drm/ttm: add transparent huge page support for wc or uc allocations

[Christian König]

From: Christian König 

Add a new huge page pool and try to allocate from it when it makes sense.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 134 ---
 1 file changed, 107 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index a800387..11a3a56 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -95,7 +95,7 @@ struct ttm_pool_opts {
unsignedsmall;
 };
 
-#define NUM_POOLS 4
+#define NUM_POOLS 6
 
 /**
  * struct ttm_pool_manager - Holds memory pools for fst allocation
@@ -122,6 +122,8 @@ struct ttm_pool_manager {
struct ttm_page_pooluc_pool;
struct ttm_page_poolwc_pool_dma32;
struct ttm_page_pooluc_pool_dma32;
+   struct ttm_page_poolwc_pool_huge;
+   struct ttm_page_pooluc_pool_huge;
} ;
};
 };
@@ -256,8 +258,8 @@ static int set_pages_array_uc(struct page **pages, int 
addrinarray)
 
 /**
  * Select the right pool or requested caching state and ttm flags. */
-static struct ttm_page_pool *ttm_get_pool(int flags,
-   enum ttm_caching_state cstate)
+static struct ttm_page_pool *ttm_get_pool(int flags, bool huge,
+ enum ttm_caching_state cstate)
 {
int pool_index;
 
@@ -269,9 +271,15 @@ static struct ttm_page_pool *ttm_get_pool(int flags,
else
pool_index = 0x1;
 
-   if (flags & TTM_PAGE_FLAG_DMA32)
+   if (flags & TTM_PAGE_FLAG_DMA32) {
+   if (huge)
+   return NULL;
pool_index |= 0x2;
 
+   } else if (huge) {
+   pool_index |= 0x4;
+   }
+
return &_manager->pools[pool_index];
 }
 
@@ -494,12 +502,14 @@ static void ttm_handle_caching_state_failure(struct 
list_head *pages,
  * pages returned in pages array.
  */
 static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
-   int ttm_flags, enum ttm_caching_state cstate, unsigned count)
+  int ttm_flags, enum ttm_caching_state cstate,
+  unsigned count, unsigned order)
 {
struct page **caching_array;
struct page *p;
int r = 0;
-   unsigned i, cpages;
+   unsigned i, j, cpages;
+   unsigned npages = 1 << order;
unsigned max_cpages = min(count,
(unsigned)(PAGE_SIZE/sizeof(struct page *)));
 
@@ -512,7 +522,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
}
 
for (i = 0, cpages = 0; i < count; ++i) {
-   p = alloc_page(gfp_flags);
+   p = alloc_pages(gfp_flags, order);
 
if (!p) {
pr_err("Unable to get page %u\n", i);
@@ -531,14 +541,18 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
goto out;
}
 
+   list_add(&p->lru, pages);
+
 #ifdef CONFIG_HIGHMEM
/* gfp flags of highmem page should never be dma32 so we
 * we should be fine in such case
 */
-   if (!PageHighMem(p))
+   if (PageHighMem(p))
+   continue;
+
 #endif
-   {
-   caching_array[cpages++] = p;
+   for (j = 0; j < npages; ++j) {
+   caching_array[cpages++] = p++;
if (cpages == max_cpages) {
 
r = ttm_set_pages_caching(caching_array,
@@ -552,8 +566,6 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
cpages = 0;
}
}
-
-   list_add(&p->lru, pages);
}
 
if (cpages) {
@@ -573,9 +585,9 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
  * Fill the given pool if there aren't enough pages and the requested number of
  * pages is small.
  */
-static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool,
-   int ttm_flags, enum ttm_caching_state cstate, unsigned count,
-   unsigned long *irq_flags)
+static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, int 
ttm_flags,
+ enum ttm_caching_state cstate,
+ unsigned count, unsigned long *irq_flags)
 {
struct page *p;
int r;
@@ -605,7 +617,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool 
*pool,
 
INIT_LIST_HEAD(&new_pages);
r = ttm_alloc_new_pages(&new_pages, pool->gfp_flags, ttm_flags,
-   cstate, alloc_size);
+   cstate, alloc_

[PATCH 6/6] drm/amdgpu: add VM support for huge pages v2

[Christian König]

From: Christian König 

Convert GTT mappings into linear ones for huge page handling.

v2: use fragment size as minimum for linear conversion

Signed-off-by: Christian König 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index bca9eeb..faedecc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1698,6 +1698,7 @@ static int amdgpu_vm_bo_split_mapping(struct 
amdgpu_device *adev,
  struct drm_mm_node *nodes,
  struct dma_fence **fence)
 {
+   unsigned min_linear_pages = 1 << adev->vm_manager.fragment_size;
uint64_t pfn, start = mapping->start;
int r;
 
@@ -1732,6 +1733,7 @@ static int amdgpu_vm_bo_split_mapping(struct 
amdgpu_device *adev,
}
 
do {
+   dma_addr_t *dma_addr = NULL;
uint64_t max_entries;
uint64_t addr, last;
 
@@ -1745,15 +1747,32 @@ static int amdgpu_vm_bo_split_mapping(struct 
amdgpu_device *adev,
}
 
if (pages_addr) {
+   uint64_t count;
+
max_entries = min(max_entries, 16ull * 1024ull);
-   addr = 0;
+   for (count = 1; count < max_entries; ++count) {
+   uint64_t idx = pfn + count;
+
+   if (pages_addr[idx] !=
+   (pages_addr[idx - 1] + PAGE_SIZE))
+   break;
+   }
+
+   if (count < min_linear_pages) {
+   addr = pfn << PAGE_SHIFT;
+   dma_addr = pages_addr;
+   } else {
+   addr = pages_addr[pfn];
+   max_entries = count;
+   }
+
} else if (flags & AMDGPU_PTE_VALID) {
addr += adev->vm_manager.vram_base_offset;
+   addr += pfn << PAGE_SHIFT;
}
-   addr += pfn << PAGE_SHIFT;
 
last = min((uint64_t)mapping->last, start + max_entries - 1);
-   r = amdgpu_vm_bo_update_mapping(adev, exclusive, pages_addr, vm,
+   r = amdgpu_vm_bo_update_mapping(adev, exclusive, dma_addr, vm,
start, last, flags, addr,
fence);
if (r)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix check for intel IOMMU

[Daniel Vetter]

On Thu, Oct 05, 2017 at 01:17:11PM +0100, Chris Wilson wrote:
> Quoting Arnd Bergmann (2017-10-05 13:07:22)
> > An earlier bugfix tried to work around this build failure:
> > 
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 
> > 'mock_gem_device':
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c:151:20: error: 'struct 
> > dev_archdata' has no member named 'iommu'
> > 
> > Checking for CONFIG_IOMMU_API is not sufficient as a compile-time
> > test since that may be enabled in configurations that have neither
> > INTEL_IOMMU not AMD_IOMMU enabled. This changes the check to
> > INTEL_IOMMU instead, as this is the only case we actually care about.
> > 
> > Fixes: f46f156ea770 ("drm/i915/selftests: Only touch archdata.iommu when it 
> > exists")
> > Signed-off-by: Arnd Bergmann 
> 
> I'll take your wisdom. I was lost trying to nail down exactly what
> config options we needed to check and settled for something that
> appeared good enough (for the small selection of configs I tested).
> 
> Reviewed-by: Chris Wilson 

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

[Bug 191571] AMD APU R4 hangs during hibernation - regression

[bugzilla-daemon]

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

Przemek (sop...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #9 from Przemek (sop...@gmail.com) ---
Fixed upstream by commit 820608548737e315c6f93e3099b4e65bde062334.

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

Re: [PATCH] drm/i915: avoid potential uninitialized variable use

[Daniel Vetter]

On Thu, Oct 05, 2017 at 02:08:26PM +0200, Arnd Bergmann wrote:
> One of the recent changes introduced a warning about
> undefined behavior in the sanity checking:
> 
> drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_hdmi_level':
> drivers/gpu/drm/i915/intel_ddi.c:654:6: error: 'n_hdmi_entries' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> It seems that the new cnl specific get_buf_trans functions
> can return uninitialized data if the voltage level is set
> to an unexpected value. This changes the code to always return
> '1' in that error case, which seems like the safest choice
> as we use one less than the number as an array index later on.
> 
> Fixes: cc9cabfdec38 ("drm/i915/cnl: Move voltage check into ddi buf trans 
> functions.")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 93cbbcbbc193..d0b786078bea 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -602,8 +602,10 @@ cnl_get_buf_trans_hdmi(struct drm_i915_private 
> *dev_priv, int *n_entries)
>   } else if (voltage == VOLTAGE_INFO_1_05V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
>   return cnl_ddi_translations_hdmi_1_05V;
> - } else
> + } else {
> + *n_entries = 1;
>   MISSING_CASE(voltage);
> + }

Somewhat meh on this, so added a /* shut up gcc */ comment and merged.

Thanks, Daniel

>   return NULL;
>  }
>  
> @@ -621,8 +623,10 @@ cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>   } else if (voltage == VOLTAGE_INFO_1_05V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_1_05V);
>   return cnl_ddi_translations_dp_1_05V;
> - } else
> + } else {
> + *n_entries = 1;
>   MISSING_CASE(voltage);
> + }
>   return NULL;
>  }
>  
> @@ -641,8 +645,10 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>   } else if (voltage == VOLTAGE_INFO_1_05V) {
>   *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_1_05V);
>   return cnl_ddi_translations_edp_1_05V;
> - } else
> + } else {
> + *n_entries = 1;
>   MISSING_CASE(voltage);
> + }
>   return NULL;
>   } else {
>   return cnl_get_buf_trans_dp(dev_priv, n_entries);
> -- 
> 2.9.0
> 

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

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

[Joonas Lahtinen]

On Wed, 2017-10-04 at 17:54 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Oscar Mateo 
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Thomas Gleixner 
> Signed-off-by: Kees Cook 



> @@ -32,9 +32,9 @@ static struct mock_request *first_request(struct 
> mock_engine *engine)
>   link);
>  }
>  
> -static void hw_delay_complete(unsigned long data)
> +static void hw_delay_complete(struct timer_list *t)
>  {
> - struct mock_engine *engine = (typeof(engine))data;
> + struct mock_engine *engine = from_timer(engine, t, hw_delay);

The order is bit strange to me, it's not same as with container_of, but
I guess GCC will complain for getting it wrong. It's also slightly
different doing the typeof for you, so I guess it makes sense, so:

Reviewed-by: Joonas Lahtinen 

Do you expect for us to merge or are you looking to merge all timer
changes from single tree?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 0/2] add Silicon Image SiI9234 driver

[Maciej Purski]

Hi everyone,

These patches are a continuation of work by Tomasz Stanislawski on sii9324 
driver, which was described
in th following letter:
https://lists.freedesktop.org/archives/dri-devel/2014-April/057481.html

The main differences from the previous code are:
* driver moved to /gpu/drm/bridge/ and integrated with drm/bridge subsystem
* added filtering-out unsupported display modes
* changed gpio interface to up-to-date
* changed interrupt handling
* improve code style
* add hdmi and sii9324 to exynos4412-trats2 device tree

All comments are welcome.

Regards,
Maciej Purski

Changes in v5:
- fix checkpatch warnings
- fix gpios property in i2c-mhl

Changes in v4:
- change documentation to more accurate
- use msleep() instead of usleep() and usleep_range()
- improve code style

Changes in v3:
- change sii9234 device tree node name
- use defines from dt-bindings/pinctrl/samsung.h

Changes in v2:
- regulators used in driver now model all physical regulators
  used by the device
- substitute some of the magic values with macros
- improve coding style
- improve error handling in sii9234_probe()
- fix commit message

Maciej Purski (2):
  drm/bridge: add Silicon Image SiI9234 driver
  ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

 .../devicetree/bindings/display/bridge/sii9234.txt |  49 +
 arch/arm/boot/dts/exynos4412-trats2.dts| 112 +++
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 996 +
 5 files changed, 1166 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

-- 
2.7.4

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

[PATCH v5 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Maciej Purski]

Add HDMI and Sil9234 MHL converter to Trats2 board.
Following in SoC devices have been enabled:
- HDMI (HDMI signal encoder),
- Mixer (video buffer scanout device),
- I2C_5 bus (used for HDMI DDC)
- I2C_8 bus (used for HDMI_PHY control).

Based on previous work by:
Tomasz Stanislawski 

Signed-off-by: Maciej Purski 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 111 
 1 file changed, 111 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 35e9b94..4483deb 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Samsung Trats 2 based on Exynos4412";
@@ -97,6 +98,34 @@
gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   vsil12: voltage-regulator-6 {
+   compatible = "regulator-fixed";
+   regulator-name = "VSIL_1.2V";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   vin-supply = <&buck7_reg>;
+   };
+
+   vcc33mhl: voltage-regulator-7 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3.3_MHL";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vcc18mhl: voltage-regulator-8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1.8_MHL";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
};
 
gpio-keys {
@@ -229,6 +258,36 @@
};
};
 
+   i2c-mhl {
+   compatible = "i2c-gpio";
+   gpios = <&gpf0 4 GPIO_ACTIVE_HIGH>, <&gpf0 6 GPIO_ACTIVE_HIGH>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <&i2c_mhl_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   sii9234: hdmi-bridge@39 {
+   compatible = "sil,sii9234";
+   avcc33-supply = <&vcc33mhl>;
+   iovcc18-supply = <&vcc18mhl>;
+   avcc12-supply = <&vsil12>;
+   cvcc12-supply = <&vsil12>;
+   reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpf3>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+   reg = <0x39>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   };
+   };
+
camera: camera {
pinctrl-0 = <&cam_port_a_clk_active &cam_port_b_clk_active>;
pinctrl-names = "default";
@@ -522,6 +581,29 @@
status = "okay";
 };
 
+&hdmi {
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_hpd>;
+   vdd-supply = <&ldo3_reg>;
+   vdd_osc-supply = <&ldo4_reg>;
+   vdd_pll-supply = <&ldo3_reg>;
+   ddc = <&i2c_5>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   hdmi_to_mhl: endpoint {
+   remote-endpoint = <&mhl_to_hdmi>;
+   };
+   };
+   };
+};
+
 &hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
@@ -600,6 +682,10 @@
};
 };
 
+&i2c_5 {
+   status = "okay";
+};
+
 &i2c_7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -894,12 +980,20 @@
};
 };
 
+&i2c_8 {
+   status = "okay";
+};
+
 &i2s0 {
pinctrl-0 = <&i2s0_bus>;
pinctrl-names = "default";
status = "okay";
 };
 
+&mixer {
+   status = "okay";
+};
+
 &mshc_0 {
num-slots = <1>;
broken-cd;
@@ -926,6 +1020,18 @@
pinctrl-names = "default";
pinctrl-0 = <&sleep0>;
 
+   mhl_int: mhl-int {
+   samsung,pins = "gpf3-5";
+   samsung,pin-pud = ;
+   };
+
+   i2c_mh

[PATCH v5 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Maciej Purski]

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
Acked-by: Rob Herring  [for dt bindings]
---
 .../devicetree/bindings/display/bridge/sii9234.txt |  49 +
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 994 +
 4 files changed, 1052 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..88041ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,49 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain two video interface port
+   nodes for HDMI encoder and connector according to 
[1].
+   - port@0 - MHL to HDMI
+   - port@1 - MHL to connector
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <&vcc33mhl>;
+   iovcc18-supply = <&vcc18mhl>;
+   avcc12-supply = <&vsil12>;
+   cvcc12-supply = <&vsil12>;
+   reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpf3>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   mhl_to_connector: endpoint {
+   remote-endpoint = <&connector_to_mhl>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
 
+config DRM_SII9234
+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..c770006
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,994 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This 

Re: [PATCH 00/12] of: overlay: clean up device tree overlay code

[Rob Herring]

On Thu, Oct 5, 2017 at 1:53 AM, Tomi Valkeinen  wrote:
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> On 04/10/17 17:56, Rob Herring wrote:
>> On Mon, Oct 2, 2017 at 10:53 PM,   wrote:
>>> From: Frank Rowand 
>>>
>>> I have found the device tree overlay code to be difficult to read and
>>> maintain.  This patch series attempts to improve that situation.
>>>
>>> The cleanup includes some changes visible to users of overlays.  The
>>> only in kernel user of overlays is fixed up for those changes.  The
>>> in kernel user is:
>>>
>>>drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>
>> At what point can we remove this? I'm assuming at some point users
>> will need to update their dtb's for other reasons and this becomes
>> obsolete.
>
> To be honest, I have no idea, or how to find that out.
>
> Do we need to get rid of it? Afaik, we haven't do much (or any?)
> maintenance on tilcdc_slave_compat.c since it was written, so from our
> perspective it's been a minimal burden. Is it creating burden for others?

Well, Frank had to deal with it. It's dealing with DT at a pretty low
level and impacts further clean-ups we want to do.

> Is the approach done with tilcdc_slave_compat.c something that's not
> recommended? I'm sure similar situations happen with other drivers too,
> and I think it's a good idea to have a recommended way of keeping
> compatibility.

If we do want this, I think we need some infrastructure to handle
these fixups and I don't really want to see dts files scattered around
the kernel. Most folks probably just break compatibility which I guess
for some platforms is fine. We do need to support maintaining
compatibility, but for how long depends on the platform.

This was added in 4.2. Looks like 2 boards used the old binding as of
4.1. Here's probably an incomplete list of changes since then:

$ git log v4.2.. --oneline -- arch/arm/boot/dts/am335x-base0033.dts
arch/arm/boot/dts/am335x-igep0033.dtsi
05e7d622f153 ARM: dts: omap: Add generic compatible string for I2C EEPROM
278cb79cc113 ARM: dts: am335x: Add missing unit name to memory nodes
c731abd99121 ARM: dts: am335x/437x/57xx: remove unneeded unit name for
gpio-leds nodes
4c049a5b7c89 ARM: dts: am335x/am437x: remove unneeded unit name for
fixed regulators
42647f947210 ARM: dts: am335x: Update elm phandle binding
63015d73f345 ARM: dts: am335x: Provide NAND ready pin
db0f68529a6a ARM: dts: am335x: Disable wait pin monitoring for NAND
037521483846 ARM: dts: am335x: Fix NAND device nodes
e9a267702d32 ARM: dts: am335x-base0033: Use IOPAD pinmux macro
8a3ecb217f11 ARM: dts: am335x-igep0033: Use IOPAD pinmux macro


And unfortunately, no one ever updated the am335x-base0033.dts to the
new binding. Though it doesn't have an nxp,tda998x node either, so
maybe it is not used? Otherwise, compatibility is probably still
needed since the clock has not even started on that board. Minimally,
this dts should be updated and the kernel should throw a WARN if the
dtb should be updated.


$ git log v4.1.. --oneline --no-merges
arch/arm/boot/dts/am335x-boneblack*
arch/arm/boot/dts/am335x-bone-common.dtsi
7e697ac3c4fb ARM: dts: tps65217: Add power button interrupt to the
common tps65217.dtsi file
6a80131e9dd2 ARM: dts: tps65217: Add charger interrupts to the common
tps65217.dtsi file
05e7d622f153 ARM: dts: omap: Add generic compatible string for I2C EEPROM
c2498af5c036 arm: dts: boneblack-wireless: add WL1835 Bluetooth device node
b9cb2ba71848 ARM: dts: Use - instead of @ for DT OPP entries for TI SoCs
bc4b1736f246 ARM: dts: am335x-boneblack: Enable 1GHz OPP for cpu
d680414d0f42 ARM: dts: Configure BeagleBone peripheral USB VBUS irq
fbb5850bd3c1 ARM: dts: Add am335x-boneblack-wireless
2876cc4a773c ARM: dts: Move most of am335x-boneblack.dts to
am335x-boneblack-common.dtsi
be53e38f0df2 dt-bindings: mfd: Remove TPS65217 interrupts
30aa2e48962c ARM: dts: am335x: Fix the interrupt name of TPS65217
a291b6b3d287 ARM: dts: am335x-boneblack: Add blue-and-red-wiring
-property to LCDC node
17fad5f3ab61 ARM: dts: AM335X-bone-common: Add the internal and
external clock nodes for rtc
eb3e4bbebac4 ARM: dts: am335x: Add the power button interrupt
1934e89a769b ARM: dts: am335x: Add the charger interrupt
2d63b9ce2136 ARM: dts: am335x: Support the PMIC interrupt
e3659351da09 Revert "ARM: dts: am335x-boneblack: Enable 1GHz OPP for cpu"
df0bd1e8f3c5 ARM: dts: am335x-boneblack: Add HDMI audio support
278cb79cc113 ARM: dts: am335x: Add missing unit name to memory nodes
c731abd99121 ARM: dts: am335x/437x/57xx: remove unneeded unit name for
gpio-leds nodes
4c049a5b7c89 ARM: dts: am335x/am437x: remove unneeded unit name for
fixed regulators
f03a881a8a8d ARM: dts: am335x-bone-common: use stdout-path in Beaglebone boards.
fd4eeada1bf1 ARM: dts: am335x-bone-common: Mark MAC as having only one PHY
c36e6ec90487 ARM: dts: am335x-boneblack: Enable 1GHz OPP for cpu
fb515b8e384d ARM: dts: am335x: Update MPU regul

[Bug 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

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

--- Comment #5 from Harry Wentland  ---
We want to avoid any regression since pre-Vega is already supported by non-DC.
Generally I have a lot more faith in DC but there could always be corner cases.
Vega is a new ASIC so by definition there won't be regressions (unless we mess
with non-display stuff).

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

[PATCH libdrm 2/2] fix uvd enc data corruption issue

[James Zhu]

In uvd encode parameter package, parameters input_pic_luma_pitch and
input_pic_chroma_pitch should be picture width align with hardware alignment.
The hardware alignment is 16 for amdgpu family earlier than AMDGPU_FAMILY_AI,
and 256 for later than and including AMDGPU_FAMILY_AI.

Signed-off-by: James Zhu 
---
 tests/amdgpu/uvd_enc_tests.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 7518103..bbda131 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -272,7 +272,7 @@ static void amdgpu_cs_uvd_enc_create(void)
 static void check_result(struct amdgpu_uvd_enc *enc)
 {
uint64_t sum;
-   uint32_t s = 26382;
+   uint32_t s = 175602;
uint32_t *ptr, size;
int i, j, r;
 
@@ -463,6 +463,8 @@ static void amdgpu_cs_uvd_enc_encode(void)
ib_cpu[len++] = chroma_offset >> 32;
ib_cpu[len++] = chroma_offset;
memcpy((ib_cpu + len), uve_encode_param, sizeof(uve_encode_param));
+   ib_cpu[len] = ALIGN(enc.width, align);
+   ib_cpu[len + 1] = ALIGN(enc.width, align);
len += sizeof(uve_encode_param) / 4;
 
memcpy((ib_cpu + len), uve_op_speed_enc_mode, 
sizeof(uve_op_speed_enc_mode));
-- 
2.7.4

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

[PATCH libdrm v2 2/2] tests/amdgpu: fix uvd enc data corruption issue

[James Zhu]

In uvd encode parameter package, parameters input_pic_luma_pitch and
input_pic_chroma_pitch should be picture width align with hardware alignment.
The hardware alignment is 16 for amdgpu family earlier than AMDGPU_FAMILY_AI,
and 256 for later than and including AMDGPU_FAMILY_AI.

Signed-off-by: James Zhu 
---
 tests/amdgpu/uvd_enc_tests.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 7518103..bbda131 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -272,7 +272,7 @@ static void amdgpu_cs_uvd_enc_create(void)
 static void check_result(struct amdgpu_uvd_enc *enc)
 {
uint64_t sum;
-   uint32_t s = 26382;
+   uint32_t s = 175602;
uint32_t *ptr, size;
int i, j, r;
 
@@ -463,6 +463,8 @@ static void amdgpu_cs_uvd_enc_encode(void)
ib_cpu[len++] = chroma_offset >> 32;
ib_cpu[len++] = chroma_offset;
memcpy((ib_cpu + len), uve_encode_param, sizeof(uve_encode_param));
+   ib_cpu[len] = ALIGN(enc.width, align);
+   ib_cpu[len + 1] = ALIGN(enc.width, align);
len += sizeof(uve_encode_param) / 4;
 
memcpy((ib_cpu + len), uve_op_speed_enc_mode, 
sizeof(uve_op_speed_enc_mode));
-- 
2.7.4

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

Re: [PATCH libdrm v2 2/2] tests/amdgpu: fix uvd enc data corruption issue

[James Zhu]

Hi Leo,

Sure, I will reset 0 in header file

Thanks!
James Zhu
On 2017-10-05 11:39 AM, Leo Liu wrote:



On 10/05/2017 11:24 AM, James Zhu wrote:

In uvd encode parameter package, parameters input_pic_luma_pitch and
input_pic_chroma_pitch should be picture width align with hardware 
alignment.
The hardware alignment is 16 for amdgpu family earlier than 
AMDGPU_FAMILY_AI,

and 256 for later than and including AMDGPU_FAMILY_AI.

Signed-off-by: James Zhu 
---
  tests/amdgpu/uvd_enc_tests.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 7518103..bbda131 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -272,7 +272,7 @@ static void amdgpu_cs_uvd_enc_create(void)
  static void check_result(struct amdgpu_uvd_enc *enc)
  {
  uint64_t sum;
-    uint32_t s = 26382;
+    uint32_t s = 175602;
  uint32_t *ptr, size;
  int i, j, r;
  @@ -463,6 +463,8 @@ static void amdgpu_cs_uvd_enc_encode(void)
  ib_cpu[len++] = chroma_offset >> 32;
  ib_cpu[len++] = chroma_offset;
  memcpy((ib_cpu + len), uve_encode_param, 
sizeof(uve_encode_param));

+    ib_cpu[len] = ALIGN(enc.width, align);
+    ib_cpu[len + 1] = ALIGN(enc.width, align);

Since here we override the pitch value based on below from uve_ib.h.

static const uint32_t uve_encode_param[] = {
    0x00a0,
    0x0080,

We'd better to reset them to 0 from the header file, since we don't 
want to leave the incorrect value there.


With that fixed, the series is

Reviewed-by: Leo Liu 


  len += sizeof(uve_encode_param) / 4;
    memcpy((ib_cpu + len), uve_op_speed_enc_mode, 
sizeof(uve_op_speed_enc_mode));




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

[Bug 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

Bug ID: 103111
   Summary: Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: stevenfa...@gmail.com

Created attachment 134681
  --> https://bugs.freedesktop.org/attachment.cgi?id=134681&action=edit
dmesg file showing a successful boot

-- 
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 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

--- Comment #1 from Steve Falco  ---
Created attachment 134682
  --> https://bugs.freedesktop.org/attachment.cgi?id=134682&action=edit
good xorg log

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

[Bug 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

--- Comment #3 from Steve Falco  ---
Created attachment 134684
  --> https://bugs.freedesktop.org/attachment.cgi?id=134684&action=edit
bad dmesg log

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

[Bug 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

--- Comment #4 from Steve Falco  ---
Created attachment 134685
  --> https://bugs.freedesktop.org/attachment.cgi?id=134685&action=edit
second bad xorg log

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

[Bug 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

--- Comment #2 from Steve Falco  ---
Created attachment 134683
  --> https://bugs.freedesktop.org/attachment.cgi?id=134683&action=edit
bad xorg log

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

[PATCH libdrm v2 1/2] tests/amdgpu: add new uvd enc support check

[James Zhu]

Query hardware IP information to find out if there are uvd encode rings
ready for use in kernel driver.

Signed-off-by: James Zhu 
---
 tests/amdgpu/uvd_enc_tests.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 6c19f7b..7518103 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -79,6 +79,8 @@ static void amdgpu_cs_uvd_enc_session_init(void);
 static void amdgpu_cs_uvd_enc_encode(void);
 static void amdgpu_cs_uvd_enc_destroy(void);
 
+static bool uvd_enc_support(void);
+
 CU_TestInfo uvd_enc_tests[] = {
{ "UVD ENC create",  amdgpu_cs_uvd_enc_create },
{ "UVD ENC session init",  amdgpu_cs_uvd_enc_session_init },
@@ -98,7 +100,7 @@ int suite_uvd_enc_tests_init(void)
 
family_id = device_handle->info.family_id;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV) {
+   if (!uvd_enc_support()) {
printf("\n\nThe ASIC NOT support UVD ENC, all sub-tests will 
pass\n");
return CUE_SUCCESS;
}
@@ -121,7 +123,7 @@ int suite_uvd_enc_tests_clean(void)
 {
int r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV) {
+   if (!uvd_enc_support()) {
 
r = amdgpu_device_deinitialize(device_handle);
if (r)
@@ -238,11 +240,24 @@ static void free_resource(struct amdgpu_uvd_enc_bo 
*uvd_enc_bo)
memset(uvd_enc_bo, 0, sizeof(*uvd_enc_bo));
 }
 
+static bool uvd_enc_support(void)
+{
+   int r;
+   struct drm_amdgpu_info_hw_ip info;
+
+   r = amdgpu_query_hw_ip_info(device_handle, AMDGPU_HW_IP_UVD_ENC, 0, 
&info);
+
+   if (r)
+   return false;
+   else
+   return (info.available_rings?true:false);
+}
+
 static void amdgpu_cs_uvd_enc_create(void)
 {
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
enc.width = 160;
@@ -281,7 +296,7 @@ static void amdgpu_cs_uvd_enc_session_init(void)
 {
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
len = 0;
@@ -339,7 +354,7 @@ static void amdgpu_cs_uvd_enc_encode(void)
vbuf_size = ALIGN(enc.width, align) * ALIGN(enc.height, 16) * 1.5;
cpb_size = vbuf_size * 10;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
num_resources  = 0;
@@ -472,7 +487,7 @@ static void amdgpu_cs_uvd_enc_destroy(void)
struct amdgpu_uvd_enc_bo sw_ctx;
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
num_resources  = 0;
-- 
2.7.4

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

[Bug 103111] Tonga PRO [Radeon R9 285/380] [1002:6939] blank screen

[bugzilla-daemon]

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

--- Comment #5 from Steve Falco  ---
I have a Radeon R9 285/380 video card in a machine that is running Fedora 26. 
When I run with Fedora kernel version 4.11.11 the video card works properly,
using the amdgpu kernel driver.

However, once I upgrade to a newer kernel in the 4.12 or 4.13 series, my
display goes blank during boot and stays that way for a long time.  The monitor
appears to be getting sync, because it doesn't go to sleep, however there is
nothing visible on the screen.

Eventually, error messages are displayed and the system never boots fully.

I've attached logs showing both a good and a bad startup.  For some reason, in
the "bad case", I got two xorg log files, so I've attached both.

Please let me know if there is more information that I can collect to help in
debug.

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

[PATCH libdrm 1/2] add new uvd enc support check

[James Zhu]

Query hardware IP information to find out if there are uvd encode rings
ready for use in kernel driver.

Signed-off-by: James Zhu 
---
 tests/amdgpu/uvd_enc_tests.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 6c19f7b..7518103 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -79,6 +79,8 @@ static void amdgpu_cs_uvd_enc_session_init(void);
 static void amdgpu_cs_uvd_enc_encode(void);
 static void amdgpu_cs_uvd_enc_destroy(void);
 
+static bool uvd_enc_support(void);
+
 CU_TestInfo uvd_enc_tests[] = {
{ "UVD ENC create",  amdgpu_cs_uvd_enc_create },
{ "UVD ENC session init",  amdgpu_cs_uvd_enc_session_init },
@@ -98,7 +100,7 @@ int suite_uvd_enc_tests_init(void)
 
family_id = device_handle->info.family_id;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV) {
+   if (!uvd_enc_support()) {
printf("\n\nThe ASIC NOT support UVD ENC, all sub-tests will 
pass\n");
return CUE_SUCCESS;
}
@@ -121,7 +123,7 @@ int suite_uvd_enc_tests_clean(void)
 {
int r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV) {
+   if (!uvd_enc_support()) {
 
r = amdgpu_device_deinitialize(device_handle);
if (r)
@@ -238,11 +240,24 @@ static void free_resource(struct amdgpu_uvd_enc_bo 
*uvd_enc_bo)
memset(uvd_enc_bo, 0, sizeof(*uvd_enc_bo));
 }
 
+static bool uvd_enc_support(void)
+{
+   int r;
+   struct drm_amdgpu_info_hw_ip info;
+
+   r = amdgpu_query_hw_ip_info(device_handle, AMDGPU_HW_IP_UVD_ENC, 0, 
&info);
+
+   if (r)
+   return false;
+   else
+   return (info.available_rings?true:false);
+}
+
 static void amdgpu_cs_uvd_enc_create(void)
 {
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
enc.width = 160;
@@ -281,7 +296,7 @@ static void amdgpu_cs_uvd_enc_session_init(void)
 {
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
len = 0;
@@ -339,7 +354,7 @@ static void amdgpu_cs_uvd_enc_encode(void)
vbuf_size = ALIGN(enc.width, align) * ALIGN(enc.height, 16) * 1.5;
cpb_size = vbuf_size * 10;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
num_resources  = 0;
@@ -472,7 +487,7 @@ static void amdgpu_cs_uvd_enc_destroy(void)
struct amdgpu_uvd_enc_bo sw_ctx;
int len, r;
 
-   if (family_id < AMDGPU_FAMILY_AI || family_id >= AMDGPU_FAMILY_RV)
+   if (!uvd_enc_support())
return;
 
num_resources  = 0;
-- 
2.7.4

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

Re: [PATCH v2] drm/gem-cma-helper: Change the level of the allocation failure message

[Eric Anholt]

Boris Brezillon  writes:

> drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
> allocate the amount of memory we requested. This can lead to annoying
> error messages when CMA is only one possible source of memory for the BO
> allocation. Turn this error message into a debug one.
>
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Eric Engestrom 

Reviewed-by: Eric Anholt 


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

Re: [PATCH libdrm v2 2/2] tests/amdgpu: fix uvd enc data corruption issue

[Leo Liu]

On 10/05/2017 11:24 AM, James Zhu wrote:

In uvd encode parameter package, parameters input_pic_luma_pitch and
input_pic_chroma_pitch should be picture width align with hardware alignment.
The hardware alignment is 16 for amdgpu family earlier than AMDGPU_FAMILY_AI,
and 256 for later than and including AMDGPU_FAMILY_AI.

Signed-off-by: James Zhu 
---
  tests/amdgpu/uvd_enc_tests.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index 7518103..bbda131 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -272,7 +272,7 @@ static void amdgpu_cs_uvd_enc_create(void)
  static void check_result(struct amdgpu_uvd_enc *enc)
  {
uint64_t sum;
-   uint32_t s = 26382;
+   uint32_t s = 175602;
uint32_t *ptr, size;
int i, j, r;
  
@@ -463,6 +463,8 @@ static void amdgpu_cs_uvd_enc_encode(void)

ib_cpu[len++] = chroma_offset >> 32;
ib_cpu[len++] = chroma_offset;
memcpy((ib_cpu + len), uve_encode_param, sizeof(uve_encode_param));
+   ib_cpu[len] = ALIGN(enc.width, align);
+   ib_cpu[len + 1] = ALIGN(enc.width, align);

Since here we override the pitch value based on below from uve_ib.h.

static const uint32_t uve_encode_param[] = {
0x00a0,
0x0080,

We'd better to reset them to 0 from the header file, since we don't want 
to leave the incorrect value there.


With that fixed, the series is

Reviewed-by: Leo Liu 


len += sizeof(uve_encode_param) / 4;
  
  	memcpy((ib_cpu + len), uve_op_speed_enc_mode, sizeof(uve_op_speed_enc_mode));


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

[Bug 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #1 from Hadrien  ---
Extract of /var/log/kern.log when I did the suspend/resume:

Oct 3 21:03:28 c18 kernel: [ 62.519787] [drm:amdgpu_vce_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 14 test failed
Oct 3 21:03:28 c18 kernel: [ 62.519795] [drm:amdgpu_resume_phase2 [amdgpu]]
*ERROR* resume of IP block  failed -110
Oct 3 21:03:28 c18 kernel: [ 62.519803] [drm:amdgpu_device_resume [amdgpu]]
*ERROR* amdgpu_resume failed (-110).
Oct 3 21:03:28 c18 kernel: [ 62.519806] dpm_run_callback():
pci_pm_resume+0x0/0xb0 returns -110
Oct 3 21:03:28 c18 kernel: [ 62.519806] PM: Device :01:00.0 failed to
resume async: error -110

...

Oct 3 21:04:21 c18 kernel: [ 115.155901] [drm:atom_op_jump [amdgpu]] *ERROR*
atombios stuck in loop for more than 5secs aborting
Oct 3 21:04:21 c18 kernel: [ 115.155912] [drm:amdgpu_atom_execute_table_locked
[amdgpu]] *ERROR* atombios stuck executing BFFC (len 116, WS 0, PS 0) @ 0xC049
Oct 3 21:04:21 c18 kernel: [ 115.155955] amdgpu :01:00.0: 9ffe950e2800
unpin not necessary

-- 
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 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #3 from Hadrien  ---
Created attachment 134688
  --> https://bugs.freedesktop.org/attachment.cgi?id=134688&action=edit
kern.log of boot/suspend/resume with Linux kernel 4.12.5

-- 
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 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #4 from Hadrien  ---
Created attachment 134689
  --> https://bugs.freedesktop.org/attachment.cgi?id=134689&action=edit
kern.log of boot/suspend/resume with Linux kernel 4.12.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 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #2 from Hadrien  ---
I tried several kernels:

4.12.4: OK
4.12.5: OK
4.12.6: FAIL, but after 20 seconds the monitor displays something: pure garbage
4.12.7: FAIL, the monitor stays OFF

I'll attach the kernel logs.

Interesting part in 4.12.6:

Oct  5 20:56:21 c18 kernel: [   37.277968] [drm:amdgpu_vce_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 13 test failed
Oct  5 20:56:21 c18 kernel: [   37.277976] [drm:amdgpu_resume [amdgpu]] *ERROR*
resume of IP block  failed -110
Oct  5 20:56:21 c18 kernel: [   37.277983] [drm:amdgpu_device_resume [amdgpu]]
*ERROR* amdgpu_resume failed (-110).
Oct  5 20:56:21 c18 kernel: [   37.277985] dpm_run_callback():
pci_pm_resume+0x0/0xa0 returns -110
Oct  5 20:56:21 c18 kernel: [   37.277986] PM: Device :01:00.0 failed to
resume async: error -110

There is a slight difference with more recent kernels, where the message
mentions ring 14 instead of ring 13 and some other functions too.

-- 
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 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

[bugzilla-daemon]

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

--- Comment #5 from Hadrien  ---
The problem looks a bit like this one:
https://bugzilla.kernel.org/show_bug.cgi?id=196615

-- 
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 6/6] drm/amdgpu: add VM support for huge pages v2

[Deucher, Alexander]

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Thursday, October 05, 2017 9:08 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH 6/6] drm/amdgpu: add VM support for huge pages v2
> 
> From: Christian König 
> 
> Convert GTT mappings into linear ones for huge page handling.
> 
> v2: use fragment size as minimum for linear conversion
> 
> Signed-off-by: Christian König 
> Reviewed-by: Felix Kuehling 

Series is:
Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 25
> ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index bca9eeb..faedecc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1698,6 +1698,7 @@ static int amdgpu_vm_bo_split_mapping(struct
> amdgpu_device *adev,
> struct drm_mm_node *nodes,
> struct dma_fence **fence)
>  {
> + unsigned min_linear_pages = 1 << adev-
> >vm_manager.fragment_size;
>   uint64_t pfn, start = mapping->start;
>   int r;
> 
> @@ -1732,6 +1733,7 @@ static int amdgpu_vm_bo_split_mapping(struct
> amdgpu_device *adev,
>   }
> 
>   do {
> + dma_addr_t *dma_addr = NULL;
>   uint64_t max_entries;
>   uint64_t addr, last;
> 
> @@ -1745,15 +1747,32 @@ static int amdgpu_vm_bo_split_mapping(struct
> amdgpu_device *adev,
>   }
> 
>   if (pages_addr) {
> + uint64_t count;
> +
>   max_entries = min(max_entries, 16ull * 1024ull);
> - addr = 0;
> + for (count = 1; count < max_entries; ++count) {
> + uint64_t idx = pfn + count;
> +
> + if (pages_addr[idx] !=
> + (pages_addr[idx - 1] + PAGE_SIZE))
> + break;
> + }
> +
> + if (count < min_linear_pages) {
> + addr = pfn << PAGE_SHIFT;
> + dma_addr = pages_addr;
> + } else {
> + addr = pages_addr[pfn];
> + max_entries = count;
> + }
> +
>   } else if (flags & AMDGPU_PTE_VALID) {
>   addr += adev->vm_manager.vram_base_offset;
> + addr += pfn << PAGE_SHIFT;
>   }
> - addr += pfn << PAGE_SHIFT;
> 
>   last = min((uint64_t)mapping->last, start + max_entries - 1);
> - r = amdgpu_vm_bo_update_mapping(adev, exclusive,
> pages_addr, vm,
> + r = amdgpu_vm_bo_update_mapping(adev, exclusive,
> dma_addr, vm,
>   start, last, flags, addr,
>   fence);
>   if (r)
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
> These bindings allows to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.

Yay!

> Signed-off-by: Andrzej Hajda 
> ---
> There are few things for discussion (IMO):
> 1. vendor specific connectors, I have added them here, but maybe better is
>to place them in separate files.

I'd worry about the standard connectors first, but probably good to have 
an idea of how vendor connectors need to be extended.

> 2. physical connector description - I have split it to three properties:
>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>This tripled is able to describe all USB-standard connectors, but there
>are also impossible combinations, for example(c, *, micro). Maybe better
>would be to just enumerate all possible connectors in include file.

We did "type" for hdmi-connector, but I think I'd really prefer 
compatible be used to distinguish as least where it may matter to s/w. 
In the HDMI case, they all are pretty much the same, just different 
physical size.

> 3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
>Controller. Maybe other functions should be also assigned:
>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>as an additional property of remote node?

child of the controller is also an option. There's already prec

> ...
> 
> Regards
> Andrzej
> ---
>  .../bindings/connector/usb-connector.txt   | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..f3a4e85122d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,49 @@
> +USB Connector
> +=
> +
> +Required properties:
> +- compatible: "usb-connector"
> +  connectors with vendor specific extensions can add one of additional
> +  compatibles:
> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
> +- type: the USB connector type: "a", "b", "ab", "c"
> +- max-mode: max USB speed mode supported by the connector:
> +  "ls", "fs", "hs", "ss", "ss+"

Do we really see cases where the connector is slower than the 
controller? Plus things like "ls" with an type A connector are not 
valid.

> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- size: size of the connector, should be specified in case of
> +  non-standard USB connectors: "mini", "micro", "powered"

What does powered mean?

This is really "type" if you compare to HDMI.

> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the
> +  OF graph bindings specified in bindings/graph.txt.
> +  There should be exactly one port with at least one endpoint to
> +  different device nodes. The first endpoint (reg = <0>) should
> +  point to USB Interface Controller.
> +
> +Example
> +---
> +
> +musb_con: connector {
> + compatible = "samsung,usb-connector-11pin", "usb-connector";
> + label = "usb";

> + type = "b";
> + size = "micro";
> + max-mode = "hs";

These all are implied by "samsung,usb-connector-11pin".

> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + musb_con_usb_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&muic_usb_out>;
> + };
> +
> + musb_con_mhl_in: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&mhl_out>;
> + };

I think this should be 2 ports, not 2 endpoints. Think of ports as 
different data streams and endpoints are either the same data stream 
muxed or fanned out depending on direction. Now for Type-C, 1 port for 
USB and alternate modes is probably correct.

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

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

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

Eddie Ringle  changed:

   What|Removed |Added

 CC||ed...@ringle.io

--- Comment #6 from Eddie Ringle  ---
Wanted to add that I'm seeing this issue now under a similar setup. I've seen
it in the past, but the last few kernel releases have been pretty smooth. Once
I upgraded to GNOME 3.26, however, both 4.13 and now 4.14-rc3 are displaying
this issue.

I'm on Arch (using Wayland primarily), with a Fury X and three Dell P2415Q
monitors, also connected via DisplayPort. I have MST disabled on all three,
since (even Dell has documented) this model has issues hitting 4K@60Hz with it
enabled.

Same "displayport link status failed" and "clock recovery failed" messages
appear for me, also three times in a row. This more often than not leads to
gnome-shell crashing. I see it most often after I've put my computer to sleep
when I try to wake it up. Other times when putting it to sleep, one monitor
will stay powered and show a backlit blank screen.

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

[git pull] drm fixes for 4.14-rc4

[Dave Airlie]

Hi Linus,

Some i915 fixes from last two weeks (as they were on a strange base
and I just waited for rc3), also a single sun4i hdmi fix.

Dave.

The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:

  Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.14-rc4

for you to fetch changes up to baf7c1f7e8f28c83f64a8c229a9357da47c0367a:

  Merge tag 'drm-misc-fixes-2017-10-05' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-10-06
11:09:47 +1000)


i915 and sun4i fixes


Chen-Yu Tsai (1):
  drm/sun4i: hdmi: Disable clks in bind function error path and
unbind function

Colin Ian King (1):
  drm/i915: remove redundant variable hw_check

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2017-09-27' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2017-10-04' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2017-10-05' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Imre Deak (3):
  drm/i915: Fix DDI PHY init if it was already on
  drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume
  drm/i915/glk: Fix DMC/DC state idleness calculation

Jani Nikula (2):
  drm/i915: always update ELD connector type after get modes
  drm/i915/bios: ignore HDMI on port A

 drivers/gpu/drm/i915/intel_audio.c  |  5 -
 drivers/gpu/drm/i915/intel_bios.c   |  7 +++
 drivers/gpu/drm/i915/intel_csr.c|  2 +-
 drivers/gpu/drm/i915/intel_ddi.c|  3 ++-
 drivers/gpu/drm/i915/intel_display.c|  2 --
 drivers/gpu/drm/i915/intel_dpio_phy.c   | 20 
 drivers/gpu/drm/i915/intel_modes.c  | 17 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +++
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c  | 19 ++-
 9 files changed, 44 insertions(+), 34 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

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

--- Comment #6 from Daniel Drake  ---
Harry, HDMI audio is not working for us on the non-DC driver on this hardware
(AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G). Are you saying non-DC should
be working fine there?

-- 
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 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

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

--- Comment #7 from Dave Airlie  ---
Daniel,

not working HDMI audio is a missing feature, not a regression. Not enabling dc
by default on older GPUs is to avoid regressions in working features. After
some testing it will get enabled.

-- 
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 103080] DC driver from drm-next-4.15-dc branch (upstream PR) not working

[bugzilla-daemon]

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

--- Comment #8 from Daniel Drake  ---
Got it. We have a number of affected systems here, so we will help with testing
efforts, reporting bugs and successes.

-- 
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 v6 3/3] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

[Archit Taneja]

On 09/28/2017 01:06 AM, Eric Anholt wrote:

This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.

v2: Set the same default orientation as the closed source firmware
 used, which is the best for viewing angle.
v3: Rewrite as an i2c client driver after bridge driver rejection.
v4: Finish probe without the DSI host, using the new delayed
 registration, and attach to the host during mipi_dsi_driver probe.
v5: Rework to drop the "probe without DSI host" mode again, now that
 vc4 will create the host early on.


Reviewed-by: Archit Taneja 



Signed-off-by: Eric Anholt 
---
  drivers/gpu/drm/panel/Kconfig  |   8 +
  drivers/gpu/drm/panel/Makefile |   1 +
  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 517 +
  3 files changed, 526 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 718d8ce15b1f..726f3fb3312d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -82,6 +82,14 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
  
+config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN

+   tristate "Raspberry Pi 7-inch touchscreen panel"
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for the Raspberry
+ Pi 7" Touchscreen.  To compile this driver as a module,
+ choose M here.
+
  config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index c8483fdd5b9b..77ede3467324 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
  obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
+obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
new file mode 100644
index ..4237a0cbcdcc
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -0,0 +1,517 @@
+/*
+ * Copyright © 2016-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Portions of this file (derived from panel-simple.c) are:
+ *
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * Raspberry Pi 7" touchscreen panel driver.
+ *
+ * The 7" touchscreen consists of a DPI LCD panel, a Toshiba
+ * TC358762XBG DSI-DPI bridge, and an I2C-connected Atmel ATTINY88-MUR
+ * controlling power management, the LCD PWM, and initial register
+ * setup of the Tohsiba.
+ *
+ * This driver controls the TC358762 and ATTINY88, presenting a DSI
+ * device with a drm_panel.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPI_DSI_DRIVER_NAME "rpi-ts-dsi"
+
+/* I2C registers of the Atmel microcontroll

Re: [PATCHv2 2/2] drm: adv7511/33: add HDMI CEC support

[Archit Taneja]

Hi Hans,

On 09/19/2017 01:03 PM, Hans Verkuil wrote:

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.


The patch looks good to me. I can go ahead an queue it to drm-misc-next.

There were some minor comments on the DT bindings patch. Are you planning
to send a new patch for that?

Thanks,
Archit



Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h |  43 +++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 +++--
  drivers/gpu/drm/bridge/adv7511/adv7533.c |  38 +--
  6 files changed, 485 insertions(+), 58 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
  adv7511-y := adv7511_drv.o
  adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..543a5eb91624 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
  #define ADV7511_PACKET_GM(x)  ADV7511_PACKET(5, x)
  #define ADV7511_PACKET_SPARE(x)   ADV7511_PACKET(6, x)
  
+#define ADV7511_REG_CEC_TX_FRAME_HDR	0x00

+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
  enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
  };
  
+#define ADV7511_MAX_ADDRS 3

+
  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,27 @@ struct adv7511 {
  
  	enum adv7511_type type;

struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
  };
  
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC

+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
+unsigned int offset);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
  #ifdef CONFIG_DRM_I2C_ADV7533
  void adv7533_dsi_power_on(struct adv7511 *adv);
  void adv7533_dsi_power_off(struct adv7511 *adv);
  void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
  int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
  int adv7533_attach_dsi(struct adv7511 *adv);
  void adv7533_detach_dsi(struct adv7511 *adv);
  int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +407,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
  }
  
-static inline void adv7533_uninit_cec(struct adv7511 *adv)

-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
  {
return -ENODEV;
  }
diff --git a/drivers