[bug report] drm/amd/display: Call into DC once per multiplane flip

[Dan Carpenter]

Hello David Francis,

This is a semi-automatic email about new static checker warnings.

The patch 8a48b44cd00f: "drm/amd/display: Call into DC once per 
multiplane flip" from Dec 11, 2018, leads to the following Smatch 
complaint:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4845 
amdgpu_dm_commit_planes()
error: we previously assumed 'acrtc_state->stream' could be null (see line 
4833)

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
  4832  
  4833  if (acrtc_state->stream) {
^^^
Check for NULL

  4834  
  4835  if (acrtc_state->freesync_timing_changed)
  4836  flip->stream_update.adjust =
  4837  &acrtc_state->stream->adjust;
  4838  
  4839  if (acrtc_state->freesync_vrr_info_changed)
  4840  flip->stream_update.vrr_infopacket =
  4841  
&acrtc_state->stream->vrr_infopacket;
  4842  }
  4843  
  4844  mutex_lock(&dm->dc_lock);
  4845  dc_commit_updates_for_stream(dm->dc,
  4846   
flip->surface_updates,
  4847   flip_count,
  4848   
acrtc_state->stream,
 ^^^
Unchecked dereference.  Also the indenting is weird.

  4849   
&flip->stream_update,
  4850   dc_state);
  4851  mutex_unlock(&dm->dc_lock);
  4852  }
  4853  
  4854  if (planes_count) {


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

Re: Cursors uAPI vs async update - questions

[Daniel Vetter]

On Mon, Feb 18, 2019 at 01:47:57PM -0300, Helen Koike wrote:
> Hello,
> 
> After some discussions I had with some people I would like to discuss
> some design choices regarding uAPI to expose async updates.
> 
> The plan is to allow userspace to update the cursor plane through the
> atomic API instead of the legacy cursor API.
> 
> The steps I was following were:
> 1) Make the legacy cursor implementation use async updates
> path/helpers; and this should work as before
> 2) Expose a way for userspace to trigger an async updates for any
> plane (adding proper tests to igt)
> 
> Assuming that async here means: update the hw immediately.
> 
> But for this to happen, the idea of legacy cursor API and async update
> should be similar, and my question is: are they?
> 
> The question that was raised was:
> 
> When we perform 100 legacy cursor updates to the kernel between 2
> v-blanks, how many times does the screen update cursor?
> (a) 1 - at vblank
> (b) 100
> (c) depends on the hw and driver
> 
> I would say (b), is that correct?

b)

We even have an igt testcase (kms_cursor_legacy) to make sure that's the
case. Might need some tweaking, but should run on any kms driver.

> If it's (b), then async updates should allow the same.
> (NOTE: Actually not really with the current implementation, if there is
> a sync pending commit, then async update blocks,
> which makes the name confusing).
> 
> Also, if async is not possible, in the current implementation we fall
> back to a sync update. But this is not that interesting for userspace,
> for example,
> if drmModeSetCursor succeeds, xorg will call that every single time it
> gets an input event, but if it fails, there are no expectations
> that cursor moves are async and xorg handles cursor updates it self
> (using the primary plane for instance). So another question here
> is: should we have another flag to say that async update should fail
> instead of falling back to a sync update ?

Maybe? I have no idea what userspace wants to do with this. Definitely
need to understand why userspace wants/needs async exposed through atomic,
that should help with answering. I think a flag like ALLOW_MODESET for
async (e.g. FORCE_ASYNC or fail if not possible) could be useful. But we
don't add new uapi without justification in form of real userspace.

> Another point is, if we perform an async update while there is still a
> pending commit, It seems to me that instead of falling back to a
> sync update, it would be better for the userspace if we could amend the
> pending commit, what do you think?

From a software pov the current async logic essentialy does exactly that -
it amends the currently pending commit. We can extend that, but it gets
really tricky, really fast. Again, we need to know the exact user of this,
lots of things are possible.

> And I just want to clarify (just because this wans't clear to me before
> and might not be clear to others) that async update (programming
> the hw immediately) can cause tearing if the hw reads the configuration
> dynamically during a scanout.

Yup. There's also hw where async cursor just keeps updating, and only the
last update before vblank will be the one that's shown, so no tearing. But
we need to allow both I think. If userspace isn't happy with that (because
it e.g. wants to use async for video updates or something like that), then
we might need another flag.
-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 108262] Unable to open intel_gpu_top (sudo): Test assertion failure function init_instdone_definitions, file instdone.c:599

[bugzilla-daemon]

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

Lakshmi  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Lakshmi  ---
Reporter please use the latest intel gpu tools
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools.

-- 
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 108073] [CI][SHARDS] igt@gem_cpu_reloc@full - incomplete

[bugzilla-daemon]

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

Lakshmi  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Lakshmi  ---
Last seen CI_DRM_5296_full (2 months, 1 week / 1138 runs ago).
This bug has been archived. Closing this bug.

-- 
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 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[David Santamaría Rogado]

I have my mail and real name in git configuration but it has taken my
computer's username. I suppose there should be a way to make git to take
the real name I have set in it's configuration. Will check it and resend as
I won't do ammend cause I have signed of by all public commits as in these
patches. Wanted to bring this up at time for 5.0 to have it out of the box
in the next Fedora but I suppose is not going to be possible.

Thanks for the guidance you are giving to me.

El lunes, 18 de febrero de 2019, Thierry Reding 
escribió:
> On Sat, Feb 16, 2019 at 08:58:33PM +0100, David Santamaría Rogado wrote:
>> From: howl 
>
> Any reason why this differs from the Signed-off-by line? Perhaps check
> your git configuration if this wasn't on purpose. Or perhaps you've
> fixed the configuration since you authored the commits, in which case
> you should be able to fix this by doing this:
>
> $ git commit --reset-author --amend
>
> You'd need to run that for each of the commits.
>
> Thierry
>
>>
>> The (void *) casting in the driver_data variable assignment is
superfluous.
>> Spotted by Jani Nikula.
>>
>> Signed-off-by: David Santamaría Rogado 
>> ---
>>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> index 52e445bb1aa5..61d3361381b7 100644
>> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> @@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[]
= {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
>>   },
>> - .driver_data = (void *)&acer_s1003,
>> + .driver_data = &acer_s1003,
>>   }, {/* Asus T100HA */
>>   .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
>>   },
>> - .driver_data = (void *)&asus_t100ha,
>> + .driver_data = &asus_t100ha,
>>   }, {/*
>>* GPD Pocket, note that the the DMI data is less generic
then
>>* it seems, devices with a board-vendor of "AMI
Corporation"
>> @@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[]
= {
>> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>>   },
>> - .driver_data = (void *)&gpd_pocket,
>> + .driver_data = &gpd_pocket,
>>   }, {/* GPD Win (same note on DMI match as GPD Pocket) */
>>   .matches = {
>> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
>> @@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[]
= {
>> DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
>>   },
>> - .driver_data = (void *)&gpd_win,
>> + .driver_data = &gpd_win,
>>   }, {/* GPD Win 2 (too generic strings, also match on bios
date) */
>>   .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
>> @@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[]
= {
>> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
>> DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
>>   },
>> - .driver_data = (void *)&gpd_win2,
>> + .driver_data = &gpd_win2,
>>   }, {/* I.T.Works TW891 */
>>   .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by
O.E.M."),
>> @@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[]
= {
>> DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by
O.E.M."),
>> DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
>>   },
>> - .driver_data = (void *)&itworks_tw891,
>> + .driver_data = &itworks_tw891,
>>   }, {/*
>>* Lenovo Ideapad Miix 310 laptop, only some production
batches
>>* have a portrait screen, the resolution checks makes the
quirk
>> @@ -140,20 +140,20 @@ static const struct dmi_system_id
orientation_data[] = {
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
>>   },
>> - .driver_data = (void *)&lcd800x1280_rightside_up,
>> + .driver_data = &lcd800x1280_rightside_up,
>>   }, {/* Lenovo Ideapad Miix 320 */
>>   .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80

Re: [RFC v4 08/17] kunit: test: add support for test abort

[Frank Rowand]

On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.
> 
> Signed-off-by: Brendan Higgins 
> ---
> Changes Since Last Version
>  - This patch is new introducing a new cross-architecture way to abort
>out of a test case (needed for KUNIT_ASSERT_*, see next patch for
>details).
>  - On a side note, this is not a complete replacement for the UML abort
>mechanism, but covers the majority of necessary functionality. UML
>architecture specific featurs have been dropped from the initial
>patchset.
> ---
>  include/kunit/test.h |  24 +
>  kunit/Makefile   |   3 +-
>  kunit/test-test.c| 127 ++
>  kunit/test.c | 208 +--
>  4 files changed, 353 insertions(+), 9 deletions(-)
>  create mode 100644 kunit/test-test.c

< snip >

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
> @@ -6,9 +6,9 @@
>   * Author: Brendan Higgins 
>   */
>  
> -#include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
>  
>  static bool kunit_get_success(struct kunit *test)
> @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool 
> success)
>   spin_unlock_irqrestore(&test->lock, flags);
>  }
>  
> +static bool kunit_get_death_test(struct kunit *test)
> +{
> + unsigned long flags;
> + bool death_test;
> +
> + spin_lock_irqsave(&test->lock, flags);
> + death_test = test->death_test;
> + spin_unlock_irqrestore(&test->lock, flags);
> +
> + return death_test;
> +}
> +
> +static void kunit_set_death_test(struct kunit *test, bool death_test)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&test->lock, flags);
> + test->death_test = death_test;
> + spin_unlock_irqrestore(&test->lock, flags);
> +}
> +
>  static int kunit_vprintk_emit(const struct kunit *test,
> int level,
> const char *fmt,
> @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct 
> kunit_stream *stream)
>   stream->commit(stream);
>  }
>  
> +static void __noreturn kunit_abort(struct kunit *test)
> +{
> + kunit_set_death_test(test, true);
> +
> + test->try_catch.throw(&test->try_catch);
> +
> + /*
> +  * Throw could not abort from test.
> +  */
> + kunit_err(test, "Throw could not abort from test!");
> + show_stack(NULL, NULL);
> + BUG();

kunit_abort() is what will be call as the result of an assert failure.

BUG(), which is a panic, which is crashing the system is not acceptable
in the Linux kernel.  You will just annoy Linus if you submit this.

-Frank

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

Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest

[Frank Rowand]

On 2/15/19 2:56 AM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand  wrote:
>>
>> On 2/14/19 4:56 PM, Brendan Higgins wrote:
>>> On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand  wrote:

 On 12/5/18 3:54 PM, Brendan Higgins wrote:
> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand  
> wrote:
>>
>> Hi Brendan,
>>
>> On 11/28/18 11:36 AM, Brendan Higgins wrote:
>>> Split out a couple of test cases that these features in base.c from the
>>> unittest.c monolith. The intention is that we will eventually split out
>>> all test cases and group them together based on what portion of device
>>> tree they test.
>>
>> Why does splitting this file apart improve the implementation?
>
> This is in preparation for patch 19/19 and other hypothetical future
> patches where test cases are split up and grouped together by what
> portion of DT they test (for example the parsing tests and the
> platform/device tests would probably go separate files as well). This
> patch by itself does not do anything useful, but I figured it made
> patch 19/19 (and, if you like what I am doing, subsequent patches)
> easier to review.

 I do not see any value in splitting the devicetree tests into
 multiple files.

 Please help me understand what the benefits of such a split are.
>>
>> Note that my following comments are specific to the current devicetree
>> unittests, and may not apply to the general case of unit tests in other
>> subsystems.
>>
> Note taken.
>>
>>> Sorry, I thought it made sense in context of what I am doing in the
>>> following patch. All I am trying to do is to provide an effective way
>>> of grouping test cases. To be clear, the idea, assuming you agree, is
>>
>> Looking at _just_ the first few fragments of the following patch, the
>> change is to break down a moderate size function of related tests,
>> of_unittest_find_node_by_name(), into a lot of extremely small functions.
> 
> Hmm...I wouldn't call that a moderate function. By my standards those
> functions are pretty large. In any case, I want to limit the
> discussion to specifically what a test case should look like, and the
> general consensus outside of the kernel is that unit test cases should
> be very very small. The reason is that each test case is supposed to> test 
> one specific property; it should be obvious what that property
> is; and it should be obvious what is needed to exercise that property.

That is a valid model and philosophy of unit test design.

It is not a model that the devicetree unit tests can be shoe horned
into.  Sort of...  In a sense, the existing devicetree unit tests
already to that, if you consider each unittest() (and sometime a few
lines of code that creates the result that unittest() checks) to be a separate
unit test.  But the kunit model does not consider the sort of
equivalent KUNIT_EXPECT_EQ(), etc, to be a unit test, the unit test
in kunit would be KUNIT_CASE().  Although it is a little confusing to
me that the initialization and clean up on exit occur one level
higher than KUNIT_CASE(), in struct kunit_module.  I think the
confusion is just a matter of slight conflict in the documentation
(btw, the documents where very helpful for me to understand the
overall concepts and model).


>> Then to find the execution order of the many small functions requires
>> finding the array of_test_find_node_by_name_cases[].  Then I have to
> 
> Execution order shouldn't matter. Each test case should be totally
> hermetic. Obviously in this case we depend on the preceeding test case
> to clean up properly, but that is something I am working on.

But the order _does_ matter for the devicetree unit tests.

That is one of the problems.  The devicetree unit tests are not small,
independent tests.  Some of the tests change state in a way that
following tests depend upon.

The design documents also mention that each unit test should have
a pre-test initialization, and a post-test cleanup to remove the
results of the initialization.

The devicetree unit tests have a large, intrusive initialization.
Once again, not a good fit for this model.

The devicetree unit tests also have an undocumented (and not at all
obvious) need to leave state changed in some cases after the test
completes.  There are cases where the way that I fully validate
the success of the tests is to examine the state of the live
devicetree via /proc/devicetree/. Ideally, this would be done by
a script or a program, but creating that is not near the top of
my todo list.


>> chase off into the kunit test runner core, where I find that the set
>> of tests in of_test_find_node_by_name_cases[] is processed by a
>> late_initcall().  So now the order of the various test groupings,
> 
> That's fair. You are not the only one to complain about that. The
> late_initcall is a hack which I plan on replacing shortly (and yes I
> know that me planning on doing something doesn

[PATCH -next] drm/ttm: remove set but not used variable 'bdev'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function 
'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:191:24: warning:
 variable 'bdev' set but not used [-Wunused-but-set-variable]

It's not used any more and can be removed.

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 93860346c426..0075eb9a0b52 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -188,13 +188,11 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx 
*ticket,
struct ttm_validate_buffer *entry;
struct ttm_buffer_object *bo;
struct ttm_bo_global *glob;
-   struct ttm_bo_device *bdev;
 
if (list_empty(list))
return;
 
bo = list_first_entry(list, struct ttm_validate_buffer, head)->bo;
-   bdev = bo->bdev;
glob = bo->bdev->glob;
 
spin_lock(&glob->lru_lock);



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

Re: drm bridge control from another driver

[Vinay Simha B N]

added the temperature alert irq handler in adv driver , in the irq
calling schedule_work(&adv7511->hpd_work); , initially in the
adv7511_detect , if we set status = connector_status_disconnected; later
when irq handler calls the schedule work, hpd does not works.
[   55.052677] [drm] Cannot find any crtc or sizes
[   55.058786] [drm] Cannot find any crtc or sizes

by default driver of adv, hpd does not works as expected, board boots
without hdmi connected, after postboot if we connect hdmi , in irq hpd_work
,but to get the display we need to press ctrl+alt+backspace.


On Thu, Feb 14, 2019 at 8:03 PM Andrzej Hajda  wrote:

> On 13.02.2019 15:31, Vinay Simha B N wrote:
> >
> >
> > On Wed, Feb 13, 2019 at 7:44 PM Andrzej Hajda  > > wrote:
> >
> > On 13.02.2019 14:40, Vinay Simha B N wrote:
> > > Andrzej/Daniel,
> > >
> > > please suggest any input on the scenario for temperature control
> and
> > > dsi bridge enable/disable.
> > >
> > > On Mon, Feb 11, 2019 at 2:41 PM Vinay Simha B N
> > mailto:simha...@gmail.com>
> > > >> wrote:
> > >
> > > dsi2hdmi(adv7511) chip operating temperature range is -10 degC
> > > to +85 degC. We want to enable/disable the bridge only when
> > > temperature range is inbetween these range.
> > >
> > > We have temperature control chip to read the temp, tLow an
> tHigh
> > > can be set. whenever interrupt(alert) triggers we want to
> > > enablel/disable the bridge.
> > >
> > > Any suggestion what is the better way to handle this scenario?
> > >
> >
> > Why do you need to bother about this quite big range at all?
> >
> > we are looking for -10 deg C, this system will be used in a place
> > where temp goes beyond -20 deg C... processor(apq8016/410c) can handle
> > upto -30, but dsi2hdmi(adv7533) chip if enabled beyond -10 deg C, life
> > of the chip goes down or it cannot operate at all.
> >
> >
> > I guess the best would be to set whole platform operating temperature
> > range, and poweroff/sleep/slow down/??? whole system, not just one
> > random chip, which probably is not the most fragile piece, am I
> right?
> >
> > right now we are focused only to disable the hdmi chip if temp goes
> > beyond -10, since this is only chip in board faces temp issue, other
> > components are fine to go upto -30 deg C.
> >
> >
> > If you really insist on handling it per chip, you can try to
> > investigate
> > following paths:
> >
> > 1. Just disable the chip, without noticing drm, other drivers, or
> > userspace, and re-enable it if temperature become acceptable, but I
> am
> > not sure if this will not change behavior of other chips.
> >
> > dsi2hdmi tied with drm framework, i need to enable/disable the bridge.
> > i can disable the regulators enabled for it , but this does not work
> > as we want.
> >
> >
> > 2. Disable the chip and report to the drm subsystem
> > connector_status_disconnected - this will cause drm to stop display
> > pipeline and userspace notification.
> >
> > any references/driver on how to disable and report to drm susbsystem
> > will help to implement.
> > connector_status_disconnected i need to call in the interrupt handler
> > of tmp102 driver.
>
>
> Look at the code of adv7511_hpd_work, it evaluates connector status
> based on ADV7511_REG_STATUS, so you can put there temperature check
> also, and call 'schedule_work(&adv7511->hpd_work)'
>
> if temperature passes valid temp range.
>
> If you want to do it in mainline, please consult it with adv7511
> authors/commiters.
>
>
> Regards
>
> Andrzej
>
>
> >
> > in userspace when i tried manually  below commands, there is no impact
> > in the display.
> > /sys/class/drm/card0-HDMI-A-1/status
> > echo off > status
> > echo on > status
> >
> >
> > Regards
> >
> > Andrzej
> >
> >
> > >
> > > regards,
> > > vinaysimha
> > >
> > > On Mon, Feb 11, 2019 at 2:10 PM Daniel Vetter
> > mailto:dan...@ffwll.ch>
> > > >> wrote:
> > >
> > > On Mon, Feb 11, 2019 at 09:32:54AM +0100, Andrzej Hajda
> > wrote:
> > > > On 11.02.2019 07:52, Vinay Simha B N wrote:
> > > > > hi,
> > > > >
> > > > > is it possible to control the drm bridge from another
> > > driver in irq
> > > > > handler(enable/disable the bridge)?
> > > >
> > > >
> > > > If you mean 'in irq context' the answer is no, usually
> > > enable/disable
> > > > callbacks can sleep, so cannot be called from atomic
> > context.
> > > >
> > > >
> > > > >
> > > > > is there a way to control the "dpms force off" and
> "dpms
> > > force on" in
> >  

Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

[Frank Rowand]

On 2/14/19 1:37 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
> 
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
> and does not require tests to be written in userspace running on a host
> kernel. Additionally, KUnit is fast: From invocation to completion KUnit
> can run several dozen tests in under a second. Currently, the entire
> KUnit test suite for KUnit runs in under a second from the initial
> invocation (build time excluded).
> 
> KUnit is heavily inspired by JUnit, Python's unittest.mock, and
> Googletest/Googlemock for C++. KUnit provides facilities for defining
> unit test cases, grouping related test cases into test suites, providing
> common infrastructure for running tests, mocking, spying, and much more.
> 
> ## What's so special about unit testing?
> 
> A unit test is supposed to test a single unit of code in isolation,
> hence the name. There should be no dependencies outside the control of
> the test; this means no external dependencies, which makes tests orders
> of magnitudes faster. Likewise, since there are no external dependencies,
> there are no hoops to jump through to run the tests. Additionally, this
> makes unit tests deterministic: a failing unit test always indicates a
> problem. Finally, because unit tests necessarily have finer granularity,
> they are able to test all code paths easily solving the classic problem
> of difficulty in exercising error handling code.
> 
> ## Is KUnit trying to replace other testing frameworks for the kernel?
> 
> No. Most existing tests for the Linux kernel are end-to-end tests, which
> have their place. A well tested system has lots of unit tests, a
> reasonable number of integration tests, and some end-to-end tests. KUnit
> is just trying to address the unit test space which is currently not
> being addressed.
> 
> ## More information on KUnit
> 
> There is a bunch of documentation near the end of this patch set that
> describes how to use KUnit and best practices for writing unit tests.
> For convenience I am hosting the compiled docs here:
> https://google.github.io/kunit-docs/third_party/kernel/docs/
> Additionally for convenience, I have applied these patches to a branch:
> https://kunit.googlesource.com/linux/+/kunit/rfc/5.0-rc5/v4
> The repo may be cloned with:
> git clone https://kunit.googlesource.com/linux
> This patchset is on the kunit/rfc/5.0-rc5/v4 branch.
> 
> ## Changes Since Last Version
> 
>  - Got KUnit working on (hypothetically) all architectures (tested on
>x86), as per Rob's (and other's) request
>  - Punting all KUnit features/patches depending on UML for now.
>  - Broke out UML specific support into arch/um/* as per "[RFC v3 01/19]
>kunit: test: add KUnit test runner core", as requested by Luis.
>  - Added support to kunit_tool to allow it to build kernels in external
>directories, as suggested by Kieran.
>  - Added a UML defconfig, and a config fragment for KUnit as suggested
>by Kieran and Luis.
>  - Cleaned up, and reformatted a bunch of stuff.
> 

I have not read through the patches in any detail.  I have read some of
the code to try to understand the patches to the devicetree unit tests.
So that may limit how valid my comments below are.

I found the code difficult to read in places where it should have been
much simpler to read.  Structuring the code in a pseudo object oriented
style meant that everywhere in a code path that I encountered a dynamic
function call, I had to go find where that dynamic function call was
initialized (and being the cautious person that I am, verify that
no where else was the value of that dynamic function call).  With
primitive vi and tags, that search would have instead just been a
simple key press (or at worst a few keys) if hard coded function
calls were done instead of dynamic function calls.  In the code paths
that I looked at, I did not see any case of a dynamic function being
anything other than the value it was originally initialized as.
There may be such cases, I did not read the entire patch set.  There
may also be cases envisioned in the architects mind of how this
flexibility may be of future value.  Dunno.

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

[PATCH] video/macfb: Always initialize DAFB colour table pointer register

[Finn Thain]

Don't skip the framebuffer CLUT pointer register initialization when
the first dafb_setpalette() invocation has regno equal to zero.

Cc: linux-m...@lists.linux-m68k.org
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Finn Thain 
---
 drivers/video/fbdev/macfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/macfb.c b/drivers/video/fbdev/macfb.c
index 37c56c45ee39..8820a556014c 100644
--- a/drivers/video/fbdev/macfb.c
+++ b/drivers/video/fbdev/macfb.c
@@ -148,7 +148,7 @@ static int dafb_setpalette(unsigned int regno, unsigned int 
red,
   unsigned int green, unsigned int blue,
   struct fb_info *info)
 {
-   static int lastreg = -1;
+   static int lastreg = -2;
unsigned long flags;
 
local_irq_save(flags);
-- 
2.19.2

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

Re: [PATCH] drivers/component: kerneldoc polish

[Randy Dunlap]

On 2/18/19 8:36 AM, Daniel Vetter wrote:
> Polish the kerneldoc a bit with suggestions from Randy.
> 
> v2: Randy found another typo: s/compent/component/
> 
> Cc: Randy Dunlap 
> Signed-off-by: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Cc: Daniel Vetter 
> Cc: Ramalingam C 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  drivers/base/component.c  | 14 +++---
>  include/linux/component.h |  2 +-
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 7dbc41cccd58..532a3a5d8f63 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -27,7 +27,7 @@
>   * helper fills the niche of aggregate drivers for specific hardware, where
>   * further standardization into a subsystem would not be practical. The 
> common
>   * example is when a logical device (e.g. a DRM display driver) is spread 
> around
> - * the SoC on various component (scanout engines, blending blocks, 
> transcoders
> + * the SoC on various components (scanout engines, blending blocks, 
> transcoders
>   * for various outputs and so on).
>   *
>   * The component helper also doesn't solve runtime dependencies, e.g. for 
> system
> @@ -378,7 +378,7 @@ static void __component_match_add(struct device *master,
>  }
>  
>  /**
> - * component_match_add_release - add a component match with release callback
> + * component_match_add_release - add a component match entry with release 
> callback
>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @release: release function for @compare_data
> @@ -408,7 +408,7 @@ void component_match_add_release(struct device *master,
>  EXPORT_SYMBOL(component_match_add_release);
>  
>  /**
> - * component_match_add_typed - add a compent match for a typed component
> + * component_match_add_typed - add a component match entry for a typed 
> component
>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @compare_typed: compare function to match against all typed components
> @@ -537,11 +537,11 @@ static void component_unbind(struct component 
> *component,
>  }
>  
>  /**
> - * component_unbind_all - unbind all component to an aggregate driver
> + * component_unbind_all - unbind all components of an aggregate driver
>   * @master_dev: device with the aggregate driver
>   * @data: opaque pointer, passed to all components
>   *
> - * Unbinds all components to the aggregate @dev by passing @data to their
> + * Unbinds all components of the aggregate @dev by passing @data to their
>   * &component_ops.unbind functions. Should be called from
>   * &component_master_ops.unbind.
>   */
> @@ -619,11 +619,11 @@ static int component_bind(struct component *component, 
> struct master *master,
>  }
>  
>  /**
> - * component_bind_all - bind all component to an aggregate driver
> + * component_bind_all - bind all components of an aggregate driver
>   * @master_dev: device with the aggregate driver
>   * @data: opaque pointer, passed to all components
>   *
> - * Binds all components to the aggregate @dev by passing @data to their
> + * Binds all components of the aggregate @dev by passing @data to their
>   * &component_ops.bind functions. Should be called from
>   * &component_master_ops.bind.
>   */
> diff --git a/include/linux/component.h b/include/linux/component.h
> index 30bcc7e590eb..16de18f473d7 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -98,7 +98,7 @@ void component_match_add_typed(struct device *master,
>   int (*compare_typed)(struct device *, int, void *), void *compare_data);
>  
>  /**
> - * component_match_add - add a compent match
> + * component_match_add - add a component match entry
>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @compare: compare function to match against all components
> 


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

[PATCH RESEND 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[David Santamaría Rogado]

The (void *) casting in the driver_data variable assignment is superfluous.
Spotted by Jani Nikula.

Signed-off-by: David Santamaría Rogado 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52e445bb1aa5..61d3361381b7 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
},
-   .driver_data = (void *)&acer_s1003,
+   .driver_data = &acer_s1003,
}, {/* Asus T100HA */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
},
-   .driver_data = (void *)&asus_t100ha,
+   .driver_data = &asus_t100ha,
}, {/*
 * GPD Pocket, note that the the DMI data is less generic then
 * it seems, devices with a board-vendor of "AMI Corporation"
@@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_pocket,
+   .driver_data = &gpd_pocket,
}, {/* GPD Win (same note on DMI match as GPD Pocket) */
.matches = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
@@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_win,
+   .driver_data = &gpd_win,
}, {/* GPD Win 2 (too generic strings, also match on bios date) */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
@@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
},
-   .driver_data = (void *)&gpd_win2,
+   .driver_data = &gpd_win2,
}, {/* I.T.Works TW891 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
@@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by O.E.M."),
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
},
-   .driver_data = (void *)&itworks_tw891,
+   .driver_data = &itworks_tw891,
}, {/*
 * Lenovo Ideapad Miix 310 laptop, only some production batches
 * have a portrait screen, the resolution checks makes the quirk
@@ -140,20 +140,20 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
}, {/* Lenovo Ideapad Miix 320 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
}, {/* VIOS LTH17 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
},
-   .driver_data = (void *)&lcd800x1280_rightside_up,
+   .driver_data = &lcd800x1280_rightside_up,
},
{}
 };
-- 
2.20.1

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

Re: [PATCH RESEND 1/2] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

[David Santamaría Rogado]

OK, I think I did it right, rebase two commits and ammeded both and
now resend. This one has been attached to this thread but number 2 has
been in a new thread.

El mar., 19 feb. 2019 a las 0:35, David Santamaría Rogado
() escribió:
>
> The (void *) casting in the driver_data variable assignment is superfluous.
> Spotted by Jani Nikula.
>
> Signed-off-by: David Santamaría Rogado 
> ---
>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 52e445bb1aa5..61d3361381b7 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -86,13 +86,13 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
> },
> -   .driver_data = (void *)&acer_s1003,
> +   .driver_data = &acer_s1003,
> }, {/* Asus T100HA */
> .matches = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
> },
> -   .driver_data = (void *)&asus_t100ha,
> +   .driver_data = &asus_t100ha,
> }, {/*
>  * GPD Pocket, note that the the DMI data is less generic then
>  * it seems, devices with a board-vendor of "AMI Corporation"
> @@ -105,7 +105,7 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
> },
> -   .driver_data = (void *)&gpd_pocket,
> +   .driver_data = &gpd_pocket,
> }, {/* GPD Win (same note on DMI match as GPD Pocket) */
> .matches = {
>   DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> @@ -113,7 +113,7 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_BOARD_SERIAL, "Default string"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
> },
> -   .driver_data = (void *)&gpd_win,
> +   .driver_data = &gpd_win,
> }, {/* GPD Win 2 (too generic strings, also match on bios date) */
> .matches = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> @@ -121,7 +121,7 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
>   DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
> },
> -   .driver_data = (void *)&gpd_win2,
> +   .driver_data = &gpd_win2,
> }, {/* I.T.Works TW891 */
> .matches = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
> @@ -129,7 +129,7 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "To be filled by O.E.M."),
>   DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
> },
> -   .driver_data = (void *)&itworks_tw891,
> +   .driver_data = &itworks_tw891,
> }, {/*
>  * Lenovo Ideapad Miix 310 laptop, only some production 
> batches
>  * have a portrait screen, the resolution checks makes the 
> quirk
> @@ -140,20 +140,20 @@ static const struct dmi_system_id orientation_data[] = {
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80SG"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
> },
> -   .driver_data = (void *)&lcd800x1280_rightside_up,
> +   .driver_data = &lcd800x1280_rightside_up,
> }, {/* Lenovo Ideapad Miix 320 */
> .matches = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 
> 320-10ICR"),
> },
> -   .driver_data = (void *)&lcd800x1280_rightside_up,
> +   .driver_data = &lcd800x1280_rightside_up,
> }, {/* VIOS LTH17 */
> .matches = {
>   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
>   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
> },
> -   .driver_data = (void *)&lcd800x1280_rightside_up,
> +   .driver_data = &lcd800x1280_rightside_up,
> },
> {}
>  };
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.

[PATCH RESEND 2/2] drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad D330

[David Santamaría Rogado]

Lenovo Ideapad D330 Pentium CPU version has 1920x1200 LCD. Console
ouput gets rotated at boot as Miix 310.

Signed-off-by: David Santamaría Rogado 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 61d3361381b7..835574e2d5bf 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -80,6 +80,12 @@ static const struct drm_dmi_panel_orientation_data 
lcd800x1280_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+static const struct drm_dmi_panel_orientation_data lcd1200x1920_rightside_up = 
{
+   .width = 1200,
+   .height = 1920,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
 static const struct dmi_system_id orientation_data[] = {
{   /* Acer One 10 (S1003) */
.matches = {
@@ -130,6 +136,13 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
},
.driver_data = &itworks_tw891,
+   }, {/* Lenovo Ideapad D330 */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
D330-10IGM"),
+   },
+   .driver_data = &lcd1200x1920_rightside_up,
}, {/*
 * Lenovo Ideapad Miix 310 laptop, only some production batches
 * have a portrait screen, the resolution checks makes the quirk
-- 
2.20.1

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

Re: [PATCH] drivers/component: kerneldoc polish

[Randy Dunlap]

On 2/18/19 12:52 AM, Daniel Vetter wrote:
> Polish the kerneldoc a bit with suggestions from Randy.
> 

Hi Daniel,
There are 2 more typos below.  With those fixed, you or Greg can add:
Acked-by: Randy Dunlap 

Thanks.

> Cc: Randy Dunlap 
> Signed-off-by: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Cc: Daniel Vetter 
> Cc: Ramalingam C 
> --
> Greg, I don't need this in any of the topic branches, best if you
> pick this one up into your -next tree directly.
> 
> Cheers, Daniel
> ---
>  drivers/base/component.c  | 14 +++---
>  include/linux/component.h |  2 +-
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 7dbc41cccd58..6954e448f46b 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -27,7 +27,7 @@
>   * helper fills the niche of aggregate drivers for specific hardware, where
>   * further standardization into a subsystem would not be practical. The 
> common
>   * example is when a logical device (e.g. a DRM display driver) is spread 
> around
> - * the SoC on various component (scanout engines, blending blocks, 
> transcoders
> + * the SoC on various components (scanout engines, blending blocks, 
> transcoders
>   * for various outputs and so on).
>   *
>   * The component helper also doesn't solve runtime dependencies, e.g. for 
> system
> @@ -378,7 +378,7 @@ static void __component_match_add(struct device *master,
>  }
>  
>  /**
> - * component_match_add_release - add a component match with release callback
> + * component_match_add_release - add a component match entry with release 
> callback
>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @release: release function for @compare_data
> @@ -408,7 +408,7 @@ void component_match_add_release(struct device *master,
>  EXPORT_SYMBOL(component_match_add_release);
>  
>  /**
> - * component_match_add_typed - add a compent match for a typed component
> + * component_match_add_typed - add a compent match entry for a typed 
> component

component

>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @compare_typed: compare function to match against all typed components
> @@ -537,11 +537,11 @@ static void component_unbind(struct component 
> *component,
>  }
>  
>  /**
> - * component_unbind_all - unbind all component to an aggregate driver
> + * component_unbind_all - unbind all components of an aggregate driver
>   * @master_dev: device with the aggregate driver
>   * @data: opaque pointer, passed to all components
>   *
> - * Unbinds all components to the aggregate @dev by passing @data to their
> + * Unbinds all components of the aggregate @dev by passing @data to their
>   * &component_ops.unbind functions. Should be called from
>   * &component_master_ops.unbind.
>   */
> @@ -619,11 +619,11 @@ static int component_bind(struct component *component, 
> struct master *master,
>  }
>  
>  /**
> - * component_bind_all - bind all component to an aggregate driver
> + * component_bind_all - bind all components of an aggregate driver
>   * @master_dev: device with the aggregate driver
>   * @data: opaque pointer, passed to all components
>   *
> - * Binds all components to the aggregate @dev by passing @data to their
> + * Binds all components of the aggregate @dev by passing @data to their
>   * &component_ops.bind functions. Should be called from
>   * &component_master_ops.bind.
>   */
> diff --git a/include/linux/component.h b/include/linux/component.h
> index 30bcc7e590eb..8628d4d0aff1 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -98,7 +98,7 @@ void component_match_add_typed(struct device *master,
>   int (*compare_typed)(struct device *, int, void *), void *compare_data);
>  
>  /**
> - * component_match_add - add a compent match
> + * component_match_add - add a compent match entry

  component

>   * @master: device with the aggregate driver
>   * @matchptr: pointer to the list of component matches
>   * @compare: compare function to match against all components
> 


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

Re: [RFC v3 17/19] of: unittest: migrate tests to run on KUnit

[Frank Rowand]

On 2/12/19 5:44 PM, Brendan Higgins wrote:
> On Wed, Nov 28, 2018 at 12:56 PM Rob Herring  wrote:
>>
>> On Wed, Nov 28, 2018 at 1:38 PM Brendan Higgins
>>  wrote:
>>>
>>> Migrate tests without any cleanup, or modifying test logic in anyway to
>>> run under KUnit using the KUnit expectation and assertion API.
>>
>> Nice! You beat me to it. This is probably going to conflict with what
>> is in the DT tree for 4.21. Also, please Cc the DT list for
>> drivers/of/ changes.
>>
>> Looks good to me, but a few mostly formatting comments below.
> 
> I just realized that we never talked about your other comments, and I
> still have some questions. (Sorry, it was the last thing I looked at
> while getting v4 ready.) No worries if you don't get to it before I
> send v4 out, I just didn't want you to think I was ignoring you.
> 
>>
>>>
>>> Signed-off-by: Brendan Higgins 
>>> ---
>>>  drivers/of/Kconfig|1 +
>>>  drivers/of/unittest.c | 1405 ++---
>>>  2 files changed, 752 insertions(+), 654 deletions(-)
>>>
> 
>>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>>> index 41b49716ac75f..a5ef44730ffdb 100644
>>> --- a/drivers/of/unittest.c
>>> +++ b/drivers/of/unittest.c
> 
>>> -
>>> -static void __init of_unittest_find_node_by_name(void)
>>> +static void of_unittest_find_node_by_name(struct kunit *test)
>>
>> Why do we have to drop __init everywhere? The tests run later?
> 
>>From the standpoint of a unit test __init doesn't really make any
> sense, right? I know that right now we are running as part of a
> kernel, but the goal should be that a unit test is not part of a
> kernel and we just include what we need.
> 
> Even so, that's the future. For now, I did not put the KUnit
> infrastructure in the .init section because I didn't think it belonged
> there. In practice, KUnit only knows how to run during the init phase
> of the kernel, but I don't think it should be restricted there. You
> should be able to run tests whenever you want because you should be
> able to test anything right? I figured any restriction on that is
> misleading and will potentially get in the way at worst, and
> unnecessary at best especially since people shouldn't build a
> production kernel with all kinds of unit tests inside.
> 
>>
>>>  {
>>> struct device_node *np;
>>> const char *options, *name;
>>>
> 
>>>
>>>
>>> -   np = of_find_node_by_path("/testcase-data/missing-path");
>>> -   unittest(!np, "non-existent path returned node %pOF\n", np);
>>> +   KUNIT_EXPECT_EQ_MSG(test,
>>> +   
>>> of_find_node_by_path("/testcase-data/missing-path"),
>>> +   NULL,
>>> +   "non-existent path returned node %pOF\n", np);
>>
>> 1 tab indent would help with less vertical code (in general, not this
>> one so much).
> 
> Will do.
> 
>>
>>> of_node_put(np);
>>>
>>> -   np = of_find_node_by_path("missing-alias");
>>> -   unittest(!np, "non-existent alias returned node %pOF\n", np);
>>> +   KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("missing-alias"), 
>>> NULL,
>>> +   "non-existent alias returned node %pOF\n", np);
>>> of_node_put(np);
>>>
>>> -   np = of_find_node_by_path("testcase-alias/missing-path");
>>> -   unittest(!np, "non-existent alias with relative path returned node 
>>> %pOF\n", np);
>>> +   KUNIT_EXPECT_EQ_MSG(test,
>>> +   
>>> of_find_node_by_path("testcase-alias/missing-path"),
>>> +   NULL,
>>> +   "non-existent alias with relative path returned 
>>> node %pOF\n",
>>> +   np);
>>> of_node_put(np);
>>>
> 
>>>
>>> -static void __init of_unittest_property_string(void)
>>> +static void of_unittest_property_string(struct kunit *test)
>>>  {
>>> const char *strings[4];
>>> struct device_node *np;
>>> int rc;
>>>
>>> np = 
>>> of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
>>> -   if (!np) {
>>> -   pr_err("No testcase data in device tree\n");
>>> -   return;
>>> -   }
>>> -
>>> -   rc = of_property_match_string(np, "phandle-list-names", "first");
>>> -   unittest(rc == 0, "first expected:0 got:%i\n", rc);
>>> -   rc = of_property_match_string(np, "phandle-list-names", "second");
>>> -   unittest(rc == 1, "second expected:1 got:%i\n", rc);
>>> -   rc = of_property_match_string(np, "phandle-list-names", "third");
>>> -   unittest(rc == 2, "third expected:2 got:%i\n", rc);
>>> -   rc = of_property_match_string(np, "phandle-list-names", "fourth");
>>> -   unittest(rc == -ENODATA, "unmatched string; rc=%i\n", rc);
>>> -   rc = of_property_match_string(np, "missing-property", "blah");
>>> -   unittest(rc == -EINVAL, "missing property; rc=%i\n", rc);
>>> -   rc = of_property_match_string(np, "empty-property", "

[Bug 108579] Request new account for IGT

[bugzilla-daemon]

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

Lakshmi  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Maxime Ripard]

On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 18, 2019 at 10:26 AM Rob Herring  wrote:
> >
> > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > > Validate the clock rate") prevents some panel and bridges from working 
> > > with
> > > sun4i driver.
> >
> > Sounds lile a regression that should be reverted. The fix is not a
> > backwards compatible change either.
> 
> anx6345 driver isn't mainlined yet and I'm not sure if this change
> breaks any mainlined boards. So likely there's not enough
> justification to revert it.
> 
> > > Unfortunately, dotclock frequency for some modes are not achievable on
> > > sunxi hardware, and there's a slight deviation in rate returned by
> > > clk_round_rate(), so they fail this check.
> > >
> > > Experiments show that panels and bridges work fine with this slight
> > > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > > fine.
> > >
> > > This patch adds DT property to disable strict clock rate check
> > >
> > > Signed-off-by: Vasily Khoruzhick 
> > > ---
> > >  .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 2 ++
> > >  drivers/gpu/drm/sun4i/sun4i_rgb.c| 5 +
> > >  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 3 +++
> > >  drivers/gpu/drm/sun4i/sun4i_tcon.h   | 1 +
> > >  4 files changed, 11 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > index f426bdb42f18..18c8b053a28d 100644
> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > @@ -63,6 +63,8 @@ Required properties:
> > >  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > >  first port should be the input endpoint. The second should be the
> > >  output, usually to an HDMI connector.
> > > +  - no-strict-clock-check: don't reject timings if exact dot clock can't 
> > > be
> > > +reached.
> >
> > This should be the default IMO. Most panels are a single timing, so if
> > we reject it the fallback no display?
> 
> As far as I remember the change was introduced to reject some modes
> for which dotclock can't be reached when driver is used with VGA
> bridge. So if we make it default it'll break boards with VGA bridge
> and old DT.
> 
> > I thought we had some mechanism already to allow some range of
> > frequencies. I think the chromeos guys needed something IIRC.
> 
> You can specify frequency range for panels, but there's nothing for
> bridges. In my case EDID doesn't specify clock tolerance.

I gave it some more though, and came up with the following patch. The
basic idea is to leave the boundary check for the bridges that will
have EDID and we need to filter out the modes that have no chance of
being supported. The tolerancy used is the one defined in VESA specs,
but I added a module parameter if you wanted to tune that.

And finally, since most of our panels are single timings without any
tolerancy, we just try our best in this case and that's it, while
leaving the door open to support display_timings and being able to do
more once we have an idea of what the tolerancies are.

If that works for you, I'll submit it.

Maxime

--- >8 ---
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f4a22689eb54..0460146aab75 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -43,6 +43,25 @@ drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
encoder);
 }
 
+static inline struct drm_connector *
+sun4i_rgb_get_connector_from_encoder(const struct drm_encoder *encoder)
+{
+   struct drm_connector *connector = NULL, *tmp;
+   struct drm_connector_list_iter iter;
+
+   drm_connector_list_iter_begin(encoder->dev, &iter);
+   drm_for_each_connector_iter(tmp, &iter)
+   if (tmp->encoder == encoder) {
+   connector = tmp;
+   goto out;
+   }
+
+out:
+   drm_connector_list_iter_end(&iter);
+
+   return connector;
+}
+
 static int sun4i_rgb_get_modes(struct drm_connector *connector)
 {
struct sun4i_rgb *rgb =
@@ -52,11 +71,22 @@ static int sun4i_rgb_get_modes(struct drm_connector 
*connector)
return drm_panel_get_modes(tcon->panel);
 }
 
+/*
+ * VESA DMT defines a tolerancy of 0.5% on the pixel clock, while the
+ * CVT spec reuses that tolerancy in its examples, so it looks to be a
+ * good default tolerancy for the EDID-based modes.
+ */
+static unsigned int clock_tolerancy = 5;
+module_param(clock_tolerancy, uint, 0644);
+MODULE_PARM_DESC(clock_t

[PATCH v1 2/2] drm/mediatek: add mipi_tx driver for mt8183

[Jitao Shi]

This patch add mt8183 mipi_tx driver.
And also support other chips that use the same binding and driver.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c|   2 +
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|   1 +
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 ++
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c

diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index fa361c8be8d7..83fb7717d383 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -198,6 +198,8 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
  .data = &mt2701_mipitx_data },
{ .compatible = "mediatek,mt8173-mipi-tx",
  .data = &mt8173_mipitx_data },
+   { .compatible = "mediatek,mt8183-mipi-tx",
+ .data = &mt8183_mipitx_data },
{ },
 };
 
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
index 2d7f05b0d6a7..af83023e81cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
@@ -47,5 +47,6 @@ unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
 
 extern const struct mtk_mipitx_data mt2701_mipitx_data;
 extern const struct mtk_mipitx_data mt8173_mipitx_data;
+extern const struct mtk_mipitx_data mt8183_mipitx_data;
 
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
new file mode 100644
index ..07f70a3cad13
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "mtk_mipi_tx.h"
+
+#define MIPITX_LANE_CON0x000c
+#define RG_DSI_CPHY_T1DRV_EN   BIT(0)
+#define RG_DSI_ANA_CK_SEL  BIT(1)
+#define RG_DSI_PHY_CK_SEL  BIT(2)
+#define RG_DSI_CPHY_EN BIT(3)
+#define RG_DSI_PHYCK_INV_ENBIT(4)
+#define RG_DSI_PWR04_ENBIT(5)
+#define RG_DSI_BG_LPF_EN   BIT(6)
+#define RG_DSI_BG_CORE_EN  BIT(7)
+#define RG_DSI_PAD_TIEL_SELBIT(8)
+
+#define MIPITX_PLL_PWR 0x0028
+#define MIPITX_PLL_CON00x002c
+#define MIPITX_PLL_CON10x0030
+#define MIPITX_PLL_CON20x0034
+#define MIPITX_PLL_CON30x0038
+#define MIPITX_PLL_CON40x003c
+#define RG_DSI_PLL_IBIAS   (3 << 10)
+
+#define MIPITX_D2_SW_CTL_EN0x0144
+#define MIPITX_D0_SW_CTL_EN0x0244
+#define MIPITX_CK_CKMODE_EN0x0328
+#define DSI_CK_CKMODE_EN   BIT(0)
+#define MIPITX_CK_SW_CTL_EN0x0344
+#define MIPITX_D1_SW_CTL_EN0x0444
+#define MIPITX_D3_SW_CTL_EN0x0544
+#define DSI_SW_CTL_EN  BIT(0)
+#define AD_DSI_PLL_SDM_PWR_ON  BIT(0)
+#define AD_DSI_PLL_SDM_ISO_EN  BIT(1)
+
+#define RG_DSI_PLL_EN  BIT(4)
+#define RG_DSI_PLL_POSDIV  (0x7 << 8)
+
+static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
+{
+   struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
+   unsigned int txdiv, txdiv0, txdiv1;
+   u64 pcw;
+   int ret;
+
+   dev_dbg(mipi_tx->dev, "prepare: %u bps\n", mipi_tx->data_rate);
+
+   if (mipi_tx->data_rate >= 20) {
+   txdiv = 1;
+   txdiv0 = 0;
+   txdiv1 = 0;
+   } else if (mipi_tx->data_rate >= 10) {
+   txdiv = 2;
+   txdiv0 = 1;
+   txdiv1 = 0;
+   } else if (mipi_tx->data_rate >= 5) {
+   txdiv = 4;
+   txdiv0 = 2;
+   txdiv1 = 0;
+   } else if (mipi_tx->data_rate > 25000) {
+   txdiv = 8;
+   txdiv0 = 3;
+   txdiv1 = 0;
+   } else if (mipi_tx->data_rate >= 12500) {
+   txdiv = 16;
+   txdiv0 = 4;
+   txdiv1 = 0;
+   } else {
+   return -EINVAL;
+   }
+
+   ret = clk_prepare_enable(mipi_tx->ref_clk);
+   if (ret < 0) {
+   dev_err(mipi_tx->dev, "can't mipi_tx ref_clk %d\n", ret);
+   return ret;
+   }
+
+   mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_CON4, RG_DSI_PLL_IBIAS);
+
+   mtk_mipi_tx_set_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
+   usleep_range(30, 100);
+   mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
+   pcw = div_u64(((u64)mipi_tx->data_rate * txdiv) << 24, 2600);
+   writel(pcw, mipi_tx->regs + MIPIT

[PATCH v1 0/2] drm/mediatek: add mipi_tx driver for mt8183

[Jitao Shi]

MT8183 has different setting to MT8173(exist chip). We add mt8183 mipi_tx 
driver.
1) Separate mipi_tx to common part and chip relate part.
2) Add mt8183 mipi_tx driver

Changes since v0:
- Separate two independent patches.

Jitao Shi (2):
  drm/mediatek: separate mipi_tx to different file
  drm/mediatek: add mipi_tx driver for mt8183

 drivers/gpu/drm/mediatek/Makefile |   1 +
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 352 ++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  52 +++
 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 +
 5 files changed, 548 insertions(+), 315 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c

-- 
2.20.1

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

[PATCH v1 1/2] drm/mediatek: separate mipi_tx to different file

[Jitao Shi]

Different IC has different mipi_tx setting of dsi.
This patch separates the mipi_tx hardware relate part for mt8173.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/Makefile |   1 +
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 350 ++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  51 +++
 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++
 4 files changed, 377 insertions(+), 315 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 82ae49c64221..2c8de1f5a5ee 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -12,6 +12,7 @@ mediatek-drm-y := mtk_disp_color.o \
  mtk_drm_plane.o \
  mtk_dsi.o \
  mtk_mipi_tx.o \
+ mtk_mt8173_mipi_tx.o \
  mtk_dpi.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index 90e913108950..fa361c8be8d7 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -11,292 +11,45 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define MIPITX_DSI_CON 0x00
-#define RG_DSI_LDOCORE_EN  BIT(0)
-#define RG_DSI_CKG_LDOOUT_EN   BIT(1)
-#define RG_DSI_BCLK_SEL(3 << 2)
-#define RG_DSI_LD_IDX_SEL  (7 << 4)
-#define RG_DSI_PHYCLK_SEL  (2 << 8)
-#define RG_DSI_DSICLK_FREQ_SEL BIT(10)
-#define RG_DSI_LPTX_CLMP_ENBIT(11)
-
-#define MIPITX_DSI_CLOCK_LANE  0x04
-#define MIPITX_DSI_DATA_LANE0  0x08
-#define MIPITX_DSI_DATA_LANE1  0x0c
-#define MIPITX_DSI_DATA_LANE2  0x10
-#define MIPITX_DSI_DATA_LANE3  0x14
-#define RG_DSI_LNTx_LDOOUT_EN  BIT(0)
-#define RG_DSI_LNTx_CKLANE_EN  BIT(1)
-#define RG_DSI_LNTx_LPTX_IPLUS1BIT(2)
-#define RG_DSI_LNTx_LPTX_IPLUS2BIT(3)
-#define RG_DSI_LNTx_LPTX_IMINUSBIT(4)
-#define RG_DSI_LNTx_LPCD_IPLUS BIT(5)
-#define RG_DSI_LNTx_LPCD_IMINUSBIT(6)
-#define RG_DSI_LNTx_RT_CODE(0xf << 8)
-
-#define MIPITX_DSI_TOP_CON 0x40
-#define RG_DSI_LNT_INTR_EN BIT(0)
-#define RG_DSI_LNT_HS_BIAS_EN  BIT(1)
-#define RG_DSI_LNT_IMP_CAL_EN  BIT(2)
-#define RG_DSI_LNT_TESTMODE_EN BIT(3)
-#define RG_DSI_LNT_IMP_CAL_CODE(0xf << 4)
-#define RG_DSI_LNT_AIO_SEL (7 << 8)
-#define RG_DSI_PAD_TIE_LOW_EN  BIT(11)
-#define RG_DSI_DEBUG_INPUT_EN  BIT(12)
-#define RG_DSI_PRESERVE(7 << 13)
-
-#define MIPITX_DSI_BG_CON  0x44
-#define RG_DSI_BG_CORE_EN  BIT(0)
-#define RG_DSI_BG_CKEN BIT(1)
-#define RG_DSI_BG_DIV  (0x3 << 2)
-#define RG_DSI_BG_FAST_CHARGE  BIT(4)
-#define RG_DSI_VOUT_MSK(0x3 << 5)
-#define RG_DSI_V12_SEL (7 << 5)
-#define RG_DSI_V10_SEL (7 << 8)
-#define RG_DSI_V072_SEL(7 << 11)
-#define RG_DSI_V04_SEL (7 << 14)
-#define RG_DSI_V032_SEL(7 << 17)
-#define RG_DSI_V02_SEL (7 << 20)
-#define RG_DSI_BG_R1_TRIM  (0xf << 24)
-#define RG_DSI_BG_R2_TRIM  (0xf << 28)
-
-#define MIPITX_DSI_PLL_CON00x50
-#define RG_DSI_MPPLL_PLL_ENBIT(0)
-#define RG_DSI_MPPLL_DIV_MSK   (0x1ff << 1)
-#define RG_DSI_MPPLL_PREDIV(3 << 1)
-#define RG_DSI_MPPLL_TXDIV0(3 << 3)
-#define RG_DSI_MPPLL_TXDIV1(3 << 5)
-#define RG_DSI_MPPLL_POSDIV(7 << 7)
-#define RG_DSI_MPPLL_MONVC_EN  BIT(10)
-#define RG_DSI_MPPLL_MONREF_EN BIT(11)
-#define RG_DSI_MPPLL_VOD_ENBIT(12)
-
-#define MIPITX_DSI_PLL_CON10x54
-#define RG_DSI_MPPLL_SDM_FRA_ENBIT(0)
-#define RG_DSI_MPPLL_SDM_SSC_PH_INIT   BIT(1)
-#define RG_DSI_MPPLL_SDM_SSC_ENBIT(2)
-#define RG_DSI_MPPLL_SDM_SSC_PRD   (0x << 16)
-
-#define MIPITX_DSI_PLL_CON20x58
-
-#define MIPITX_DSI_PLL_TOP 0x64
-#define RG_DSI_MPPLL_PRESERVE  (0xff << 8)
-
-#define MIPITX_DSI_PLL_PWR 0x68
-#define RG_DSI_MPPLL_SDM_PWR_ONBIT(0)
-#define RG_DSI_MPPLL_SDM_ISO_ENBIT(1)
-#define RG_DSI_MPPLL_SDM_PWR_ACK   BIT(8)
-
-#define MIPITX_DSI_SW_CTRL 0x80
-#define SW_CTRL_EN BIT(0)
-
-#define MIPITX_DSI_SW_CTRL_CON00x84
-#define SW_LNTC_LPTX_PRE_OEBIT(0)
-#define SW_LNTC_LPTX_OEBIT(1)
-#define SW_LNTC_LPTX_P BIT(2)
-#define SW_LNTC_LPTX_N

Re: freedreno header uses not installed xf86atomic.h

[Eric Engestrom]

On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
>  wrote:
> >
> > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom  
> > wrote:
> > >
> > > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > > > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake  
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Using libdrm-2.4.97, mesa fails to build on ARM with:
> > > > > >
> > > > > > [  456s] In file included from
> > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> > > > > > [  456s]  from
> > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
> > > > > > [  456s]  from
> > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_context.h:39,
> > > > > > [  456s]  from
> > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_program.c:33:
> > > > > > [  456s] /usr/include/freedreno/freedreno_ringbuffer.h:32:10: fatal
> > > > > > error: xf86atomic.h: No such file or directory
> > > > > >
> > > > > > The freedreno headers were recently modified to use xf86atomic.h:
> > > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> > > > > >
> > > > >
> > > > > oh, that union/ifdef hack was specifically to avoid this issue..
> > > > > probably the patch removing it should be reverted.
> > > >
> > > > Right, I messed up with that commit, I didn't realise 
> > > > freedreno_ringbuffer.h
> > > > was installed. We need to remove that include.
> > > >
> > > > That said, I'm confused as to how freedreno_ringbuffer.h users in Mesa
> > > > knows whether it's safe to use refcnt from that union?
> > > > It doesn't check for HAS_ATOMIC_OPS, so it can't know whether it
> > > > contains garbage padding or a refcount, can it?
> > >
> > > No, that wouldn't even compile?
> > >
> > > (with the code before my messed up commit:)
> > > Mesa includes freedreno_ringbuffer.h but doesn't define HAS_ATOMIC_OPS,
> > > so fd_ringbuffer::refcnt doesn't get compiled in (but the padding is
> > > still there), so code in mesa can't use ->refcnt because the compiler
> > > wouldn't know what that is.
> > >
> > > I must be missing something, how did this ever compile?
> >
> > So, these days, mesa has it's own copy of the libdrm code,
> > libdrm_freedreno really only exists so that you can still build old
> > mesa with new libdrm.  And for a handful of small standalone utilities
> > (fdperf, and some test code I use to poke the hw standalone)..
> >
> > But the way it works is that mesa never needs to access the refcnt, it
> > mostly only needs to access cur/end (and it wants to do that in a way
> > that can be inlined, not fxn call into a different dso, since that is
> > a hot path).  The only code that accesses the refcnt is in the libdrm
> > code itself.  Hence this ugly union hack, just to make the struct the
> > same size both for mesa and for libdrm.
> >
> Ouch, I did not see the header was installed either.
> 
> Just skimmed through Mesa prior to the libdrm_freedreno merge - there
> are no references of fd_ringbuffer::refcnt.
> So a simple revert will do the job. To avoid repeating this mistake,
> we want to add an inline comment.

Reverting the commits now, and I went to add a comment and saw that
there was already one that I blindly missed last time around:

  /* This is a bit gross, but we can't use atomic_t in exported
   * headers.  OTOH, we don't need the refcnt to be publicly
   * visible.  The only reason that this struct is exported is
   * because fd_ringbuffer_emit needs to be something that can
   * be inlined for performance reasons.
   */

I just pushed the revert:
e09f327765902f3b7d31 "freedreno: revert bad freedreno/atomic_ops commits"

Emil, I'd like to release libdrm-2.4.98 today/tomorrow, I assume you're
ok with that (since you got your MODALIAS change in there as well, which
you wanted for your mesa series)?
The drmIsMaster() issue also got fixed, so I think we're good to have
a better release than the previous one :]

Should I send an MR blacklisting libdrm-2.4.97 in mesa/freedreno?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[zhoucm1]

Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is already 
rebased to latest drm-misc(kernel 5.0). You can directly use that branch.



-David


On 2019年02月19日 01:01, Koenig, Christian wrote:

Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:

Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj 
implementation?


David is the expert on that, but as far as I know that is forbidden by 
the vulkan spec.


I'm not finding anything in the vulkan spec that makes out of order 
signaling illegal.
That's why I came up with this test, just verifying that the timeline 
does not go backward in term of its payload.


Well we need to handle this case gracefully in the kernel, so it is 
still a good testcase.


Christian.



-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:

Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. 
either the same way as during CS or we abort and return an error 
message.


I think just using the same approach as during CS ist the best we 
can do.


Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:


Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't 
in-order, and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a 
warning?


Otherwise like Lionel's unexpected use cases, which easily leads to 
deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.452958]  drm_syncobj_add_point+0x102/0x160 [drm]
[   60.452965]  ? drm_syncobj_fd_to_hand

Re: [PATCH v3 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset

[Maxime Ripard]

Hi Robin,

On Wed, Feb 13, 2019 at 04:40:11PM +, Robin Murphy wrote:
> On 13/02/2019 15:41, Maxime Ripard wrote:
> > Hi Robin,
> > 
> > Thanks for your feedback!
> > 
> > On Tue, Feb 12, 2019 at 06:46:40PM +, Robin Murphy wrote:
> > > On 11/02/2019 15:02, Maxime Ripard wrote:
> > > > Now that we can express our DMA topology, rely on those property 
> > > > instead of
> > > > hardcoding an offset from the dma_addr_t which wasn't really great.
> > > > 
> > > > We still need to add some code to deal with the old DT that would lack 
> > > > that
> > > > property, but we move the offset to the DRM device dma_pfn_offset to be
> > > > able to rely on just the dma_addr_t associated to the GEM object.
> > > > 
> > > > Acked-by: Daniel Vetter 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >drivers/gpu/drm/sun4i/sun4i_backend.c | 28 
> > > > +---
> > > >1 file changed, 21 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> > > > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > > index 9e9255ee59cd..1846a1b30fea 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > > @@ -383,13 +383,6 @@ int sun4i_backend_update_layer_buffer(struct 
> > > > sun4i_backend *backend,
> > > > paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
> > > > DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
> > > > -   /*
> > > > -* backend DMA accesses DRAM directly, bypassing the system
> > > > -* bus. As such, the address range is different and the buffer
> > > > -* address needs to be corrected.
> > > > -*/
> > > > -   paddr -= PHYS_OFFSET;
> > > > -
> > > > if (fb->format->is_yuv)
> > > > return sun4i_backend_update_yuv_buffer(backend, fb, 
> > > > paddr);
> > > > @@ -835,6 +828,27 @@ static int sun4i_backend_bind(struct device *dev, 
> > > > struct device *master,
> > > > dev_set_drvdata(dev, backend);
> > > > spin_lock_init(&backend->frontend_lock);
> > > > +   if (of_find_property(dev->of_node, "interconnects", NULL)) {
> > > > +   /*
> > > > +* This assume we have the same DMA constraints for all 
> > > > our the
> > > > +* devices in our pipeline (all the backends, but also 
> > > > the
> > > > +* frontends). This sounds bad, but it has always been 
> > > > the case
> > > > +* for us, and DRM doesn't do per-device allocation 
> > > > either, so
> > > > +* we would need to fix DRM first...
> > > > +*/
> > > > +   ret = of_dma_configure(drm->dev, dev->of_node, true);
> > > 
> > > It would be even nicer if we could ensure that drm->dev originates from a 
> > > DT
> > > node which has the appropriate interconnects property itself, such that we
> > > can assume it's already configured correctly.
> > 
> > The thing is drm->dev comes from a node in the DT that is a virtual
> > node, and therefore doesn't have any resources attached, so I'm not
> > sure we have any other way, unfortunately.
> 
> Right, I appreciate that it may not be feasible to swizzle drm->dev for one
> of the 'real' component devices, but what I was also thinking was that since
> the virtual device node effectively represents the aggregation of the other
> component devices, we could just say that it also has to have its own link
> to the MBUS interconnect (with the ID of the pipeline entrypoint it's
> associated with, I guess). That ought to be enough to get dma_configure() to
> do the job, and in fairness is no *less* accurate a description of the
> hardware, even if might look a little funky to some.

That virtual device however can work with up to 4 devices that can
perform DMA operations, all of them going through a different port of
the MBUS controller that can account for DMA usage on a per-master
basis.

Eventually, we should support that feature as well, but the point is
that from a DT point of view, there's not a single point of DMA access
for that particular device but more likely 2-4 points, each with a
different argument to the phandle.

We could of course have a hack and use only one of them, but that
would be less accurate than what we currently have. Plus, this is
really due to a restriction on the DRM side, that could change in the
future (even though it's unlikely). Fixing that restriction would make
that property completely useless, confusing and wrong from an hardware
PoV.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH] drm/doc: document recommended component helper usage

[Daniel Vetter]

On Tue, Feb 12, 2019 at 05:46:15PM +0100, Daniel Vetter wrote:
> Now that component has docs it's worth spending a few words and
> hyperlinks on recommended best practices in drm.
> 
> v2: Add another item that component shouldn't be preferred over
> drm_bridge/panel and similar subsystems already providing specialized
> support for specific components (Laurent). Also convert to bullet
> list.
> 
> Cc: Laurent Pinchart 
> Cc: Russell King - ARM Linux admin 
> Signed-off-by: Daniel Vetter 

Merged with Maxime's irc r-b.
-Daniel

> ---
>  Documentation/driver-api/component.rst |  2 ++
>  Documentation/gpu/drm-internals.rst|  5 +
>  drivers/gpu/drm/drm_drv.c  | 25 +
>  3 files changed, 32 insertions(+)
> 
> diff --git a/Documentation/driver-api/component.rst 
> b/Documentation/driver-api/component.rst
> index 2da4a8f20607..57e37590733f 100644
> --- a/Documentation/driver-api/component.rst
> +++ b/Documentation/driver-api/component.rst
> @@ -1,3 +1,5 @@
> +.. _component:
> +
>  ==
>  Component Helper for Aggregate Drivers
>  ==
> diff --git a/Documentation/gpu/drm-internals.rst 
> b/Documentation/gpu/drm-internals.rst
> index 3ae23a5454ac..966bd2d9f0cc 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -93,6 +93,11 @@ Device Instance and Driver Handling
>  Driver Load
>  ---
>  
> +Component Helper Usage
> +~~
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_drv.c
> +   :doc: component helper usage recommendations
>  
>  IRQ Helper Library
>  ~~
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4f70cf68112f..43825a888e67 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -456,6 +456,31 @@ static void drm_fs_inode_free(struct inode *inode)
>   }
>  }
>  
> +/**
> + * DOC: component helper usage recommendations
> + *
> + * DRM drivers that drive hardware where a logical device consists of a pile 
> of
> + * independent hardware blocks are recommended to use the :ref:`component 
> helper
> + * library`. For consistency and better options for code reuse the
> + * following guidelines apply:
> + *
> + *  - The entire device initialization procedure should be run from the
> + *&component_master_ops.master_bind callback, starting with 
> drm_dev_init(),
> + *then binding all components with component_bind_all() and finishing 
> with
> + *drm_dev_register().
> + *
> + *  - The opaque pointer passed to all components through 
> component_bind_all()
> + *should point at &struct drm_device of the device instance, not some 
> driver
> + *specific private structure.
> + *
> + *  - The component helper fills the niche where further standardization of
> + *interfaces is not practical. When there already is, or will be, a
> + *standardized interface like &drm_bridge or &drm_panel, providing its 
> own
> + *functions to find such components at driver load time, like
> + *drm_of_find_panel_or_bridge(), then the component helper should not be
> + *used.
> + */
> +
>  /**
>   * drm_dev_init - Initialise new DRM device
>   * @dev: DRM device
> -- 
> 2.20.1
> 

-- 
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 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #13 from Zdenek  ---
I get hard lock during LibreOffice start after this workaround. Nothing
interesting in logs can be found.

-- 
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 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Lionel Landwerlin]

Thanks David,

Will give this a go!

-Lionel

On 19/02/2019 10:46, zhoucm1 wrote:


Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is 
already rebased to latest drm-misc(kernel 5.0). You can directly use 
that branch.



-David


On 2019年02月19日 01:01, Koenig, Christian wrote:

Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:

Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj 
implementation?


David is the expert on that, but as far as I know that is forbidden 
by the vulkan spec.


I'm not finding anything in the vulkan spec that makes out of order 
signaling illegal.
That's why I came up with this test, just verifying that the 
timeline does not go backward in term of its payload.


Well we need to handle this case gracefully in the kernel, so it is 
still a good testcase.


Christian.



-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:

Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. 
either the same way as during CS or we abort and return an error 
message.


I think just using the same approach as during CS ist the best we 
can do.


Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:


Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't 
in-order, and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give 
a warning?


Otherwise like Lionel's unexpected use cases, which easily leads to 
deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  0010 DS:  ES:  CR0: 80050033
[   60.452914] CR2: 7f9d74336dd8 CR3: 00084a67e004 CR4:
003606e0
[   60.452915] DR0:  DR1:  DR2:

[   60.452915] DR3:  DR6: fffe0ff0 DR7:
0400
[   60.452916] Call Trace:
[   60.4529

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Koenig, Christian]

Hi David,

Could you have a look if it's reasonable?

Patch #1 is also something I already fixed on my local branch.

But patch #2 won't work like this.

We can't return an error from drm_syncobj_add_point() because we already 
submitted work to the hardware. And just dropping the fence like you do in the 
patch is a clearly no-go as well.

Regards,
Christian.

Am 19.02.19 um 11:46 schrieb zhoucm1:

Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is already rebased 
to latest drm-misc(kernel 5.0). You can directly use that branch.


-David

On 2019年02月19日 01:01, Koenig, Christian wrote:
Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:
Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj implementation?

David is the expert on that, but as far as I know that is forbidden by the 
vulkan spec.

I'm not finding anything in the vulkan spec that makes out of order signaling 
illegal.
That's why I came up with this test, just verifying that the timeline does not 
go backward in term of its payload.

Well we need to handle this case gracefully in the kernel, so it is still a 
good testcase.

Christian.


-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:
Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. either the 
same way as during CS or we abort and return an error message.

I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, and we 
shouldn't lead to deadlock.

Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a warning?

Otherwise like Lionel's unexpected use cases, which easily leads to deadlock.


-David

On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5655a45fc0
[   60.452913] FS:  7fdc5c459980() GS:8f569eb8()
knlGS:
[   60.452913] CS:  001

Re: [PATCH libdrm 1/3] xf86drm: dedupe `#define`s

[Emil Velikov]

On Mon, 18 Feb 2019 at 17:10, Eric Engestrom  wrote:
>
> On Wednesday, 2018-12-19 17:08:01 +, Eric Engestrom wrote:
> > Adapted from a local patch carried by DragonFlyBSD:
> > https://github.com/DragonFlyBSD/DPorts/blob/bc056f88f7e4d468d8c9751f831a47b5ae1326e3/graphics/libdrm/files/patch-xf86drm.h
> >
> > Patch is sadly uncredited (a bot authored the commit), so I can't credit
> > the author here either.
> >
> > Signed-off-by: Eric Engestrom 
>
> Ping? :)
>
Thanks - saw this before but if fell through the cracks.

> > ---
> >  xf86drm.c | 10 --
> >  xf86drm.h | 16 ++--
> >  2 files changed, 10 insertions(+), 16 deletions(-)
> >
This adds more API for not so obvious reasons. I've got a series that
resolves this by folding the duplicated code into a few trivial
helpers.
Let me see if I can pull then out from the larger series and send them out.

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

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Emil Velikov]

On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  wrote:
>
> On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  RELEASING | 27 ---
> > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/RELEASING b/RELEASING
> > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > --- a/RELEASING
> > > +++ b/RELEASING
> > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature 
> > > in question.
> > >
> > >  Follow these steps to release a new version of libdrm:
> > >
> > > -  1) Bump the version number in configure.ac and meson.build. We seem
> > > - to have settled for 2.4.x as the versioning scheme for libdrm, so
> > > - just bump the  micro version.
> > > -
> > > -  2) Run autoconf and then re-run ./configure so the build system
> > > - picks up the new version number.
> > > -
> > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > - distcheck" should result in no warnings or errors and end with a
> > > - message of the form:
> > > -
> > > -   =
> > > -   libdrm-X.Y.Z archives ready for distribution:
> > > -   libdrm-X.Y.Z.tar.gz
> > > -   libdrm-X.Y.Z.tar.bz2
> > > -   =
> > > -
> > > - Make sure that the version number reported by distcheck and in
> > > - the tarball names matches the number you bumped to in configure.ac.
> > > +  1) Bump the version number in meson.build. We seem to have settled for
> > > + 2.4.x as the versioning scheme for libdrm, so just bump the micro
> > > + version.
> > > +
> > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > + Make sure that the version number of the tarball name in
> > > + builddir/meson-dist/ matches the number you bumped to. Move that
> > > + tarball to the libdrm repo root for the release script to pick up.
> > >
> > >4) Push the updated master branch with the bumped version number:
>
> Just noticed I forgot to decrement item 4 & 5 :]
>
> > >
> > > --
> > > Cheers,
> > >   Eric
> > >
> >
> > Acked-by: Dylan Baker 
> >
> > But you should probably get someone other than just me to look at this.
>
> There is no "libdrm maintainer", which makes everyone a libdrm
> maintainer :]
>
> If nobody object, I'll push this in a few weeks (there's really no rush,
> but I want to make that move at some point, we have no reason to stay
> dependant on autotools now that we have better tools).

Must admit I'm not the biggest fan. I can see this being cool for the
maintainer, if autotools was was present on their system.
The unfortunate reality is - it's there for the foreseeable future.
If anything it makes it more annoying for those using autotools/make -
regardless if they like doing so or not.

So that's a nack from me :-\

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

Re: freedreno header uses not installed xf86atomic.h

[Emil Velikov]

On Tue, 19 Feb 2019 at 10:08, Eric Engestrom  wrote:
>
> On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> >  wrote:
> > >
> > > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom  
> > > wrote:
> > > >
> > > > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > > > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > > > > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Using libdrm-2.4.97, mesa fails to build on ARM with:
> > > > > > >
> > > > > > > [  456s] In file included from
> > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> > > > > > > [  456s]  from
> > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
> > > > > > > [  456s]  from
> > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_context.h:39,
> > > > > > > [  456s]  from
> > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_program.c:33:
> > > > > > > [  456s] /usr/include/freedreno/freedreno_ringbuffer.h:32:10: 
> > > > > > > fatal
> > > > > > > error: xf86atomic.h: No such file or directory
> > > > > > >
> > > > > > > The freedreno headers were recently modified to use xf86atomic.h:
> > > > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> > > > > > >
> > > > > >
> > > > > > oh, that union/ifdef hack was specifically to avoid this issue..
> > > > > > probably the patch removing it should be reverted.
> > > > >
> > > > > Right, I messed up with that commit, I didn't realise 
> > > > > freedreno_ringbuffer.h
> > > > > was installed. We need to remove that include.
> > > > >
> > > > > That said, I'm confused as to how freedreno_ringbuffer.h users in Mesa
> > > > > knows whether it's safe to use refcnt from that union?
> > > > > It doesn't check for HAS_ATOMIC_OPS, so it can't know whether it
> > > > > contains garbage padding or a refcount, can it?
> > > >
> > > > No, that wouldn't even compile?
> > > >
> > > > (with the code before my messed up commit:)
> > > > Mesa includes freedreno_ringbuffer.h but doesn't define HAS_ATOMIC_OPS,
> > > > so fd_ringbuffer::refcnt doesn't get compiled in (but the padding is
> > > > still there), so code in mesa can't use ->refcnt because the compiler
> > > > wouldn't know what that is.
> > > >
> > > > I must be missing something, how did this ever compile?
> > >
> > > So, these days, mesa has it's own copy of the libdrm code,
> > > libdrm_freedreno really only exists so that you can still build old
> > > mesa with new libdrm.  And for a handful of small standalone utilities
> > > (fdperf, and some test code I use to poke the hw standalone)..
> > >
> > > But the way it works is that mesa never needs to access the refcnt, it
> > > mostly only needs to access cur/end (and it wants to do that in a way
> > > that can be inlined, not fxn call into a different dso, since that is
> > > a hot path).  The only code that accesses the refcnt is in the libdrm
> > > code itself.  Hence this ugly union hack, just to make the struct the
> > > same size both for mesa and for libdrm.
> > >
> > Ouch, I did not see the header was installed either.
> >
> > Just skimmed through Mesa prior to the libdrm_freedreno merge - there
> > are no references of fd_ringbuffer::refcnt.
> > So a simple revert will do the job. To avoid repeating this mistake,
> > we want to add an inline comment.
>
> Reverting the commits now, and I went to add a comment and saw that
> there was already one that I blindly missed last time around:
>
>   /* This is a bit gross, but we can't use atomic_t in exported
>* headers.  OTOH, we don't need the refcnt to be publicly
>* visible.  The only reason that this struct is exported is
>* because fd_ringbuffer_emit needs to be something that can
>* be inlined for performance reasons.
>*/
>
> I just pushed the revert:
> e09f327765902f3b7d31 "freedreno: revert bad freedreno/atomic_ops commits"
>
> Emil, I'd like to release libdrm-2.4.98 today/tomorrow, I assume you're
> ok with that (since you got your MODALIAS change in there as well, which
> you wanted for your mesa series)?
> The drmIsMaster() issue also got fixed, so I think we're good to have
> a better release than the previous one :]
>
> Should I send an MR blacklisting libdrm-2.4.97 in mesa/freedreno?
Sounds great, thanks!

I'll stuck with the original releasing procedure.

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

[PATCH] drm/imx: fix resource leak of struct drm_display_mode mode

[Colin King]

From: Colin Ian King 

Currently when the call to of_get_drm_display_mode fails the error return
path does not free an earlier allocated struct drm_display_mode, causing
a memory leak. Fix this by kfree'ing mode before returning.

Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code from 
of_get_drm_display_mode()")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/imx/parallel-display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index 1a76de1e8e7b..10eb70577f76 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -69,8 +69,10 @@ static int imx_pd_connector_get_modes(struct drm_connector 
*connector)
ret = of_get_drm_display_mode(np, &imxpd->mode,
  &imxpd->bus_flags,
  OF_USE_NATIVE_MODE);
-   if (ret)
+   if (ret) {
+   kfree(mode);
return ret;
+   }
 
drm_mode_copy(mode, &imxpd->mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
-- 
2.20.1

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

Re: [PULL] topic/mei-hdcp

[Greg KH]

On Tue, Feb 19, 2019 at 08:55:27AM +0100, Daniel Vetter wrote:
> Hi all,
> 
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
> 
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
> 
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
> 
> Joonas, please pull into drm-intel-next-queued so I can apply the i915
> hdcp patches.
> 
> Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
> into drivers-misc:
> - You pull this topic pull and then apply the mei-hdcp patches on top in
>   char-misc-next.
> - I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
>   to_mei_cl_device for mei client devices drivers") and then apply all the
>   mei-hdcp stuff into a new topic branch.
> 
> I think 2nd option would be better, allows us to integration test easier,
> and we'll have a topic branch in case we need a fixup spanning mei-hdcp
> and i915. Also would allow me to start merging the patches, since I think
> it's too late for 5.1.

No objection from me, pull away!

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

[Bug 109650] [amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x [bisected]

[bugzilla-daemon]

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

--- Comment #1 from tempel.jul...@gmail.com ---
I can confirm this with RX 580, /sys/kernel/debug/dri/0/amdgpu_pm_info also
shows a constant GPU usage of 100%.

-- 
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 libdrm] RELEASING: update instructions to use meson instead of autotools

[Daniel Vetter]

On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov  wrote:
>
> On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  wrote:
> >
> > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > Signed-off-by: Eric Engestrom 
> > > > ---
> > > >  RELEASING | 27 ---
> > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/RELEASING b/RELEASING
> > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > --- a/RELEASING
> > > > +++ b/RELEASING
> > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature 
> > > > in question.
> > > >
> > > >  Follow these steps to release a new version of libdrm:
> > > >
> > > > -  1) Bump the version number in configure.ac and meson.build. We seem
> > > > - to have settled for 2.4.x as the versioning scheme for libdrm, so
> > > > - just bump the  micro version.
> > > > -
> > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > - picks up the new version number.
> > > > -
> > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > - distcheck" should result in no warnings or errors and end with a
> > > > - message of the form:
> > > > -
> > > > -   =
> > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > -   libdrm-X.Y.Z.tar.gz
> > > > -   libdrm-X.Y.Z.tar.bz2
> > > > -   =
> > > > -
> > > > - Make sure that the version number reported by distcheck and in
> > > > - the tarball names matches the number you bumped to in 
> > > > configure.ac.
> > > > +  1) Bump the version number in meson.build. We seem to have settled 
> > > > for
> > > > + 2.4.x as the versioning scheme for libdrm, so just bump the micro
> > > > + version.
> > > > +
> > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > + Make sure that the version number of the tarball name in
> > > > + builddir/meson-dist/ matches the number you bumped to. Move that
> > > > + tarball to the libdrm repo root for the release script to pick up.
> > > >
> > > >4) Push the updated master branch with the bumped version number:
> >
> > Just noticed I forgot to decrement item 4 & 5 :]
> >
> > > >
> > > > --
> > > > Cheers,
> > > >   Eric
> > > >
> > >
> > > Acked-by: Dylan Baker 
> > >
> > > But you should probably get someone other than just me to look at this.
> >
> > There is no "libdrm maintainer", which makes everyone a libdrm
> > maintainer :]
> >
> > If nobody object, I'll push this in a few weeks (there's really no rush,
> > but I want to make that move at some point, we have no reason to stay
> > dependant on autotools now that we have better tools).
>
> Must admit I'm not the biggest fan. I can see this being cool for the
> maintainer, if autotools was was present on their system.
> The unfortunate reality is - it's there for the foreseeable future.
> If anything it makes it more annoying for those using autotools/make -
> regardless if they like doing so or not.
>
> So that's a nack from me :-\

Not really following what's the downside is of using meson to cut the
release tarball? Resulting tarball should still be able to build fine
with automake. If the concern is that automake will bitrot, then I
think a much better solution is to add a few automake targets to the
gitlab ci autobuilder stuff. That's what we've done for igt at least,
works neatly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] dt-bindings: panel: Add Ilitek ILI9341 panel documentation

[Josef Lusticky]

---
 .../bindings/display/panel/ilitek,ili9341.txt | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
new file mode 100644
index ..4e0e483bc12e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
@@ -0,0 +1,33 @@
+Ilitek ILI9341 TFT panel driver with SPI control bus
+
+This is a driver for 240x320 TFT panels with parallel RGB color input.
+
+Required properties:
+  - compatible: "displaytech,dt024ctft", "ilitek,ili9341"
+  - backlight: phandle of the backlight device attached to the panel
+
+Optional properties:
+  - dc-gpios: a GPIO spec for the Data/Command pin, see gpio/gpio.txt
+  - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
+
+The panel must obey the rules for a SPI slave device as specified in
+spi/spi-bus.txt
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+
+panel@0 {
+   compatible = "displaytech,dt024ctft", "ilitek,ili9341";
+   reg = <0>;
+   backlight = <&backlight>;
+   dc-gpios = <&pio 4 9 GPIO_ACTIVE_HIGH>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <&display_out>;
+   };
+   };
+};
-- 
2.20.1

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

[PATCH 1/2] drm/panel: Add Ilitek ILI9341 parallel RGB panel driver

[Josef Lusticky]

---
 MAINTAINERS  |   6 +
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 320 +++
 4 files changed, 334 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

diff --git a/MAINTAINERS b/MAINTAINERS
index df5668bc1c88..ec366473174b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4800,6 +4800,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
 F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: Josef Lusticky 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+F: Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
+
 DRM DRIVER FOR HX8357D PANELS
 M: Eric Anholt 
 T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e070153ef21..0e2ceea5009a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,6 +46,13 @@ config DRM_PANEL_ILITEK_IL9322
  Say Y here if you want to enable support for Ilitek IL9322
  QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
 
+config DRM_PANEL_ILITEK_IL9341
+   tristate "Ilitek ILI9341 240x320 panels"
+   depends on OF && SPI
+   help
+ Say Y here if you want to enable support for Ilitek IL9341
+ QVGA (240x320) RGB panel.
+
 config DRM_PANEL_ILITEK_ILI9881C
tristate "Ilitek ILI9881C-based panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e7ab71968bbf..1df564018bc4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_IL9341) += panel-ilitek-ili9341.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
new file mode 100644
index ..51ed03140f8d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Ilitek ILI9341 drm_panel driver
+ * 240RGBx320 dots resolution TFT LCD display
+ *
+ * This driver support the following panel configurations:
+ * - 18-bit parallel RGB interface
+ * - 8-bit SPI with Data/Command GPIO
+ *
+ * Copyright (C) 2019 Josef Lusticky 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* ILI9341 extended register set */
+#define ILI9341_IFMODE 0xB0 // clock polarity
+#define ILI9341_IFCTL  0xF6 // interface conrol
+#define ILI9341_PGAMCTRL   0xE0 // positive gamma control
+#define ILI9341_NGAMCTRL   0xE1 // negative gamma control
+
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+/**
+ * struct ili9341_config - the display specific configuration
+ * @width_mm: physical panel width [mm]
+ * @height_mm: physical panel height [mm]
+ */
+struct ili9341_config {
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct ili9341 {
+   const struct ili9341_config *conf;
+   struct drm_panel panel;
+   struct spi_device *spi;
+   struct backlight_device *backlight;
+   struct gpio_desc *dc_gpio;
+   struct gpio_desc *reset_gpio;
+};
+
+static inline struct ili9341 *panel_to_ili9341(struct drm_panel *panel)
+{
+   return container_of(panel, struct ili9341, panel);
+}
+
+static int ili9341_spi_write_command(struct ili9341 *ili, u8 cmd)
+{
+   struct spi_transfer xfer = {
+   .tx_buf = &cmd,
+   .bits_per_word = 8,
+   .len = 1
+   };
+   struct spi_message msg;
+   spi_message_init(&msg);
+   spi_message_add_tail(&xfer, &msg);
+
+   gpiod_set_value(ili->dc_gpio, 0);
+
+   return spi_sync(ili->spi, &msg);
+}
+
+static int ili9341_spi_write_data(struct ili9341 *ili, u8 *data, size_t size)
+{
+   struct spi_transfer xfer = {
+   .tx_buf = data,
+   .bits_per_word = 8,
+   .len = size
+   };
+
+   struct spi_message msg;
+   spi_message_init(&msg);
+   spi_message_add_tail(&xfer, &msg);
+
+   gpiod_set_value(ili->dc_gpio, 1);
+
+   return spi_sync(ili->spi, &msg);
+}
+
+#define ili9341_spi_write(ili, cmd, data...) \
+({ \
+   u8 d[] = { data }; \
+   ili9341_spi_write_command(ili, cmd); \
+ 

[PATCH 0/2] Add DRM panel driver for Ilitek ILI9341 based panels in parallel RGB mode

[Josef Lusticky]

These patches add panel driver for ili9341-based panels in parallel RGB mode.
The driver was developed for DispleyTech DT024CTFT LCD panel [1] which features 
ILI9341 chip [2].
The driver was tested on the Allwinner A13 (sun5i) platform.

The driver supports 240x320 pixel resolution with 18-bit RGB (6 wires per color)
and SPI control bus with Data/Command GPIO pin.

The Data/Command GPIO is optional, however at the moment the driver requires it:
The display itself is capable of 9-bit SPI without the Data/Command GPIO.
Support for such configuration can be added later to the driver.

Optional HW reset gpio can be specified, otherwise SW reset command is used
during the initialization.

The ILI9341 displays have two command sets:
Level 1 conforms to MIPI specs
Level 2 is outside the MIPI specs - custom defines are used in the driver

The ILI9341 supports various RGB modes (e.g. NVSYNC, DE_LOW, clock freq, etc.),
however values that are presented in the ILI9341 datasheet [2] are used
by the driver in struct drm_display_mode.


General note on ILI9341-based displays:
The ILI9341 chip can be used in parallel RGB with SPI control
or in SPI only mode where the image data itself is also transferred via SPI.
This driver supports parallel RGB displays - it works with displays wired with 
18-bit RGB input,
it does not support SPI data mode (i.e. Multi-inno mi0283qt or Adafruit 
yx240qv29 are not supported by this driver).
The SPI data mode is naturally much slower than the parallel RGB mode.

General note on DisplayTech DT024CTFT panel:
The panel supports different configuation options (18/16/6-bit RGB or 9/8-bit 
SPI) depending on the IM[0:3] wiring.
To keep this patch small for reveiw, at the moment only 18-bit RGB mode and 
8-bit SPI with Data/Command GPIO
is supported by this driver.


I kindly ask you for a patch review.

Links to datasheet:
[1] 
https://www.displaytech-us.com/sites/default/files/display-data-sheet/DT024CTFT-v10_0.pdf
[2] https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

Best regards,
Josef Lusticky

Josef Lusticky (2):
  drm/panel: Add Ilitek ILI9341 panel driver
  dt-bindings: panel: Add Ilitek ILI9341 panel documentation

 .../bindings/display/panel/ilitek,ili9341.txt |  33 ++
 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |   7 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c  | 320 ++
 5 files changed, 367 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

-- 
2.20.1

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

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Joonas Lahtinen]

+ dri-devel mailing list, especially for the buddy allocator part

Quoting Dave Airlie (2019-02-15 02:47:07)
> On Fri, 15 Feb 2019 at 00:57, Matthew Auld  wrote:
> >
> > In preparation for upcoming devices with device local memory, introduce the
> > concept of different memory regions, and a simple buddy allocator to manage
> > them.
> 
> This is missing the information on why it's not TTM.
> 
> Nothing against extending i915 gem off into doing stuff we already
> have examples off in tree, but before you do that it would be good to
> have a why we can't use TTM discussion in public.

Glad that you asked. It's my fault that it was not included in
the cover letter. I anticipated the question, but was travelling
for a couple of days at the time this was sent. I didn't want
to write a hasty explanation and then disappear, leaving others to
take the heat.

So here goes the less-hasty version:

We did an analysis on the effort needed vs benefit gained of using
TTM when this was started initially. The conclusion was that we
already share the interesting bits of code through core DRM, really.

Re-writing the memory handling to TTM would buy us more fine-grained
locking. But it's more a trait of rewriting the memory handling with
the information we have learned, than rewriting it to use TTM :)

And further, we've been getting rid of struct_mutex at a steady phase
in the past years, so we have a clear path to the fine-grained locking
already in the not-so-distant future. With all this we did not see
much gained from converting over, as the code sharing is already
substantial.

We also wanted to have the buddy allocator instead of a for loop making
drm_mm allocations to make sure we can keep the memory fragmentation
at bay. The intent is to move the buddy allocator to core DRM, to the
benefit of all the drivers, if there is interest from community. It has
been written as a strictly separate component with that in mind.

And if you take the buddy allocator out of the patch set, the rest is
mostly just vfuncing things up to be able to have different backing
storages for objects. We took the opportunity to move over to the more
valgrind friendly mmap while touching things, but it's something we
have been contemplating anyway. And yeah, loads of selftests.

That's really all that needed adding, and most of it is internal to
i915 and not to do with uAPI. This means porting over an userspace
driver doesn't require a substantial rewrite, but adding new a few
new IOCTLs to set the preferred backing storage placements.

All the previous GEM abstractions keep applying, so we did not see
a justification to rewrite the kernel driver and userspace drivers.
It would have just to made things look like TTM, when we already
have the important parts of the code shared with TTM drivers
behind the GEM interfaces which all our drivers sit on top of.

I hope this answered the question to some extent, and feel free to
ask more details or provide suggestion to what we could have done
differently.

Regards, Joonas

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

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Eric Engestrom]

On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov  
> wrote:
> >
> > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  
> > wrote:
> > >
> > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > Signed-off-by: Eric Engestrom 
> > > > > ---
> > > > >  RELEASING | 27 ---
> > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > >
> > > > > diff --git a/RELEASING b/RELEASING
> > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > --- a/RELEASING
> > > > > +++ b/RELEASING
> > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > feature in question.
> > > > >
> > > > >  Follow these steps to release a new version of libdrm:
> > > > >
> > > > > -  1) Bump the version number in configure.ac and meson.build. We seem
> > > > > - to have settled for 2.4.x as the versioning scheme for libdrm, 
> > > > > so
> > > > > - just bump the  micro version.
> > > > > -
> > > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > > - picks up the new version number.
> > > > > -
> > > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > > - distcheck" should result in no warnings or errors and end with a
> > > > > - message of the form:
> > > > > -
> > > > > -   =
> > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > -   =
> > > > > -
> > > > > - Make sure that the version number reported by distcheck and in
> > > > > - the tarball names matches the number you bumped to in 
> > > > > configure.ac.
> > > > > +  1) Bump the version number in meson.build. We seem to have settled 
> > > > > for
> > > > > + 2.4.x as the versioning scheme for libdrm, so just bump the 
> > > > > micro
> > > > > + version.
> > > > > +
> > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > + Make sure that the version number of the tarball name in
> > > > > + builddir/meson-dist/ matches the number you bumped to. Move that
> > > > > + tarball to the libdrm repo root for the release script to pick 
> > > > > up.
> > > > >
> > > > >4) Push the updated master branch with the bumped version number:
> > >
> > > Just noticed I forgot to decrement item 4 & 5 :]
> > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >   Eric
> > > > >
> > > >
> > > > Acked-by: Dylan Baker 
> > > >
> > > > But you should probably get someone other than just me to look at this.
> > >
> > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > maintainer :]
> > >
> > > If nobody object, I'll push this in a few weeks (there's really no rush,
> > > but I want to make that move at some point, we have no reason to stay
> > > dependant on autotools now that we have better tools).
> >
> > Must admit I'm not the biggest fan. I can see this being cool for the
> > maintainer, if autotools was was present on their system.
> > The unfortunate reality is - it's there for the foreseeable future.
> > If anything it makes it more annoying for those using autotools/make -
> > regardless if they like doing so or not.
> >
> > So that's a nack from me :-\
> 
> Not really following what's the downside is of using meson to cut the
> release tarball? Resulting tarball should still be able to build fine
> with automake. If the concern is that automake will bitrot, then I
> think a much better solution is to add a few automake targets to the
> gitlab ci autobuilder stuff. That's what we've done for igt at least,
> works neatly.

Agreed, and to me using meson has a huge upside: it packages what's in git,
unlike autotools which packages whatever was on your machine at the time.
This makes it much less likely to accidentally send files with local
modifications or add/remove files without meaning to.

Like I said though, there's no rush, so let's make sure issues are
addressed first.

I'll add a CI job to run `make distcheck` on releases (libdrm-* tags).

Emil, would that be enough, or was your concern something else?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: freedreno header uses not installed xf86atomic.h

[Eric Engestrom]

On Tuesday, 2019-02-19 11:56:21 +, Emil Velikov wrote:
> On Tue, 19 Feb 2019 at 10:08, Eric Engestrom  wrote:
> >
> > On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> > >  wrote:
> > > >
> > > > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom 
> > > >  wrote:
> > > > >
> > > > > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > > > > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > > > > > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Using libdrm-2.4.97, mesa fails to build on ARM with:
> > > > > > > >
> > > > > > > > [  456s] In file included from
> > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> > > > > > > > [  456s]  from
> > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
> > > > > > > > [  456s]  from
> > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_context.h:39,
> > > > > > > > [  456s]  from
> > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_program.c:33:
> > > > > > > > [  456s] /usr/include/freedreno/freedreno_ringbuffer.h:32:10: 
> > > > > > > > fatal
> > > > > > > > error: xf86atomic.h: No such file or directory
> > > > > > > >
> > > > > > > > The freedreno headers were recently modified to use 
> > > > > > > > xf86atomic.h:
> > > > > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> > > > > > > >
> > > > > > >
> > > > > > > oh, that union/ifdef hack was specifically to avoid this issue..
> > > > > > > probably the patch removing it should be reverted.
> > > > > >
> > > > > > Right, I messed up with that commit, I didn't realise 
> > > > > > freedreno_ringbuffer.h
> > > > > > was installed. We need to remove that include.
> > > > > >
> > > > > > That said, I'm confused as to how freedreno_ringbuffer.h users in 
> > > > > > Mesa
> > > > > > knows whether it's safe to use refcnt from that union?
> > > > > > It doesn't check for HAS_ATOMIC_OPS, so it can't know whether it
> > > > > > contains garbage padding or a refcount, can it?
> > > > >
> > > > > No, that wouldn't even compile?
> > > > >
> > > > > (with the code before my messed up commit:)
> > > > > Mesa includes freedreno_ringbuffer.h but doesn't define 
> > > > > HAS_ATOMIC_OPS,
> > > > > so fd_ringbuffer::refcnt doesn't get compiled in (but the padding is
> > > > > still there), so code in mesa can't use ->refcnt because the compiler
> > > > > wouldn't know what that is.
> > > > >
> > > > > I must be missing something, how did this ever compile?
> > > >
> > > > So, these days, mesa has it's own copy of the libdrm code,
> > > > libdrm_freedreno really only exists so that you can still build old
> > > > mesa with new libdrm.  And for a handful of small standalone utilities
> > > > (fdperf, and some test code I use to poke the hw standalone)..
> > > >
> > > > But the way it works is that mesa never needs to access the refcnt, it
> > > > mostly only needs to access cur/end (and it wants to do that in a way
> > > > that can be inlined, not fxn call into a different dso, since that is
> > > > a hot path).  The only code that accesses the refcnt is in the libdrm
> > > > code itself.  Hence this ugly union hack, just to make the struct the
> > > > same size both for mesa and for libdrm.
> > > >
> > > Ouch, I did not see the header was installed either.
> > >
> > > Just skimmed through Mesa prior to the libdrm_freedreno merge - there
> > > are no references of fd_ringbuffer::refcnt.
> > > So a simple revert will do the job. To avoid repeating this mistake,
> > > we want to add an inline comment.
> >
> > Reverting the commits now, and I went to add a comment and saw that
> > there was already one that I blindly missed last time around:
> >
> >   /* This is a bit gross, but we can't use atomic_t in exported
> >* headers.  OTOH, we don't need the refcnt to be publicly
> >* visible.  The only reason that this struct is exported is
> >* because fd_ringbuffer_emit needs to be something that can
> >* be inlined for performance reasons.
> >*/
> >
> > I just pushed the revert:
> > e09f327765902f3b7d31 "freedreno: revert bad freedreno/atomic_ops commits"
> >
> > Emil, I'd like to release libdrm-2.4.98 today/tomorrow, I assume you're
> > ok with that (since you got your MODALIAS change in there as well, which
> > you wanted for your mesa series)?
> > The drmIsMaster() issue also got fixed, so I think we're good to have
> > a better release than the previous one :]
> >
> > Should I send an MR blacklisting libdrm-2.4.97 in mesa/freedreno?
> Sounds great, thanks!

Actually, as far as I can tell Mesa doesn't use libdrm_freedreno (anymore)?
The issue will only happen with old mesa + libdrm 2.4.97, so there's
nothing we can do? Can you confirm R

Re: [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support

[Rob Herring]

On Mon, Feb 18, 2019 at 1:07 PM Vasily Khoruzhick  wrote:
>
> On Mon, Feb 18, 2019 at 10:33 AM Rob Herring  wrote:
> >
> > On Thu, Feb 14, 2019 at 09:09:56PM -0800, Vasily Khoruzhick wrote:
> > > This commit adds support for the NewEast Optoelectronics CO., LTD
> > > WJFH116008A 11.6" 1920x1080 TFT LCD panel.
> > >
> > > Signed-off-by: Vasily Khoruzhick 
> > > ---
> > >  .../display/panel/neweast,wjfh116008a.txt |  7 
> > >  drivers/gpu/drm/panel/panel-simple.c  | 39 +++
> > >  2 files changed, 46 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt 
> > > b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> > > new file mode 100644
> > > index ..d76579f9f55e
> > > --- /dev/null
> > > +++ 
> > > b/Documentation/devicetree/bindings/display/panel/neweast,wjfh116008a.txt
> > > @@ -0,0 +1,7 @@
> > > +NewEast Optoelectronics CO., LTD WJFH116008A 11.6" 1920x1080 TFT LCD 
> > > panel
> > > +
> > > +Required properties:
> > > +- compatible: should be "neweast,wjfh116008a"
> > > +
> > > +This binding is compatible with the simple-panel binding, which is 
> > > specified
> > > +in simple-panel.txt in this directory.
> >
> > We already established that this goes thru a standard eDP connector. We
> > should describe that and everything associated with it.
>
> I believe using eDP connector binding wouldn't help much in my case
> and it won't improve accuracy of hardware description while adding
> unnecessary code duplication (edp-connector will be pretty much
> simple-panel).
>
> Since currently there're no standalone connector drivers, implementing
> one requires significant refactoring of the code that I'm not
> familiar.

I'm not talking about drivers. I'm talking about bindings. Those are
not necessarily 1-1. There's no reason the simple panel driver can't
have an 'edp-connector' entry.

Also, since you have EDID, you should be using that for timing data
IMO, and the binding needs to have enough information to support that.
It may if DP-aux comes from the bridge chip or it may not if you need
to describe that connection. Again, this is independent from what
Linux chooses to do. If Linux chooses to have its own timing
information that's its choice. Another OS may choose to use EDID.

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

[PATCH][next] drm/i915/selftests: fix memory leak of 'spin'

[Colin King]

From: Colin Ian King 

There is a memory leak of 'spin' on an error return path. Fix this by
kfree'ing spin before the return.

Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/selftests/i915_gem_context.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index d00d0bb07784..cf988797bb17 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -725,8 +725,10 @@ __sseu_prepare(struct drm_i915_private *i915,
}
 
ret = igt_spinner_init(spin, i915);
-   if (ret)
+   if (ret) {
+   kfree(spin);
return ret;
+   }
 
rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
-- 
2.20.1

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

RE: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
>Ville
>Syrjälä
>Sent: Tuesday, February 19, 2019 1:37 AM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ; 
>Lankhorst,
>Maarten ; dri-devel@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
>
>On Wed, Feb 13, 2019 at 12:35:10PM +0530, Uma Shankar wrote:
>> This adds colorspace information to HDMI AVI infoframe.
>> A helper function is added to program the same.
>>
>> v2: Moved this to drm core instead of i915 driver.
>>
>> v3: Exported the helper function.
>>
>> v4: Added separate HDMI specific macro as per CTA spec.
>> This is separate from user exposed enum values. This is as per Ville's
>> suggestion.
>>
>> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
>> review comment to be clear and not to be confused with RGB.
>>
>> v6: Added bit wise macro for various fields of colorimetry for easier
>> understanding and review as per Ville's comments. Moved the same out
>> of header file to avoid any namespace issues.
>>
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 66
>++
>>  include/drm/drm_edid.h |  6 +
>>  2 files changed, 72 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 990b190..64816c0 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4924,6 +4924,72 @@ static bool is_hdmi2_sink(struct drm_connector
>> *connector)  }
>> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>>
>> +/* HDMI Colorspace Spec Definitions */
>> +#define FULL_COLORIMETRY_MASK   0x1FF
>> +#define NORMAL_COLORIMETRY_MASK 0x3
>> +#define EXTENDED_COLORIMETRY_MASK   0x7
>> +#define EXTENDED_ACE_COLORIMETRY_MASK   0xF
>> +
>> +#define C(x) ((x) << 0)
>> +#define EC(x) ((x) << 2)
>> +#define ACE(x) ((x) << 5)
>> +
>> +#define HDMI_COLORIMETRY_NO_DATA0x0
>> +#define HDMI_COLORIMETRY_SMPTE_170M_YCC (C(1) | EC(0) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_BT709_YCC  (C(2) | EC(0) | ACE(0))
>> +#define HDMI_COLORIMETRY_XVYCC_601  (C(3) | EC(0) | ACE(0))
>> +#define HDMI_COLORIMETRY_XVYCC_709  (C(3) | EC(1) | ACE(0))
>> +#define HDMI_COLORIMETRY_SYCC_601   (C(3) | EC(2) | ACE(0))
>> +#define HDMI_COLORIMETRY_OPYCC_601  (C(3) | EC(3) | ACE(0))
>> +#define HDMI_COLORIMETRY_OPRGB  (C(3) | EC(4) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_CYCC(C(3) | EC(5) | ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
>> +#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
>> +#define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) |
>ACE(0))
>> +#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) |
>ACE(1))
>> +
>> +static const u32 hdmi_colorimetry_val[] = {
>> +[DRM_MODE_COLORIMETRY_NO_DATA] =
>HDMI_COLORIMETRY_NO_DATA,
>> +[DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] =
>HDMI_COLORIMETRY_SMPTE_170M_YCC,
>> +[DRM_MODE_COLORIMETRY_BT709_YCC] =
>HDMI_COLORIMETRY_BT709_YCC,
>> +[DRM_MODE_COLORIMETRY_XVYCC_601] =
>HDMI_COLORIMETRY_XVYCC_601,
>> +[DRM_MODE_COLORIMETRY_XVYCC_709] =
>HDMI_COLORIMETRY_XVYCC_709,
>> +[DRM_MODE_COLORIMETRY_SYCC_601] =
>HDMI_COLORIMETRY_SYCC_601,
>> +[DRM_MODE_COLORIMETRY_OPYCC_601] =
>HDMI_COLORIMETRY_OPYCC_601,
>> +[DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
>> +[DRM_MODE_COLORIMETRY_BT2020_CYCC] =
>HDMI_COLORIMETRY_BT2020_CYCC,
>> +[DRM_MODE_COLORIMETRY_BT2020_RGB] =
>HDMI_COLORIMETRY_BT2020_RGB,
>> +[DRM_MODE_COLORIMETRY_BT2020_YCC] =
>HDMI_COLORIMETRY_BT2020_YCC, };
>
>Probably best to
>
>#undef C
>#undef EC
>#undef ACE
>
>here to avoid accidents.

Sure will add that. So with this fixed and DP stuff dropped, can I mark your RB 
on all the remaining 2 patches
(DP patch will get dropped). If you confirm will resend with your RB for merge.

Thanks & Regards,
Uma Shankar

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


>> +
>> +/**
>> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
>> + *   colorspace information
>> + * @frame: HDMI AVI infoframe
>> + * @conn_state: connector state
>> + */
>> +void
>> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
>> +  const struct drm_connector_state *conn_state) 
>> {
>> +u32 colorimetry_val;
>> +u32 colorimetry_index = conn_state->colorspace &
>> +FULL_COLORIMETRY_MASK;
>> +
>> +if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
>> +colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
>> +else
>> +colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
>> +
>> +frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
>> +/*
>> + * 

Re: [PATCH][next] drm/i915/selftests: fix memory leak of 'spin'

[Chris Wilson]

Quoting Colin King (2019-02-19 15:01:29)
> From: Colin Ian King 
> 
> There is a memory leak of 'spin' on an error return path. Fix this by
> kfree'ing spin before the return.
> 
> Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
> Signed-off-by: Colin Ian King 

I hope already fixed by

commit 2a4a2754039594c60b58b02b6781428a85f6d745
Author: Chris Wilson 
Date:   Fri Feb 15 19:50:10 2019 +

drm/i915/selftests: Always free spinner on __sseu_prepare error

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

RE: [Intel-gfx] [v16 2/4] drm: Add DP colorspace property

[Shankar, Uma]

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:39 AM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, 
>Ville
>; Lankhorst, Maarten 
>Subject: Re: [Intel-gfx] [v16 2/4] drm: Add DP colorspace property
>
>On Wed, Feb 13, 2019 at 12:35:09PM +0530, Uma Shankar wrote:
>> This patch adds a DP colorspace property, enabling userspace to switch
>> to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced
>> the colorspace enum to incorporate both HDMI and DP supported
>> colorspaces. Also, added a default option for colorspace.
>>
>> v3: Split the changes to have separate colorspace property for DP and
>> HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> v8: Addressed Ville's review comments and updated the colorspace macro
>> definitions.
>>
>> Signed-off-by: Uma Shankar 
>> Acked-by: Jani Nikula 
>> Reviewed-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 07d65a1..5473bea 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>>  { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
>P3_RGB_Theater" },
>> };
>>
>> +static const struct drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>> +/* DP MSA Colorimetry */
>> +{ DRM_MODE_DP_COLORIMETRY_BT601_YCC, "BT601_YCC" },
>> +{ DRM_MODE_DP_COLORIMETRY_BT709_YCC, "BT709_YCC" },
>> +{ DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" }, };
>
>I think we should postpone this patch (and the DP related bits in the previous 
>patch)
>until we have the implementation done. Ie. let's just get HDMI working 
>initially.

Sure, will drop this.

>> +
>>  /**
>>   * DOC: standard connector properties
>>   *
>> @@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
>>  ARRAY_SIZE(hdmi_colorspaces));
>>  if (!prop)
>>  return -ENOMEM;
>> +} else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
>> +   connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort) {
>> +prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
>> +"Colorspace", dp_colorspaces,
>> +ARRAY_SIZE(dp_colorspaces));
>> +
>> +if (!prop)
>> +return -ENOMEM;
>>  } else {
>>  DRM_DEBUG_KMS("Colorspace property not supported\n");
>>  return 0;
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe

[Ville Syrjälä]

On Tue, Feb 19, 2019 at 03:09:00PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf 
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, February 19, 2019 1:37 AM
> >To: Shankar, Uma 
> >Cc: intel-...@lists.freedesktop.org; Syrjala, Ville 
> >; Lankhorst,
> >Maarten ; dri-devel@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v16 3/4] drm: Add colorspace info to AVI Infoframe
> >
> >On Wed, Feb 13, 2019 at 12:35:10PM +0530, Uma Shankar wrote:
> >> This adds colorspace information to HDMI AVI infoframe.
> >> A helper function is added to program the same.
> >>
> >> v2: Moved this to drm core instead of i915 driver.
> >>
> >> v3: Exported the helper function.
> >>
> >> v4: Added separate HDMI specific macro as per CTA spec.
> >> This is separate from user exposed enum values. This is as per Ville's
> >> suggestion.
> >>
> >> v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
> >> review comment to be clear and not to be confused with RGB.
> >>
> >> v6: Added bit wise macro for various fields of colorimetry for easier
> >> understanding and review as per Ville's comments. Moved the same out
> >> of header file to avoid any namespace issues.
> >>
> >> Signed-off-by: Uma Shankar 
> >> ---
> >>  drivers/gpu/drm/drm_edid.c | 66
> >++
> >>  include/drm/drm_edid.h |  6 +
> >>  2 files changed, 72 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 990b190..64816c0 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -4924,6 +4924,72 @@ static bool is_hdmi2_sink(struct drm_connector
> >> *connector)  }
> >> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> >>
> >> +/* HDMI Colorspace Spec Definitions */
> >> +#define FULL_COLORIMETRY_MASK 0x1FF
> >> +#define NORMAL_COLORIMETRY_MASK   0x3
> >> +#define EXTENDED_COLORIMETRY_MASK 0x7
> >> +#define EXTENDED_ACE_COLORIMETRY_MASK 0xF
> >> +
> >> +#define C(x) ((x) << 0)
> >> +#define EC(x) ((x) << 2)
> >> +#define ACE(x) ((x) << 5)
> >> +
> >> +#define HDMI_COLORIMETRY_NO_DATA  0x0
> >> +#define HDMI_COLORIMETRY_SMPTE_170M_YCC   (C(1) | EC(0) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_BT709_YCC(C(2) | EC(0) | ACE(0))
> >> +#define HDMI_COLORIMETRY_XVYCC_601(C(3) | EC(0) | ACE(0))
> >> +#define HDMI_COLORIMETRY_XVYCC_709(C(3) | EC(1) | ACE(0))
> >> +#define HDMI_COLORIMETRY_SYCC_601 (C(3) | EC(2) | ACE(0))
> >> +#define HDMI_COLORIMETRY_OPYCC_601(C(3) | EC(3) | ACE(0))
> >> +#define HDMI_COLORIMETRY_OPRGB(C(3) | EC(4) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_CYCC  (C(3) | EC(5) | ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_RGB   (C(3) | EC(6) | ACE(0))
> >> +#define HDMI_COLORIMETRY_BT2020_YCC   (C(3) | EC(6) | ACE(0))
> >> +#define HDMI_COLORIMETRY_DCI_P3_RGB_D65   (C(3) | EC(7) |
> >ACE(0))
> >> +#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER   (C(3) | EC(7) |
> >ACE(1))
> >> +
> >> +static const u32 hdmi_colorimetry_val[] = {
> >> +  [DRM_MODE_COLORIMETRY_NO_DATA] =
> >HDMI_COLORIMETRY_NO_DATA,
> >> +  [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] =
> >HDMI_COLORIMETRY_SMPTE_170M_YCC,
> >> +  [DRM_MODE_COLORIMETRY_BT709_YCC] =
> >HDMI_COLORIMETRY_BT709_YCC,
> >> +  [DRM_MODE_COLORIMETRY_XVYCC_601] =
> >HDMI_COLORIMETRY_XVYCC_601,
> >> +  [DRM_MODE_COLORIMETRY_XVYCC_709] =
> >HDMI_COLORIMETRY_XVYCC_709,
> >> +  [DRM_MODE_COLORIMETRY_SYCC_601] =
> >HDMI_COLORIMETRY_SYCC_601,
> >> +  [DRM_MODE_COLORIMETRY_OPYCC_601] =
> >HDMI_COLORIMETRY_OPYCC_601,
> >> +  [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> >> +  [DRM_MODE_COLORIMETRY_BT2020_CYCC] =
> >HDMI_COLORIMETRY_BT2020_CYCC,
> >> +  [DRM_MODE_COLORIMETRY_BT2020_RGB] =
> >HDMI_COLORIMETRY_BT2020_RGB,
> >> +  [DRM_MODE_COLORIMETRY_BT2020_YCC] =
> >HDMI_COLORIMETRY_BT2020_YCC, };
> >
> >Probably best to
> >
> >#undef C
> >#undef EC
> >#undef ACE
> >
> >here to avoid accidents.
> 
> Sure will add that. So with this fixed and DP stuff dropped, can I mark your 
> RB on all the remaining 2 patches
> (DP patch will get dropped). If you confirm will resend with your RB for 
> merge.

Yeah, I think it should be good to go in.

> 
> Thanks & Regards,
> Uma Shankar
> 
> >With that
> >Reviewed-by: Ville Syrjälä 
> 
> 
> >> +
> >> +/**
> >> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
> >> + *   colorspace information
> >> + * @frame: HDMI AVI infoframe
> >> + * @conn_state: connector state
> >> + */
> >> +void
> >> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> >> +const struct drm_connector_state *conn_state) 
> >> {
> >> +  u32 colorimetry_val;
> >> +  u32 colorimetry_index = conn_sta

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Daniel Vetter]

On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov  
> > wrote:
> > >
> > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  
> > > wrote:
> > > >
> > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > Signed-off-by: Eric Engestrom 
> > > > > > ---
> > > > > >  RELEASING | 27 ---
> > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > >
> > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > --- a/RELEASING
> > > > > > +++ b/RELEASING
> > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > > feature in question.
> > > > > >
> > > > > >  Follow these steps to release a new version of libdrm:
> > > > > >
> > > > > > -  1) Bump the version number in configure.ac and meson.build. We 
> > > > > > seem
> > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > libdrm, so
> > > > > > - just bump the  micro version.
> > > > > > -
> > > > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > > > - picks up the new version number.
> > > > > > -
> > > > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > > > - distcheck" should result in no warnings or errors and end 
> > > > > > with a
> > > > > > - message of the form:
> > > > > > -
> > > > > > -   =
> > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > -   =
> > > > > > -
> > > > > > - Make sure that the version number reported by distcheck and in
> > > > > > - the tarball names matches the number you bumped to in 
> > > > > > configure.ac.
> > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > settled for
> > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump the 
> > > > > > micro
> > > > > > + version.
> > > > > > +
> > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > + Make sure that the version number of the tarball name in
> > > > > > + builddir/meson-dist/ matches the number you bumped to. Move 
> > > > > > that
> > > > > > + tarball to the libdrm repo root for the release script to 
> > > > > > pick up.
> > > > > >
> > > > > >4) Push the updated master branch with the bumped version number:
> > > >
> > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > >   Eric
> > > > > >
> > > > >
> > > > > Acked-by: Dylan Baker 
> > > > >
> > > > > But you should probably get someone other than just me to look at 
> > > > > this.
> > > >
> > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > maintainer :]
> > > >
> > > > If nobody object, I'll push this in a few weeks (there's really no rush,
> > > > but I want to make that move at some point, we have no reason to stay
> > > > dependant on autotools now that we have better tools).
> > >
> > > Must admit I'm not the biggest fan. I can see this being cool for the
> > > maintainer, if autotools was was present on their system.
> > > The unfortunate reality is - it's there for the foreseeable future.
> > > If anything it makes it more annoying for those using autotools/make -
> > > regardless if they like doing so or not.
> > >
> > > So that's a nack from me :-\
> >
> > Not really following what's the downside is of using meson to cut the
> > release tarball? Resulting tarball should still be able to build fine
> > with automake. If the concern is that automake will bitrot, then I
> > think a much better solution is to add a few automake targets to the
> > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > works neatly.
>
> Agreed, and to me using meson has a huge upside: it packages what's in git,
> unlike autotools which packages whatever was on your machine at the time.
> This makes it much less likely to accidentally send files with local
> modifications or add/remove files without meaning to.
>
> Like I said though, there's no rush, so let's make sure issues are
> addressed first.
>
> I'll add a CI job to run `make distcheck` on releases (libdrm-* tags).

I'd go with make check only. make distcheck needs all the manual
fiddling in makefile templates (EXTRA_DIST and friends) since automake
doesn't do the right thing by default like meson. If we go with meson
for making release tarballs, I don't think it makes sense to keep the
automake stuff alive.

But there's a bunch of compile-time tests in libdrm, run by ninja test
and make check, those should keep working imo, at least for 

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Dylan Baker]

Quoting Daniel Vetter (2019-02-19 07:20:12)
> On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> wrote:
> >
> > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov  
> > > wrote:
> > > >
> > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  
> > > > wrote:
> > > > >
> > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > ---
> > > > > > >  RELEASING | 27 ---
> > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > >
> > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > --- a/RELEASING
> > > > > > > +++ b/RELEASING
> > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > > > feature in question.
> > > > > > >
> > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > >
> > > > > > > -  1) Bump the version number in configure.ac and meson.build. We 
> > > > > > > seem
> > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > libdrm, so
> > > > > > > - just bump the  micro version.
> > > > > > > -
> > > > > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > > > > - picks up the new version number.
> > > > > > > -
> > > > > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > > > > - distcheck" should result in no warnings or errors and end 
> > > > > > > with a
> > > > > > > - message of the form:
> > > > > > > -
> > > > > > > -   =
> > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > -   =
> > > > > > > -
> > > > > > > - Make sure that the version number reported by distcheck and 
> > > > > > > in
> > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > configure.ac.
> > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > settled for
> > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump the 
> > > > > > > micro
> > > > > > > + version.
> > > > > > > +
> > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > + builddir/meson-dist/ matches the number you bumped to. Move 
> > > > > > > that
> > > > > > > + tarball to the libdrm repo root for the release script to 
> > > > > > > pick up.
> > > > > > >
> > > > > > >4) Push the updated master branch with the bumped version 
> > > > > > > number:
> > > > >
> > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > >   Eric
> > > > > > >
> > > > > >
> > > > > > Acked-by: Dylan Baker 
> > > > > >
> > > > > > But you should probably get someone other than just me to look at 
> > > > > > this.
> > > > >
> > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > maintainer :]
> > > > >
> > > > > If nobody object, I'll push this in a few weeks (there's really no 
> > > > > rush,
> > > > > but I want to make that move at some point, we have no reason to stay
> > > > > dependant on autotools now that we have better tools).
> > > >
> > > > Must admit I'm not the biggest fan. I can see this being cool for the
> > > > maintainer, if autotools was was present on their system.
> > > > The unfortunate reality is - it's there for the foreseeable future.
> > > > If anything it makes it more annoying for those using autotools/make -
> > > > regardless if they like doing so or not.
> > > >
> > > > So that's a nack from me :-\
> > >
> > > Not really following what's the downside is of using meson to cut the
> > > release tarball? Resulting tarball should still be able to build fine
> > > with automake. If the concern is that automake will bitrot, then I
> > > think a much better solution is to add a few automake targets to the
> > > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > > works neatly.
> >
> > Agreed, and to me using meson has a huge upside: it packages what's in git,
> > unlike autotools which packages whatever was on your machine at the time.
> > This makes it much less likely to accidentally send files with local
> > modifications or add/remove files without meaning to.
> >
> > Like I said though, there's no rush, so let's make sure issues are
> > addressed first.
> >
> > I'll add a CI job to run `make distcheck` on releases (libdrm-* tags).
> 
> I'd go with make check only. make distcheck needs all the manual
> fiddling in makefile templates (EXTRA_DIST and friends) s

Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Vasily Khoruzhick]

On Tue, Feb 19, 2019 at 12:56 AM Maxime Ripard
 wrote:
>
> On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 18, 2019 at 10:26 AM Rob Herring  wrote:
> > >
> > > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > > > Validate the clock rate") prevents some panel and bridges from working 
> > > > with
> > > > sun4i driver.
> > >
> > > Sounds lile a regression that should be reverted. The fix is not a
> > > backwards compatible change either.
> >
> > anx6345 driver isn't mainlined yet and I'm not sure if this change
> > breaks any mainlined boards. So likely there's not enough
> > justification to revert it.
> >
> > > > Unfortunately, dotclock frequency for some modes are not achievable on
> > > > sunxi hardware, and there's a slight deviation in rate returned by
> > > > clk_round_rate(), so they fail this check.
> > > >
> > > > Experiments show that panels and bridges work fine with this slight
> > > > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > > > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works 
> > > > just
> > > > fine.
> > > >
> > > > This patch adds DT property to disable strict clock rate check
> > > >
> > > > Signed-off-by: Vasily Khoruzhick 
> > > > ---
> > > >  .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 2 ++
> > > >  drivers/gpu/drm/sun4i/sun4i_rgb.c| 5 +
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 3 +++
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.h   | 1 +
> > > >  4 files changed, 11 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > index f426bdb42f18..18c8b053a28d 100644
> > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > @@ -63,6 +63,8 @@ Required properties:
> > > >  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > >  first port should be the input endpoint. The second should be the
> > > >  output, usually to an HDMI connector.
> > > > +  - no-strict-clock-check: don't reject timings if exact dot clock 
> > > > can't be
> > > > +reached.
> > >
> > > This should be the default IMO. Most panels are a single timing, so if
> > > we reject it the fallback no display?
> >
> > As far as I remember the change was introduced to reject some modes
> > for which dotclock can't be reached when driver is used with VGA
> > bridge. So if we make it default it'll break boards with VGA bridge
> > and old DT.
> >
> > > I thought we had some mechanism already to allow some range of
> > > frequencies. I think the chromeos guys needed something IIRC.
> >
> > You can specify frequency range for panels, but there's nothing for
> > bridges. In my case EDID doesn't specify clock tolerance.
>
> I gave it some more though, and came up with the following patch. The
> basic idea is to leave the boundary check for the bridges that will
> have EDID and we need to filter out the modes that have no chance of
> being supported. The tolerancy used is the one defined in VESA specs,
> but I added a module parameter if you wanted to tune that.
>
> And finally, since most of our panels are single timings without any
> tolerancy, we just try our best in this case and that's it, while
> leaving the door open to support display_timings and being able to do
> more once we have an idea of what the tolerancies are.
>
> If that works for you, I'll submit it.

Maxime, thanks for your patch but  it doesn't work for me. Pinebook
needs 1% tolerance. Having it as a module parameter means that no
distro will be able to boot on Pinebook out of the box.

> Maxime
>
> --- >8 ---
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index f4a22689eb54..0460146aab75 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -43,6 +43,25 @@ drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
> encoder);
>  }
>
> +static inline struct drm_connector *
> +sun4i_rgb_get_connector_from_encoder(const struct drm_encoder *encoder)
> +{
> +   struct drm_connector *connector = NULL, *tmp;
> +   struct drm_connector_list_iter iter;
> +
> +   drm_connector_list_iter_begin(encoder->dev, &iter);
> +   drm_for_each_connector_iter(tmp, &iter)
> +   if (tmp->encoder == encoder) {
> +   connector = tmp;
> +   goto out;
> +   }
> +
> +out:
> +   drm_connector_list_iter_end(&iter);
> +
> +   return connector;
> +}
> +
>  static int sun4i_rgb_get_modes(struct drm_connector *connector)
>  {
> struct sun4i_rg

Re: freedreno header uses not installed xf86atomic.h

[Rob Clark]

On Tue, Feb 19, 2019 at 9:07 AM Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-19 11:56:21 +, Emil Velikov wrote:
> > On Tue, 19 Feb 2019 at 10:08, Eric Engestrom  
> > wrote:
> > >
> > > On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > > > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> > > >  wrote:
> > > > >
> > > > > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom 
> > > > >  wrote:
> > > > > >
> > > > > > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > > > > > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > > > > > > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Using libdrm-2.4.97, mesa fails to build on ARM with:
> > > > > > > > >
> > > > > > > > > [  456s] In file included from
> > > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> > > > > > > > > [  456s]  from
> > > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
> > > > > > > > > [  456s]  from
> > > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_context.h:39,
> > > > > > > > > [  456s]  from
> > > > > > > > > ../../../../../src/gallium/drivers/freedreno/freedreno_program.c:33:
> > > > > > > > > [  456s] /usr/include/freedreno/freedreno_ringbuffer.h:32:10: 
> > > > > > > > > fatal
> > > > > > > > > error: xf86atomic.h: No such file or directory
> > > > > > > > >
> > > > > > > > > The freedreno headers were recently modified to use 
> > > > > > > > > xf86atomic.h:
> > > > > > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> > > > > > > > >
> > > > > > > >
> > > > > > > > oh, that union/ifdef hack was specifically to avoid this issue..
> > > > > > > > probably the patch removing it should be reverted.
> > > > > > >
> > > > > > > Right, I messed up with that commit, I didn't realise 
> > > > > > > freedreno_ringbuffer.h
> > > > > > > was installed. We need to remove that include.
> > > > > > >
> > > > > > > That said, I'm confused as to how freedreno_ringbuffer.h users in 
> > > > > > > Mesa
> > > > > > > knows whether it's safe to use refcnt from that union?
> > > > > > > It doesn't check for HAS_ATOMIC_OPS, so it can't know whether it
> > > > > > > contains garbage padding or a refcount, can it?
> > > > > >
> > > > > > No, that wouldn't even compile?
> > > > > >
> > > > > > (with the code before my messed up commit:)
> > > > > > Mesa includes freedreno_ringbuffer.h but doesn't define 
> > > > > > HAS_ATOMIC_OPS,
> > > > > > so fd_ringbuffer::refcnt doesn't get compiled in (but the padding is
> > > > > > still there), so code in mesa can't use ->refcnt because the 
> > > > > > compiler
> > > > > > wouldn't know what that is.
> > > > > >
> > > > > > I must be missing something, how did this ever compile?
> > > > >
> > > > > So, these days, mesa has it's own copy of the libdrm code,
> > > > > libdrm_freedreno really only exists so that you can still build old
> > > > > mesa with new libdrm.  And for a handful of small standalone utilities
> > > > > (fdperf, and some test code I use to poke the hw standalone)..
> > > > >
> > > > > But the way it works is that mesa never needs to access the refcnt, it
> > > > > mostly only needs to access cur/end (and it wants to do that in a way
> > > > > that can be inlined, not fxn call into a different dso, since that is
> > > > > a hot path).  The only code that accesses the refcnt is in the libdrm
> > > > > code itself.  Hence this ugly union hack, just to make the struct the
> > > > > same size both for mesa and for libdrm.
> > > > >
> > > > Ouch, I did not see the header was installed either.
> > > >
> > > > Just skimmed through Mesa prior to the libdrm_freedreno merge - there
> > > > are no references of fd_ringbuffer::refcnt.
> > > > So a simple revert will do the job. To avoid repeating this mistake,
> > > > we want to add an inline comment.
> > >
> > > Reverting the commits now, and I went to add a comment and saw that
> > > there was already one that I blindly missed last time around:
> > >
> > >   /* This is a bit gross, but we can't use atomic_t in exported
> > >* headers.  OTOH, we don't need the refcnt to be publicly
> > >* visible.  The only reason that this struct is exported is
> > >* because fd_ringbuffer_emit needs to be something that can
> > >* be inlined for performance reasons.
> > >*/
> > >
> > > I just pushed the revert:
> > > e09f327765902f3b7d31 "freedreno: revert bad freedreno/atomic_ops commits"

Thanks

> > > Emil, I'd like to release libdrm-2.4.98 today/tomorrow, I assume you're
> > > ok with that (since you got your MODALIAS change in there as well, which
> > > you wanted for your mesa series)?
> > > The drmIsMaster() issue also got fixed, so I think we're good to have
> > > a better release than the previous one :]
> > >
> 

[Bug 109678] build error: /usr/include/xorg/xf86Opt.h:44:10: error: two or more data types in declaration specifiers

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |
Product|xorg|DRI
Version|git |unspecified
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Component|Driver/Radeon   |libdrm
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org

--- Comment #1 from Michel Dänzer  ---
This was caused by libdrm, fixed with current libdrm Git master.

-- 
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 109678] build error: /usr/include/xorg/xf86Opt.h:44:10: error: two or more data types in declaration specifiers

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 109587 ***

-- 
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 109587] "xf86drm: Add drmIsMaster()" commit breaks X server builds

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||pedretti.fa...@gmail.com

--- Comment #2 from Michel Dänzer  ---
*** Bug 109678 has been marked as a duplicate of this bug. ***

-- 
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 v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Jordan Crouse]

On Sun, Feb 17, 2019 at 05:43:16PM -0500, Rob Clark wrote:
> On Sun, Feb 17, 2019 at 4:08 PM Rob Herring  wrote:
> >
> > On Mon, Feb 4, 2019 at 10:15 AM Jordan Crouse  
> > wrote:
> > >
> > > The GMU should have two power domains defined: "cx" and "gx". "cx" is the
> > > actual power domain for the device and "gx" will be attached at runtime
> > > to manage reference counting on the GPU device in case of a GMU crash.
> >
> > power-domains are supposed to be actual regions on a chip die which
> > can be power gated. However, they are often abused by being defined in
> > terms of kernel PM domains which are not always the same thing. This
> > description sounds like the latter case.
> >
> 
> iirc (and Jordan can correct me), this arrangement was needed because
> normally the GMU does the GPU power control (except for if we manage
> to crash it and need to reset the GMU)..
> 
> so maybe not 100% about the actual regions on chip die which can be
> gated.. but it is a reality of how hw + fw + sw fit together..

Ack - forgot to add Stephen who knows about this.

Rob is correct. The GX domain is real but it is normally controlled by an
off-CPU microcontroller. The CPU needs to get involved only when the
microcontroller crashes and we need to get things back to normal.  So the
description of it being an actual region on a chip die is accurate.

It sounds like I need to describe the hardware better in the bindings document.

Jordan

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

[Bug 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Peres  ---
Actually, moving this to IGT as this is unlikely a problem of i915.

-- 
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 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

--- Comment #2 from CI Bug Log  ---
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call
failed: RPC failed at server.  :integer division or 
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5629/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

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

[v17 0/3] Add Colorspace connector property interface

[Uma Shankar]

This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.
 - This property is just to inform sink what colorspace
   source is trying to drive.

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
default to an unset state where driver will assign the colorspace
when not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list

v5: Modified the colorspace property creation helper to take
platform specific enum list based on the capabilities of the
platform as suggested by Shashank. With this there is no need
for segregation between DP and HDMI.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the kernel doc as well with more details.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.

v10: Addressed Maarten' review comment, updated the RB from Maarten
and Jani Nikula's ack. Also fixed sparse warnings and checkpatch
complaints.

v11: Addressed Ville's review comments. Modified MACRO names, added
infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace
macro definitions defined in CTA 861.G. Currently linux/hdmi lacks
support for ACE formats, will be added as a separate series.

v12: Exported the helper API.

v13: As per Ville's suggestion, added separate CTA 861.G spec defined
HDMI specific macros. This is separate from user exposed enum values.
Fixed some macro naming inconsistencies.

v14: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB. Added a check
to allow only RGB colorspaces to be set in infoframe through the colorspace
property, since there is no output csc property to control planar formats
and it will be added later.

v15: Fixed an error in one of the if check.

v16: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues. Dropped the check for planar
vs RGB and allow all the colorspaces.

v17: Dropped DP changes and will be added later once full support for DP
colorspace is enabled. Addressed Ville's review comments and added Ville's
RB tags.

Uma Shankar (3):
  drm: Add HDMI colorspace property
  drm: Add colorspace info to AVI Infoframe
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
 drivers/gpu/drm/drm_connector.c| 78 ++
 drivers/gpu/drm/drm_edid.c | 70 ++
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c |  8 
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 13 ++
 include/drm/drm_connector.h| 42 ++
 include/drm/drm_edid.h |  6 +++
 9 files changed, 223 insertions(+)

-- 
1.9.1

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

[v17 1/3] drm: Add HDMI colorspace property

[Uma Shankar]

Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.

v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.

v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.

v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.

v13: Reorder the colorspace macros.

v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
 drivers/gpu/drm/drm_connector.c   | 78 +++
 include/drm/drm_connector.h   | 42 +
 3 files changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd40..4eb81f1 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff..07d65a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 };
 DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
 
+static const struct drm_prop_enum_list hdmi_co

[v17 2/3] drm: Add colorspace info to AVI Infoframe

[Uma Shankar]

This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.

v2: Moved this to drm core instead of i915 driver.

v3: Exported the helper function.

v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. This is
as per Ville's suggestion.

v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.

v6: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues.

v7: Undef some macros to avoid any namespace collision as suggested by
Ville. Added Ville's RB.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 70 ++
 include/drm/drm_edid.h |  6 
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..5f14253 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4924,6 +4924,76 @@ static bool is_hdmi2_sink(struct drm_connector 
*connector)
 }
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
+/* HDMI Colorspace Spec Definitions */
+#define FULL_COLORIMETRY_MASK  0x1FF
+#define NORMAL_COLORIMETRY_MASK0x3
+#define EXTENDED_COLORIMETRY_MASK  0x7
+#define EXTENDED_ACE_COLORIMETRY_MASK  0xF
+
+#define C(x) ((x) << 0)
+#define EC(x) ((x) << 2)
+#define ACE(x) ((x) << 5)
+
+#define HDMI_COLORIMETRY_NO_DATA   0x0
+#define HDMI_COLORIMETRY_SMPTE_170M_YCC(C(1) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_BT709_YCC (C(2) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_601 (C(3) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_709 (C(3) | EC(1) | ACE(0))
+#define HDMI_COLORIMETRY_SYCC_601  (C(3) | EC(2) | ACE(0))
+#define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
+#define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_CYCC   (C(3) | EC(5) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_RGB(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_YCC(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_D65(C(3) | EC(7) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER(C(3) | EC(7) | ACE(1))
+
+static const u32 hdmi_colorimetry_val[] = {
+   [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
+   [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
+   [DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
+   [DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
+   [DRM_MODE_COLORIMETRY_XVYCC_709] = HDMI_COLORIMETRY_XVYCC_709,
+   [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
+   [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
+   [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
+   [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
+   [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
+   [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
+};
+
+#undef C
+#undef EC
+#undef ACE
+
+/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ *   colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+   u32 colorimetry_val;
+   u32 colorimetry_index = conn_state->colorspace & FULL_COLORIMETRY_MASK;
+
+   if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
+   colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
+   else
+   colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
+
+   frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
+   /*
+* ToDo: Extend it for ACE formats as well. Modify the infoframe
+* structure and extend it in drivers/video/hdmi
+*/
+   frame->extended_colorimetry = (colorimetry_val >> 2) &
+   EXTENDED_COLORIMETRY_MASK;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
+
 /**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,6 +331,7 @@ struct cea_sad {
 
 struct drm_encoder;
 struct drm_connector;
+struct drm_connector_state;
 struct drm_display_mode;
 
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -35

[v17 3/3] drm/i915: Attach colorspace property and enable modeset

[Uma Shankar]

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

This patch attaches and enables HDMI colorspace, DP will be
taken care separately.

v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.

v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.

v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.

v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment

v7: Fixed a checkpatch complaint, Addressed  Maarten' review
comment, updated the RB from Maarten and Jani's ack.

v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.

v9: Added a check to only allow RGB colorpsaces to be set in
infoframe though the colorspace property. Since there is no output
csc property to control planar formats and it will be added later.
Changes for RGB->YUV conversion inside driver without userspace
knowledge is still supported. This is as per Ville's suggestion.

v10: Fixed an error in if check.

v11: Dropped the check for planar vs RGB and allow all the colorspaces.
Onus will be on userspace to pick whatever pipe output it is able to
drive.

v12: Added Ville's RB.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c |  8 
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 13 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 7cf9290..da419e1 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -126,6 +126,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+   new_conn_state->base.colorspace != old_conn_state->base.colorspace 
||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
 }
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_colorspace_property(connector))
+   drm_object_attach_property(&connector->base,
+  connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eec4ed9..7a883c3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1803,6 +1803,7 @@ int intel_connector_update_modes(struct drm_connector 
*connector,
 void intel_attach_force_audio_property(struct drm_connector *connector);
 void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f125a62..765718b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct 
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+   drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
   conn_state->connector,
   adj

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Emil Velikov]

On Tue, 19 Feb 2019 at 15:36, Dylan Baker  wrote:
>
> Quoting Daniel Vetter (2019-02-19 07:20:12)
> > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> > wrote:
> > >
> > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov 
> > > >  wrote:
> > > > >
> > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom 
> > > > >  wrote:
> > > > > >
> > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > > ---
> > > > > > > >  RELEASING | 27 ---
> > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > --- a/RELEASING
> > > > > > > > +++ b/RELEASING
> > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > > > > feature in question.
> > > > > > > >
> > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > >
> > > > > > > > -  1) Bump the version number in configure.ac and meson.build. 
> > > > > > > > We seem
> > > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > > libdrm, so
> > > > > > > > - just bump the  micro version.
> > > > > > > > -
> > > > > > > > -  2) Run autoconf and then re-run ./configure so the build 
> > > > > > > > system
> > > > > > > > - picks up the new version number.
> > > > > > > > -
> > > > > > > > -  3) Verify that the code passes "make distcheck".  Running 
> > > > > > > > "make
> > > > > > > > - distcheck" should result in no warnings or errors and end 
> > > > > > > > with a
> > > > > > > > - message of the form:
> > > > > > > > -
> > > > > > > > -   =
> > > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > > -   =
> > > > > > > > -
> > > > > > > > - Make sure that the version number reported by distcheck 
> > > > > > > > and in
> > > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > > configure.ac.
> > > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > > settled for
> > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump 
> > > > > > > > the micro
> > > > > > > > + version.
> > > > > > > > +
> > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > > + builddir/meson-dist/ matches the number you bumped to. 
> > > > > > > > Move that
> > > > > > > > + tarball to the libdrm repo root for the release script to 
> > > > > > > > pick up.
> > > > > > > >
> > > > > > > >4) Push the updated master branch with the bumped version 
> > > > > > > > number:
> > > > > >
> > > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers,
> > > > > > > >   Eric
> > > > > > > >
> > > > > > >
> > > > > > > Acked-by: Dylan Baker 
> > > > > > >
> > > > > > > But you should probably get someone other than just me to look at 
> > > > > > > this.
> > > > > >
> > > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > > maintainer :]
> > > > > >
> > > > > > If nobody object, I'll push this in a few weeks (there's really no 
> > > > > > rush,
> > > > > > but I want to make that move at some point, we have no reason to 
> > > > > > stay
> > > > > > dependant on autotools now that we have better tools).
> > > > >
> > > > > Must admit I'm not the biggest fan. I can see this being cool for the
> > > > > maintainer, if autotools was was present on their system.
> > > > > The unfortunate reality is - it's there for the foreseeable future.
> > > > > If anything it makes it more annoying for those using autotools/make -
> > > > > regardless if they like doing so or not.
> > > > >
> > > > > So that's a nack from me :-\
> > > >
> > > > Not really following what's the downside is of using meson to cut the
> > > > release tarball? Resulting tarball should still be able to build fine
> > > > with automake. If the concern is that automake will bitrot, then I
> > > > think a much better solution is to add a few automake targets to the
> > > > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > > > works neatly.
> > >
meson dist is effectively a git tarball. Hence one cannot simply
"./configure && make" it

> > > Agreed, and to me using meson has a huge upside: it packages what's in 
> > > git,
> > > unlike autotools which packages whatever was on your machine at the time.
If meson doesn't use any of 

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Kuehling, Felix]

On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
>> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
>>> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
 Another good question is also why the heck the acc_size counts
 towards
 the DMA32 zone?
>>> DMA32 TTM pages are accounted in the DMA32 zone. Other pages are
>>> not.
>> Yeah, I'm perfectly aware of this. But this is for the accounting
>> size!
>>
>> We have an accounting for the stuff needed additional to the pages
>> backing the BO (e.g. the page and DMA addr array).
>>
>> And from the bug description it sounds like we use the DMA32 zone
>> for
>> this accounting which of course is completely nonsense.
> It's actually accounted in all available zones, since it would be
> pretty hard to determine exactly where that memory should be accounted.
> In particular if it's vmalloced. It might be DMA32, it might not. Given
> the objective of stopping malicious user-space from exhausting the
> DMA32 zone it was, at the time the code was written, a reasonable
> approximation. With ever increasing memory sizes, there might be better
> solutions?

As far as I can see, in TTM, ttm_mem_global_alloc is only used for the 
acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems to 
use it to account for a few things that are allocated with kmalloc.

So would a better solution be to change ttm_mem_global_alloc to use only 
the kernel zone?

Regards,
   Felix


>
> /Thomas
>
>> Christian.
>>
>>> For small persistent allocations using ttm_mem_global_alloc(), they
>>> are
>>> accounted also in the DMA32 zone, which may cause over-accounting
>>> of
>>> that zone, but that's pretty unlikely to be a big problem..
>>>
>>> /Thomas
>>>
>>>
>>>
>>>
>>>
 In other words why should the internal bookkeeping pages be
 allocated
 in
 the DMA32 zone?

 That doesn't sounds valid to me in any way,
 Christian.

 Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> Hmm,
>
> This zone was intended to stop TTM page allocations from
> exhausting
> the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> default,
> which
> means if we drop this check, other devices may stop functioning
> unexpectedly?
>
> However, in the end I'd expect the kernel page allocation
> system
> to
> make sure there are some pages left in the DMA32 zone,
> otherwise
> random non-IO page allocations would also potentially exhaust
> the
> DMA32 zone without anybody caring, which means removing this
> zone
> wouldn't be any worse than whatever other subsystems may be
> doing
> already...
>
> /Thomas
>
>
> On 2/16/19 12:02 AM, Kuehling, Felix wrote:
>> This is an RFC. I'm not sure this is the right solution, but
>> it
>> highlights the problem I'm trying to solve.
>>
>> The dma32_zone limits the acc_size of all allocated BOs to
>> 2GB.
>> On a
>> 64-bit system with hundreds of GB of system memory and GPU
>> memory,
>> this can become a bottle neck. We're seeing TTM memory
>> allocation
>> failures not because we're truly out of memory, but because
>> we're
>> out of space in the dma32_zone for the acc_size needed for
>> our BO
>> book-keeping.
>>
>> Signed-off-by: Felix Kuehling 
>> CC: thellst...@vmware.com
>> CC: christian.koe...@amd.com
>> ---
>> drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index f1567c3..bb05365 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -363,7 +363,7 @@ static int
>> ttm_mem_init_highmem_zone(struct
>> ttm_mem_global *glob,
>> glob->zones[glob->num_zones++] = zone;
>> return 0;
>> }
>> -#else
>> +#elifndef CONFIG_64BIT
>> static int ttm_mem_init_dma32_zone(struct ttm_mem_global
>> *glob,
>>const struct sysinfo *si)
>> {
>> @@ -441,7 +441,7 @@ int ttm_mem_global_init(struct
>> ttm_mem_global
>> *glob)
>> ret = ttm_mem_init_highmem_zone(glob, &si);
>> if (unlikely(ret != 0))
>> goto out_no_zone;
>> -#else
>> +#elifndef CONFIG_64BIT
>> ret = ttm_mem_init_dma32_zone(glob, &si);
>> if (unlikely(ret != 0))
>> goto out_no_zone;
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cthellstrom%40vmware.com%7C1a84a2a700cd48b3980a08d695c38ade%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[John Stultz]

On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey  wrote:
> On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the Android userland
> > code to get this fully validated.
> >
> > This patchset tries to implement the per-heap devices for ION.
> > The main benefit is that it avoids multiplexing heap operations
> > through the /dev/ion interface, and allows for each heap to have
> > its own permissions/sepolicy rules.
>
> In general, I've always thought that having a device node per-heap is
> a bit messy for userspace. Multiplexing through the single node
> doesn't seem like an insurmountable problem, but the point about

Hrm. I guess for me having a custom enumeration interface over ioctl
seems less ideal compared to a directory list.

> permissions/sepolicy is reasonably compelling if it's a real
> requirement. What would be the reasons for that?

Its a bit second hand for me, so hopefully I don't have it wrong. I've
cc'ed some additional google folks and Benjamin for extra context, but
my sense of it is that you may have some less-trusted code that we're
fine with allocating system heap dma-bufs, but don't want to to be
giving access to more limited heaps like carveout or cma, or more
potentially security troubling heaps like system-contig.

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

[Bug 201273] Fatal error during GPU init amdgpu RX560

[bugzilla-daemon]

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

--- Comment #35 from quirin.blae...@freenet.de ---
Bug is still alive. v4.20.9

-- 
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: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Rodrigo Vivi]

On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> 
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
> 
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> drm/i915/icl: Add the ICL PCI IDs
> 
> The Intel Media SDK describes these as
> 
> /* VLV */
> { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */

hmmm... no idea about this one...
Ville?
maybe we should just remove from kernel since it was never
missed from Mesa?

> 
> /* ICL LP */
> { 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }

This is pure display so no Mesa needed for this ID.

> 
> and libdrm's intel_chipset.h describes the VLV id as
> 
> #define PCI_CHIP_VALLEYVIEW_PO0x0f30 /* VLV PO board */
> 
> It isn't clear what the ICL configuration should be from public
> information.
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index b91abd7a3f9..3568007b1ef 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
>  CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
>  CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
>  CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
> +CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
> @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 
> 6x8 GT1.5)")
>  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
>  CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> +CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Ville Syrjälä]

On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > 
> > 0x0f30
> > ff049b6ce21d2814451afd4a116d001712e0116b
> > drm/i915: bind driver to ValleyView chipsets
> > 
> > 0x8A70
> > d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> > drm/i915/icl: Add the ICL PCI IDs
> > 
> > The Intel Media SDK describes these as
> > 
> > /* VLV */
> > { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */
> 
> hmmm... no idea about this one...
> Ville?
> maybe we should just remove from kernel since it was never
> missed from Mesa?

Bspec says that is the infamous X0. Assuming it's not
lying to us it should be safe to remove.

> 
> > 
> > /* ICL LP */
> > { 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }
> 
> This is pure display so no Mesa needed for this ID.
> 
> > 
> > and libdrm's intel_chipset.h describes the VLV id as
> > 
> > #define PCI_CHIP_VALLEYVIEW_PO  0x0f30 /* VLV PO board */
> > 
> > It isn't clear what the ICL configuration should be from public
> > information.
> > 
> > diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> > index b91abd7a3f9..3568007b1ef 100644
> > --- a/include/pci_ids/i965_pci_ids.h
> > +++ b/include/pci_ids/i965_pci_ids.h
> > @@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
> >  CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
> >  CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
> >  CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
> > +CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
> > @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice 
> > Lake 6x8 GT1.5)")
> >  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> >  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
> >  CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> > +CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> >  CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")

-- 
Ville Syrjälä
Intel
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[Bug 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

--- Comment #3 from Stuart Summers  ---
Agree this looks like an issue in IGT or possibly in the chameleond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It does look feasible that if
we were to pass a 0 for width and height, we could potentially get a
div-by-zero exception when chameleond prepares the video output:
CaptureVideo ->
_PrepareCapturingVideo/_captured_params['max_frame_limit']/flow_manager.GetMaxFrameLimit
-> input_flow.GetMaxFrameLimit -> frame_manager.GetMaxFrameLimit ->
field_manager.GetMaxFieldLimit -> VideoDumper.GetMaxFieldLimit:
  def GetMaxFieldLimit(cls, width, height):  
"""Returns of the maximal number of fields which can be dumped.""" 
BYTE_PER_PIXEL = 3 
PAGE_SIZE = 4096 
field_size = width * height * BYTE_PER_PIXEL   
field_size = ((field_size - 1) / PAGE_SIZE + 1) * PAGE_SIZE
return cls._DUMP_BUFFER_SIZE / field_size

That said, running this myself locally does not result in the failure of this
sighting, and from kms_chamelium.c, during the CRC check, we are passing 0 for
width and height:
  chamelium_capture(data->chamelium, port, 0, 0, 0, 0, count);

So I'd expect this to fail all the time if the issue were in the Python call I
indicated above.

And I'd also expect for CI to have seen this already if that were the case,
given this code has been present for some time.

-- 
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 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

--- Comment #4 from Stuart Summers  ---
Sent that previous comment a little too quickly... It looks like we aren't
actually sending those 0's in the first place, in addition to my off-by-one
(given we are taking 0 - 1, not 0) miss:
  (w && h) ? "(ii)" : "(ii)",

>From chameleond, this will autofill x, y, width, and height based on the
current resolution. Maybe the resolution was misconfigured? Or perhaps there's
an issue in the chamelium FPGA?

I still think it would be interesting here to get the chameleond log (see
request here: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/29 + the
recent patch I posted to igt). There is quite a bit of state logging in
chameleond with that patch run locally with --d.

The only other thing I see interesting in the logs is this, just before the
error:
(kms_chamelium:2877) igt_chamelium-DEBUG: Chamelium needs FSM, handling

I don't see that when I run locally. Maybe we're getting a spurious hotplug
event while trying to capture video? Or maybe the video capture is taking to
long and/or hung for some reason, causing the hotplug to timeout?

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

[PATCH] drm/msm: Truncate the buffer object name if the copy from user failed

[Jordan Crouse]

If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.

This is on top of [1] reported and fixed by Dan Carpenter.

[1] https://patchwork.freedesktop.org/series/56656/

Fixes: f05c83e77460 ("drm/msm: add uapi to get/set debug name")
Reported-by: Dan Carpenter 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87eae44..9ca558d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -852,8 +852,11 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
break;
}
if (copy_from_user(msm_obj->name, u64_to_user_ptr(args->value),
-  args->len))
+  args->len)) {
+   msm_obj->name[0] = '\0'
ret = -EFAULT;
+   break;
+   }
msm_obj->name[args->len] = '\0';
for (i = 0; i < args->len; i++) {
if (!isprint(msm_obj->name[i])) {
-- 
2.7.4

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

[PATCH RESEND] drm/msm: Truncate the buffer object name if the copy from user failed

[Jordan Crouse]

(Resend since there was a compile error that I forgot to commit before sending)

If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.

This is on top of [1] reported and fixed by Dan Carpenter.

[1] https://patchwork.freedesktop.org/series/56656/

Fixes: f05c83e77460 ("drm/msm: add uapi to get/set debug name")
Reported-by: Dan Carpenter 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87eae44..906b2bb 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -852,8 +852,11 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
break;
}
if (copy_from_user(msm_obj->name, u64_to_user_ptr(args->value),
-  args->len))
+  args->len)) {
+   msm_obj->name[0] = '\0';
ret = -EFAULT;
+   break;
+   }
msm_obj->name[args->len] = '\0';
for (i = 0; i < args->len; i++) {
if (!isprint(msm_obj->name[i])) {
-- 
2.7.4

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

[PATCH] drm/amd/powerplay/smu8_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable table_size is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
index 553a203ac47c..019d6a206492 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
@@ -272,12 +272,10 @@ static int 
smu8_init_dynamic_state_adjustment_rule_settings(
struct pp_hwmgr *hwmgr,
ATOM_CLK_VOLT_CAPABILITY *disp_voltage_table)
 {
-   uint32_t table_size =
-   sizeof(struct phm_clock_voltage_dependency_table) +
-   (7 * sizeof(struct phm_clock_voltage_dependency_record));
+   struct phm_clock_voltage_dependency_table *table_clk_vlt;
 
-   struct phm_clock_voltage_dependency_table *table_clk_vlt =
-   kzalloc(table_size, GFP_KERNEL);
+   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
+   GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
pr_err("Can not allocate memory!\n");
-- 
2.20.1

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

[PATCH] drm/msm: Remove pm_runtime calls from msm_iommu.c

[Jordan Crouse]

Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
device before doing a IOMMU operation. This was because usually the
IOMMU driver didn't do power control of its own and since the hardware
used the same clocks and power as the respective multimedia device it
was a easy way to make sure that the power was available.

Now two things have changed. First, the SMMU devices can do their own power
control and more important bringing up the a6xx GPU isn't as easy as
turning on some clocks. To bring the GPU up we need the GMU which itself
needs the IOMMU so we have a chicken and egg problem.

Luckily this is easily fixed by removing the pm_runtime calls from the
functions and letting the device link to the IOMMU device handle the magic.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_iommu.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 4d62790..12bb54c 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -38,13 +38,8 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char 
* const *names,
int cnt)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
-   int ret;
 
-   pm_runtime_get_sync(mmu->dev);
-   ret = iommu_attach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
-
-   return ret;
+   return iommu_attach_device(iommu->domain, mmu->dev);
 }
 
 static void msm_iommu_detach(struct msm_mmu *mmu, const char * const *names,
@@ -52,9 +47,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const char 
* const *names,
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
-   pm_runtime_get_sync(mmu->dev);
iommu_detach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
 }
 
 static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
@@ -63,9 +56,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
 
-// pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
-// pm_runtime_put_sync(mmu->dev);
WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
@@ -75,9 +66,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
iova, unsigned len)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
-   pm_runtime_get_sync(mmu->dev);
iommu_unmap(iommu->domain, iova, len);
-   pm_runtime_put_sync(mmu->dev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH] drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable table_size is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 5273de3c5b98..0ad8fe4a6277 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -139,12 +139,10 @@ static int smu10_construct_max_power_limits_table(struct 
pp_hwmgr *hwmgr,
 static int smu10_init_dynamic_state_adjustment_rule_settings(
struct pp_hwmgr *hwmgr)
 {
-   uint32_t table_size =
-   sizeof(struct phm_clock_voltage_dependency_table) +
-   (7 * sizeof(struct phm_clock_voltage_dependency_record));
+   struct phm_clock_voltage_dependency_table *table_clk_vlt;
 
-   struct phm_clock_voltage_dependency_table *table_clk_vlt =
-   kzalloc(table_size, GFP_KERNEL);
+   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
+   GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
pr_err("Can not allocate memory!\n");
-- 
2.20.1

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

[Bug 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

Easwar Hariharan  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |stuart.summ...@intel.com
   |.org|

-- 
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 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

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

--- Comment #22 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
Ok, being back at the system after some days, I see the kmemleaks are still
present with Linux 5.0-rc6+.

Bernd, what triggers this on your system? What is your test case? Start some
program?

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

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #14 from Harry Wentland  ---
I'd recommend updating the System BIOS.

Early BIOSes on HP Envy x360 (and possibly other Raven laptops) had trouble
loading the DMCU FW.

-- 
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/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Alex Deucher]

On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
 wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable table_size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva 

Applied this and the smu8 patch.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index 5273de3c5b98..0ad8fe4a6277 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -139,12 +139,10 @@ static int 
> smu10_construct_max_power_limits_table(struct pp_hwmgr *hwmgr,
>  static int smu10_init_dynamic_state_adjustment_rule_settings(
> struct pp_hwmgr 
> *hwmgr)
>  {
> -   uint32_t table_size =
> -   sizeof(struct phm_clock_voltage_dependency_table) +
> -   (7 * sizeof(struct phm_clock_voltage_dependency_record));
> +   struct phm_clock_voltage_dependency_table *table_clk_vlt;
>
> -   struct phm_clock_voltage_dependency_table *table_clk_vlt =
> -   kzalloc(table_size, GFP_KERNEL);
> +   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
> +   GFP_KERNEL);
>
> if (NULL == table_clk_vlt) {
> pr_err("Can not allocate memory!\n");
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags

[jglisse]

From: Jérôme Glisse 

Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index e630def131ce..c8672c366f67 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -25,11 +25,13 @@ struct mmu_notifier_mm {
spinlock_t lock;
 };
 
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+
 struct mmu_notifier_range {
struct mm_struct *mm;
unsigned long start;
unsigned long end;
-   bool blockable;
+   unsigned flags;
 };
 
 struct mmu_notifier_ops {
@@ -229,7 +231,7 @@ extern void __mmu_notifier_invalidate_range(struct 
mm_struct *mm,
 static inline bool
 mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
 {
-   return range->blockable;
+   return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
 }
 
 static inline void mmu_notifier_release(struct mm_struct *mm)
@@ -275,7 +277,7 @@ static inline void
 mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
 {
if (mm_has_notifiers(range->mm)) {
-   range->blockable = true;
+   range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
 }
@@ -284,7 +286,7 @@ static inline int
 mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
 {
if (mm_has_notifiers(range->mm)) {
-   range->blockable = false;
+   range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
return __mmu_notifier_invalidate_range_start(range);
}
return 0;
@@ -331,6 +333,7 @@ static inline void mmu_notifier_range_init(struct 
mmu_notifier_range *range,
range->mm = mm;
range->start = start;
range->end = end;
+   range->flags = 0;
 }
 
 #define ptep_clear_flush_young_notify(__vma, __address, __ptep)
\
-- 
2.17.2

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

[PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable

[jglisse]

From: Jérôme Glisse 

Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an unsigned for more flags.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 4050ec1c3b45..e630def131ce 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -226,6 +226,12 @@ extern void __mmu_notifier_invalidate_range_end(struct 
mmu_notifier_range *r,
 extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  unsigned long start, unsigned long end);
 
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+   return range->blockable;
+}
+
 static inline void mmu_notifier_release(struct mm_struct *mm)
 {
if (mm_has_notifiers(mm))
@@ -455,6 +461,11 @@ static inline void _mmu_notifier_range_init(struct 
mmu_notifier_range *range,
 #define mmu_notifier_range_init(range, mm, start, end) \
_mmu_notifier_range_init(range, start, end)
 
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+   return true;
+}
 
 static inline int mm_has_notifiers(struct mm_struct *mm)
 {
-- 
2.17.2

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

[PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation

[jglisse]

From: Jérôme Glisse 

This update each existing invalidation to use the correct mmu notifier
event that represent what is happening to the CPU page table. See the
patch which introduced the events to see the rational behind this.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 fs/proc/task_mmu.c  |  4 ++--
 kernel/events/uprobes.c |  2 +-
 mm/huge_memory.c| 14 ++
 mm/hugetlb.c|  8 
 mm/khugepaged.c |  2 +-
 mm/ksm.c|  4 ++--
 mm/madvise.c|  2 +-
 mm/memory.c | 14 +++---
 mm/migrate.c|  4 ++--
 mm/mprotect.c   |  5 +++--
 mm/rmap.c   |  6 +++---
 11 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index fcbd0e574917..3b93ce496dd4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1151,8 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
break;
}
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0,
-   NULL, mm, 0, -1UL);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY,
+   0, NULL, mm, 0, -1UL);
mmu_notifier_invalidate_range_start(&range);
}
walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 46f546bdba00..8e8342080013 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -161,7 +161,7 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
struct mmu_notifier_range range;
struct mem_cgroup *memcg;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, addr,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
addr + PAGE_SIZE);
 
VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index c9d638f1b34e..1da6ca0f0f6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1184,9 +1184,8 @@ static vm_fault_t do_huge_pmd_wp_page_fallback(struct 
vm_fault *vmf,
cond_resched();
}
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-   haddr,
-   haddr + HPAGE_PMD_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+   haddr, haddr + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
@@ -1349,9 +1348,8 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf, 
pmd_t orig_pmd)
vma, HPAGE_PMD_NR);
__SetPageUptodate(new_page);
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-   haddr,
-   haddr + HPAGE_PMD_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+   haddr, haddr + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
spin_lock(vmf->ptl);
@@ -2028,7 +2026,7 @@ void __split_huge_pud(struct vm_area_struct *vma, pud_t 
*pud,
spinlock_t *ptl;
struct mmu_notifier_range range;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
address & HPAGE_PUD_MASK,
(address & HPAGE_PUD_MASK) + HPAGE_PUD_SIZE);
mmu_notifier_invalidate_range_start(&range);
@@ -2247,7 +2245,7 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t 
*pmd,
spinlock_t *ptl;
struct mmu_notifier_range range;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
address & HPAGE_PMD_MASK,
(address & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d9e5c5a4c004..a58115c6b0a3 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3250,7 +3250,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct 
mm_st

[PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening

This patch is just passing down the new informations by adding it to the
mmu_notifier_range structure.

Changes since v1:
- Initialize flags field from mmu_notifier_range_init() arguments

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 62f94cd85455..0379956fff23 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -58,10 +58,12 @@ struct mmu_notifier_mm {
 #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
 
 struct mmu_notifier_range {
+   struct vm_area_struct *vma;
struct mm_struct *mm;
unsigned long start;
unsigned long end;
unsigned flags;
+   enum mmu_notifier_event event;
 };
 
 struct mmu_notifier_ops {
@@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct 
mmu_notifier_range *range,
   unsigned long start,
   unsigned long end)
 {
+   range->vma = vma;
+   range->event = event;
range->mm = mm;
range->start = start;
range->end = end;
-   range->flags = 0;
+   range->flags = flags;
 }
 
 #define ptep_clear_flush_young_notify(__vma, __address, __ptep)
\
-- 
2.17.2

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

[PATCH v5 0/9] mmu notifier provide context informations

[jglisse]

From: Jérôme Glisse 

Since last version [4] i added the extra bits needed for the change_pte
optimization (which is a KSM thing). Here i am not posting users of
this, they will be posted to the appropriate sub-systems (KVM, GPU,
RDMA, ...) once this serie get upstream. If you want to look at users
of this see [5] [6]. If this gets in 5.1 then i will be submitting
those users for 5.2 (including KVM if KVM folks feel comfortable with
it).

Note that this serie does not change any behavior for any existing
code. It just pass down more informations to mmu notifier listener.

The rational for this patchset:


CPU page table update can happens for many reasons, not only as a
result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...)
but also as a result of kernel activities (memory compression, reclaim,
migration, ...).

This patch introduce a set of enums that can be associated with each
of the events triggering a mmu notifier:

- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking

Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid). Without this serie, driver are force to assume that
every notification is an munmap which triggers useless trashing within
drivers that associate structure with range of virtual address. Each
driver is force to free up its tracking structure and then restore it
on next device page fault. With this serie we can also optimize device
page table update [5].

More over this can also be use to optimize out some page table updates
like for KVM where we can update the secondary MMU directly from the
callback instead of clearing it.

Patches to leverage this serie will be posted separately to each sub-
system.

Cheers,
Jérôme

[1] v1 https://lkml.org/lkml/2018/3/23/1049
[2] v2 https://lkml.org/lkml/2018/12/5/10
[3] v3 https://lkml.org/lkml/2018/12/13/620
[4] v4 https://lkml.org/lkml/2019/1/23/838
[5] patches to use this:
https://lkml.org/lkml/2019/1/23/833
https://lkml.org/lkml/2019/1/23/834
https://lkml.org/lkml/2019/1/23/832
https://lkml.org/lkml/2019/1/23/831
[6] KVM restore change pte optimization
https://patchwork.kernel.org/cover/10791179/

Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Arnd Bergmann 

Jérôme Glisse (9):
  mm/mmu_notifier: helper to test if a range invalidation is blockable
  mm/mmu_notifier: convert user range->blockable to helper function
  mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags
  mm/mmu_notifier: contextual information for event enums
  mm/mmu_notifier: contextual information for event triggering
invalidation v2
  mm/mmu_notifier: use correct mmu_notifier events for each invalidation
  mm/mmu_notifier: pass down vma and reasons why mmu notifier is
happening v2
  mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper
  mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where
appropriate v2

 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  |  8 +--
 drivers/gpu/drm/i915/i915_gem_userptr.c |  2 +-
 drivers/gpu/drm/radeon/radeon_mn.c  |  4 +-
 drivers/infiniband/core/umem_odp.c  |  5 +-
 drivers/xen/gntdev.c|  6 +-
 fs/proc/task_mmu.c  |  3 +-
 include/linux/mmu_notifier.h| 93 +++--
 kernel/events/uprobes.c |  3 +-
 mm/hmm.c|  6 +-
 mm/huge_memory.c| 14 ++--
 mm/hugetlb.c| 12 ++--
 mm/khugepaged.c |  3 +-
 mm/ksm.c|  9 ++-
 mm/madvise.c|  3 +-
 mm/memory.c | 26 ---
 mm/migrate.c|  5 +-
 mm/mmu_notifier.c   | 12 +++-
 mm/mprotect.c   |  4 +-
 mm/mremap.c |  3 +-
 mm/oom_kill.c   |  3 +-
 mm/rmap.c   |  6 +-
 virt/kvm/kvm_main.c |  3 +-
 22 files changed, 180 insertions(+), 53 deletions(-)

-- 
2.17.2

___
dri

[PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function

[jglisse]

From: Jérôme Glisse 

Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.

This patch is the outcome of the following coccinelle patch:

%<---
@@
identifier I1, FN;
@@
FN(..., struct mmu_notifier_range *I1, ...) {
<...
-I1->blockable
+mmu_notifier_range_blockable(I1)
...>
}
--->%

spatch --in-place --sp-file blockable.spatch --dir .

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 8 
 drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
 drivers/gpu/drm/radeon/radeon_mn.c  | 4 ++--
 drivers/infiniband/core/umem_odp.c  | 5 +++--
 drivers/xen/gntdev.c| 6 +++---
 mm/hmm.c| 6 +++---
 mm/mmu_notifier.c   | 2 +-
 virt/kvm/kvm_main.c | 3 ++-
 8 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 3e6823fdd939..58ed401c5996 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -256,14 +256,14 @@ static int amdgpu_mn_invalidate_range_start_gfx(struct 
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
 * amdgpu_mn_invalidate_node
 */
-   if (amdgpu_mn_read_lock(amn, range->blockable))
+   if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
 
it = interval_tree_iter_first(&amn->objects, range->start, end);
while (it) {
struct amdgpu_mn_node *node;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
@@ -299,7 +299,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct 
mmu_notifier *mn,
/* notification is exclusive, but interval is inclusive */
end = range->end - 1;
 
-   if (amdgpu_mn_read_lock(amn, range->blockable))
+   if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
 
it = interval_tree_iter_first(&amn->objects, range->start, end);
@@ -307,7 +307,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct 
mmu_notifier *mn,
struct amdgpu_mn_node *node;
struct amdgpu_bo *bo;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1d3f9a31ad61..777b3f8727e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,7 +122,7 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
while (it) {
struct drm_i915_gem_object *obj;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
break;
}
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
index b3019505065a..c9bd1278f573 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -133,7 +133,7 @@ static int radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
 * the tear down.
 */
-   if (range->blockable)
+   if (mmu_notifier_range_blockable(range))
mutex_lock(&rmn->lock);
else if (!mutex_trylock(&rmn->lock))
return -EAGAIN;
@@ -144,7 +144,7 @@ static int radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
struct radeon_bo *bo;
long r;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
goto out_unlock;
}
diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index 012044f16d1c..3a3f1538d295 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ 

[PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

This patch introduce a set of enums that can be associated with each of
the events triggering a mmu notifier. Latter patches take advantages of
those enum values.

- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking

Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid).

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index c8672c366f67..2386e71ac1b8 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -10,6 +10,36 @@
 struct mmu_notifier;
 struct mmu_notifier_ops;
 
+/**
+ * enum mmu_notifier_event - reason for the mmu notifier callback
+ * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that
+ * move the range
+ *
+ * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
+ * madvise() or replacing a page by another one, ...).
+ *
+ * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
+ * ie using the vma access permission (vm_page_prot) to update the whole range
+ * is enough no need to inspect changes to the CPU page table (mprotect()
+ * syscall)
+ *
+ * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
+ * pages in the range so to mirror those changes the user must inspect the CPU
+ * page table (from the end callback).
+ *
+ * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
+ * access flags). User should soft dirty the page in the end callback to make
+ * sure that anyone relying on soft dirtyness catch pages that might be written
+ * through non CPU mappings.
+ */
+enum mmu_notifier_event {
+   MMU_NOTIFY_UNMAP = 0,
+   MMU_NOTIFY_CLEAR,
+   MMU_NOTIFY_PROTECTION_VMA,
+   MMU_NOTIFY_PROTECTION_PAGE,
+   MMU_NOTIFY_SOFT_DIRTY,
+};
+
 #ifdef CONFIG_MMU_NOTIFIER
 
 /*
-- 
2.17.2

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

[PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening.

This patchset do the initial mechanical convertion of all the places that
calls mmu_notifier_range_init to also provide the default MMU_NOTIFY_UNMAP
event as well as the vma if it is know (most invalidation happens against
a given vma). Passing down the vma allows the users of mmu notifier to
inspect the new vma page protection.

The MMU_NOTIFY_UNMAP is always the safe default as users of mmu notifier
should assume that every for the range is going away when that event
happens. A latter patch do convert mm call path to use a more appropriate
events for each call.

Changes since v1:
- add the flags parameter to init range flags

This is done as 2 patches so that no call site is forgotten especialy
as it uses this following coccinelle patch:

%<--
@@
identifier I1, I2, I3, I4;
@@
static inline void mmu_notifier_range_init(struct mmu_notifier_range *I1,
+enum mmu_notifier_event event,
+unsigned flags,
+struct vm_area_struct *vma,
struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }

@@
@@
-#define mmu_notifier_range_init(range, mm, start, end)
+#define mmu_notifier_range_init(range, event, flags, vma, mm, start, end)

@@
expression E1, E3, E4;
identifier I1;
@@
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, I1,
I1->vm_mm, E3, E4)
...>

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(..., struct vm_area_struct *VMA, ...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(...) {
struct vm_area_struct *VMA;
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN;
@@
FN(...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, NULL,
E2, E3, E4)
...> }
-->%

Applied with:
spatch --all-includes --sp-file mmu-notifier.spatch fs/proc/task_mmu.c 
--in-place
spatch --sp-file mmu-notifier.spatch --dir kernel/events/ --in-place
spatch --sp-file mmu-notifier.spatch --dir mm --in-place

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 fs/proc/task_mmu.c   |  3 ++-
 include/linux/mmu_notifier.h |  5 -
 kernel/events/uprobes.c  |  3 ++-
 mm/huge_memory.c | 12 
 mm/hugetlb.c | 12 
 mm/khugepaged.c  |  3 ++-
 mm/ksm.c |  6 --
 mm/madvise.c |  3 ++-
 mm/memory.c  | 25 -
 mm/migrate.c |  5 -
 mm/mprotect.c|  3 ++-
 mm/mremap.c  |  3 ++-
 mm/oom_kill.c|  3 ++-
 mm/rmap.c|  6 --
 14 files changed, 62 insertions(+), 30 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 92a91e7816d8..fcbd0e574917 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1151,7 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
break;
}
 
-   mmu_notifier_range_init(&range, mm, 0, -1UL);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0,
+   NULL, mm, 0, -1UL);
mmu_notifier_invalidate_range_start(&range);
}
walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 2386e71ac1b8..62f94cd85455 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -356,6 +356,9 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct 
*mm)
 
 
 static inline void mmu_notifier_range_init(struct mmu_notifier_range *range,
+  enum mmu_notifier_event event,
+  unsigned flags,
+  struct vm_area_struct *vma,
   struct mm_struc

[PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper

[jglisse]

From: Jérôme Glisse 

Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h |  4 
 mm/mmu_notifier.c| 10 ++
 2 files changed, 14 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 0379956fff23..b6c004bd9f6a 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -259,6 +259,8 @@ extern void __mmu_notifier_invalidate_range_end(struct 
mmu_notifier_range *r,
  bool only_end);
 extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  unsigned long start, unsigned long end);
+extern bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range);
 
 static inline bool
 mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
@@ -568,6 +570,8 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct 
*mm)
 {
 }
 
+#define mmu_notifier_range_update_to_read_only(r) false
+
 #define ptep_clear_flush_young_notify ptep_clear_flush_young
 #define pmdp_clear_flush_young_notify pmdp_clear_flush_young
 #define ptep_clear_young_notify ptep_test_and_clear_young
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index abd88c466eb2..ee36068077b6 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -395,3 +395,13 @@ void mmu_notifier_unregister_no_release(struct 
mmu_notifier *mn,
mmdrop(mm);
 }
 EXPORT_SYMBOL_GPL(mmu_notifier_unregister_no_release);
+
+bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range)
+{
+   if (!range->vma || range->event != MMU_NOTIFY_PROTECTION_VMA)
+   return false;
+   /* Return true if the vma still have the read flag set. */
+   return range->vma->vm_flags & VM_READ;
+}
+EXPORT_SYMBOL_GPL(mmu_notifier_range_update_to_read_only);
-- 
2.17.2

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

[PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2

[jglisse]

From: Jérôme Glisse 

When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag
for page table update that use set_pte_at_notify() and where the we are
going either from read and write to read only with same pfn or read only
to read and write with new pfn.

Note that set_pte_at_notify() itself should only be use in rare cases
ie we do not want to use it when we are updating a significant range of
virtual addresses and thus a significant number of pte. Instead for
those cases the event provided to mmu notifer invalidate_range_start()
callback should be use for optimization.

Changes since v1:
- Use the new unsigned flags field in struct mmu_notifier_range
- Use the new flags parameter to mmu_notifier_range_init()
- Explicitly list all the patterns where we can use change_pte()

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 34 --
 mm/ksm.c | 11 ++-
 mm/memory.c  |  5 +++--
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..0230a4b06b46 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -40,6 +40,26 @@ enum mmu_notifier_event {
MMU_NOTIFY_SOFT_DIRTY,
 };
 
+/*
+ * @MMU_NOTIFIER_RANGE_BLOCKABLE: can the mmu notifier range_start/range_end
+ * callback block or not ? If set then the callback can block.
+ *
+ * @MMU_NOTIFIER_USE_CHANGE_PTE: only set when the page table it updated with
+ * the set_pte_at_notify() the valid patterns for this are:
+ *  - pte read and write to read only same pfn
+ *  - pte read only to read and write (pfn can change or stay the same)
+ *  - pte read only to read only with different pfn
+ * It is illegal to set in any other circumstances.
+ *
+ * Note that set_pte_at_notify() should not be use outside of the above cases.
+ * When updating a range in batch (like write protecting a range) it is better
+ * to rely on invalidate_range_start() and struct mmu_notifier_range to infer
+ * the kind of update that is happening (as an example you can look at the
+ * mmu_notifier_range_update_to_read_only() function).
+ */
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+#define MMU_NOTIFIER_USE_CHANGE_PTE (1 << 1)
+
 #ifdef CONFIG_MMU_NOTIFIER
 
 /*
@@ -55,8 +75,6 @@ struct mmu_notifier_mm {
spinlock_t lock;
 };
 
-#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
-
 struct mmu_notifier_range {
struct vm_area_struct *vma;
struct mm_struct *mm;
@@ -268,6 +286,12 @@ mmu_notifier_range_blockable(const struct 
mmu_notifier_range *range)
return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
 }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+   return (range->flags & MMU_NOTIFIER_USE_CHANGE_PTE);
+}
+
 static inline void mmu_notifier_release(struct mm_struct *mm)
 {
if (mm_has_notifiers(mm))
@@ -509,6 +533,12 @@ mmu_notifier_range_blockable(const struct 
mmu_notifier_range *range)
return true;
 }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+   return false;
+}
+
 static inline int mm_has_notifiers(struct mm_struct *mm)
 {
return 0;
diff --git a/mm/ksm.c b/mm/ksm.c
index b782fadade8f..41e51882f999 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1066,9 +1066,9 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
 
BUG_ON(PageTransCompound(page));
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
-   pvmw.address,
-   pvmw.address + PAGE_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+   MMU_NOTIFIER_USE_CHANGE_PTE, vma, mm,
+   pvmw.address, pvmw.address + PAGE_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
if (!page_vma_mapped_walk(&pvmw))
@@ -1155,8 +1155,9 @@ static int replace_page(struct vm_area_struct *vma, 
struct page *page,
if (!pmd)
goto out;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
-   addr + PAGE_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+   MMU_NOTIFIER_USE_CHANGE_PTE,
+   vma, mm, addr, addr + PAGE_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
ptep = pte_o

Re: [PATCH] drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

On 2/19/19 1:51 PM, Alex Deucher wrote:
> On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
>  wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements for that array. For example:
>>
>> struct foo {
>> int stuff;
>> struct boo entry[];
>> };
>>
>> size = sizeof(struct foo) + count * sizeof(struct boo);
>> instance = kzalloc(size, GFP_KERNEL);
>>
>> Instead of leaving these open-coded and prone to type mistakes, we can
>> now use the new struct_size() helper:
>>
>> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>>
>> Notice that, in this case, variable table_size is not necessary, hence
>> it is removed.
>>
>> This code was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Applied this and the smu8 patch.  Thanks!
> 
Great!

Thanks, Alex.

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

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:04 PM  wrote:
>
> From: Jérôme Glisse 
>
> Since last version [4] i added the extra bits needed for the change_pte
> optimization (which is a KSM thing). Here i am not posting users of
> this, they will be posted to the appropriate sub-systems (KVM, GPU,
> RDMA, ...) once this serie get upstream. If you want to look at users
> of this see [5] [6]. If this gets in 5.1 then i will be submitting
> those users for 5.2 (including KVM if KVM folks feel comfortable with
> it).

The users look small and straightforward. Why not await acks and
reviewed-by's for the users like a typical upstream submission and
merge them together? Is all of the functionality of this
infrastructure consumed by the proposed users? Last time I checked it
was only a subset.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> >
> > From: Jérôme Glisse 
> >
> > Since last version [4] i added the extra bits needed for the change_pte
> > optimization (which is a KSM thing). Here i am not posting users of
> > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > RDMA, ...) once this serie get upstream. If you want to look at users
> > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > it).
> 
> The users look small and straightforward. Why not await acks and
> reviewed-by's for the users like a typical upstream submission and
> merge them together? Is all of the functionality of this
> infrastructure consumed by the proposed users? Last time I checked it
> was only a subset.

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
vs UNMAP. Both of which i intend to use. The RDMA folks already ack
the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
were ok with it too. I do not want to merge things through Andrew
for all of this we discussed that in the past, merge mm bits through
Andrew in one release and bits that use things in the next release.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #15 from Harry Wentland  ---
Can you see if this patch fixes it:
https://patchwork.freedesktop.org/patch/277181/

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

Re: [PATCH v2] xf86drm: Add drmIsMaster()

[Daniel Vetter]

On Thu, Jan 24, 2019 at 10:45:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 09:56:51AM +1300, Christopher James Halse Rogers 
> wrote:
> > On 24 January 2019 6:18:32 am NZDT, Emil Velikov  
> > wrote:
> > >On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> > > wrote:
> > >>
> > >> We can't use drmSetMaster to query whether or not a drm fd is master
> > >> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
> > >>
> > >> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
> > >> DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
> > >> whether or not the fd is master.
> > >>
> > >> This is useful for code that might get master by open()ing the drm
> > >device
> > >> while no other master exists, but can't call drmSetMaster itself
> > >because
> > >> it's not running as root or is in a container, where container-root
> > >isn't
> > >> real-root.
> > >>
> > >> v2: Use the AUTH_MAGIC request rather than MODE_ATTACHMODE, as it's
> > >more
> > >> clearly related to master status.
> > >>
> > >> Signed-off-by: Christopher James Halse Rogers
> > >
> > >> ---
> > >>  xf86drm.c | 15 +++
> > >>  xf86drm.h |  2 ++
> > >>  2 files changed, 17 insertions(+)
> > >>
> > >> diff --git a/xf86drm.c b/xf86drm.c
> > >> index 10df682b..adee5bd9 100644
> > >> --- a/xf86drm.c
> > >> +++ b/xf86drm.c
> > >> @@ -2741,6 +2741,21 @@ drm_public int drmDropMaster(int fd)
> > >>  return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, NULL);
> > >>  }
> > >>
> > >> +drm_public bool drmIsMaster(int fd)
> > >> +{
> > >> +/* Detect master by attempting something that requires
> > >master.
> > >> + *
> > >> + * Authenticating magic tokens requires master and 0 is
> > >> + * guaranteed to be an invalid magic number. Attempting this
> > >on
> > >> + * a master fd will fail therefore fail with EINVAL because
> > >0 is
> > >> + * invalid.
> > >> + *
> > >> + * A non-master fd will fail with EACCESS, as the kernel
> > >checks for
> > >> + * master before attempting to do anything else.
> > >> + */
> > >> +return drmAuthMagic(fd, 0) == EINVAL;
> > >What magic value is valid, is a DRM implementation detail, which we
> > >don't need to depend upon.
> > >
> > >Instead we can check for EACCES, since we care if we have permissions
> > >- aka are we master.
> > >The function returns a negative errno, so I'd make this a:
> > >
> > >return drmAuthMagic(fd, 0) != -EACCES;
> > >
> > >If you and Daniel agree, I'll squash this locally and push.
> > 
> > That's a much better idea, thanks!
> 
> I don't like checks for "something else happened", I much prefer checking
> for something specific. Hence == -EINVAL over != EACCESS. But I guess in
> this case here it doesn't matter.
> 
> We just need to make sure that the igt tests both ways, to make sure we'll
> never ever break this. I'd still prefer the current version, imo easier to
> write an igt to make sure it keeps working.

Since this landed now ... is the igt anywhere to make sure this keeps
working?
-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

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
>
> On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > >
> > > From: Jérôme Glisse 
> > >
> > > Since last version [4] i added the extra bits needed for the change_pte
> > > optimization (which is a KSM thing). Here i am not posting users of
> > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > it).
> >
> > The users look small and straightforward. Why not await acks and
> > reviewed-by's for the users like a typical upstream submission and
> > merge them together? Is all of the functionality of this
> > infrastructure consumed by the proposed users? Last time I checked it
> > was only a subset.
>
> Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> were ok with it too. I do not want to merge things through Andrew
> for all of this we discussed that in the past, merge mm bits through
> Andrew in one release and bits that use things in the next release.

Ok, I was trying to find the links to the acks on the mailing list,
those references would address my concerns. I see no reason to rush
SOFT_DIRTY and CLEAR ahead of the upstream user.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask

[Laura Abbott]

On 2/15/19 11:01 AM, John Stultz wrote:

On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey  wrote:


Hi John,

On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:



[snip]


Some thoughts, as this ABI break has the potential to be pretty painful.

1) Unfortunately, this ABI is exposed *through* libion via
ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
will have a wider impact to vendor userland code.


I figured libion could fairly easily loop through all the set bits in
heap_mask and call the ioctl for each until it succeeds. That
preserves the old behaviour from the libion clients' perspective.


Potentially, though that implicitly still caps the heaps to 32.  So
I'm not sure what the net benefit would be.



2) For patches that cause ABI breaks, it might be good to make it
clear in the commit what the userland impact looks like in userspace,
possibly with an example, so the poor folks who bisect down the change
as breaking their system in a year or so have a clear example as to
what they need to change in their code.

3) Also, its not clear how a given userland should distinguish between
the different ABIs.  We already have logic in libion to distinguish
between pre-4.12 legacy and post-4.12 implementations (using implicit
ion_free() behavior). I don't see any such check we can make with this
code. Adding another ABI version may require we provide an actual
interface version ioctl.



A slightly fragile/ugly approach might be to attempt a small
allocation with a heap_mask of 0x. On an "old" implementation,
you'd expect that to succeed, whereas it would/could be made to fail
in the "new" one.


Yea I think having a proper ION_IOC_VERSION is going to be necessary.

I'm hoping to send out an ugly first stab at the kernel side for
switching to per-heap devices (with a config for keeping /dev/ion for
legacy compat), which I hope will address the core issue this patch
does (moving away from heap masks to specifically requested heaps).

thanks
-john



Arnd/Greg said no to this last time I tried back in 2016

https://lore.kernel.org/lkml/1472769644-11039-4-git-send-email-labb...@redhat.com/T/#u
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH 1/4] ion: Add ION_VERSION ioctl

[Laura Abbott]

On 2/15/19 12:24 PM, John Stultz wrote:

With all the slight interface changes ion has had
through its time in staging, keeping userland working
properly has been a pain. Assuming more churn going
forward, provide a proper version interface.

Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/staging/android/ion/ion-ioctl.c | 4 
  drivers/staging/android/ion/ion.h   | 2 ++
  drivers/staging/android/uapi/ion.h  | 7 +++
  3 files changed, 13 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index a8d3cc4..458a9f2 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -13,6 +13,7 @@
  union ion_ioctl_arg {
struct ion_allocation_data allocation;
struct ion_heap_query query;
+   u32 version;
  };
  
  static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)

@@ -86,6 +87,9 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(&data.query);
break;
+   case ION_IOC_VERSION:
+   data.version = ION_VERSION;
+   break;
default:
return -ENOTTY;
}
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 47b594c..439e682 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -21,6 +21,8 @@
  
  #include "../uapi/ion.h"
  
+#define ION_VERSION 3

+
  /**
   * struct ion_platform_heap - defines a heap in the given platform
   * @type: type of the heap from ion_heap_type enum
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 5d70098..c480448 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -124,4 +124,11 @@ struct ion_heap_query {
  #define ION_IOC_HEAP_QUERY _IOWR(ION_IOC_MAGIC, 8, \
struct ion_heap_query)
  
+/**

+ * DOC: ION_IOC_VERSION - Get ION interface version
+ *
+ * Takes a u32 and returns the ION interface version
+ */
+#define ION_IOC_VERSION_IOR(ION_IOC_MAGIC, 9, u32)
+
  #endif /* _UAPI_LINUX_ION_H */



Like I said on the other thread, I was told no before
https://lore.kernel.org/lkml/1472769644-11039-4-git-send-email-labb...@redhat.com/T/#u
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe  wrote:
>
> On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > >
> > > > From: Jérôme Glisse 
> > > >
> > > > Since last version [4] i added the extra bits needed for the change_pte
> > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > > it).
> > >
> > > The users look small and straightforward. Why not await acks and
> > > reviewed-by's for the users like a typical upstream submission and
> > > merge them together? Is all of the functionality of this
> > > infrastructure consumed by the proposed users? Last time I checked it
> > > was only a subset.
> >
> > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > were ok with it too. I do not want to merge things through Andrew
> > for all of this we discussed that in the past, merge mm bits through
> > Andrew in one release and bits that use things in the next release.
>
> It is usually cleaner for everyone to split patches like this, for
> instance I always prefer to merge RDMA patches via RDMA when
> possible. Less conflicts.
>
> The other somewhat reasonable option is to get acks and send your own
> complete PR to Linus next week? That works OK for tree-wide changes.

Yes, I'm not proposing that they be merged together, instead I'm just
looking for the acked-by / reviewed-by tags even if those patches are
targeting the next merge window.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Laura Abbott]

On 2/19/19 9:21 AM, John Stultz wrote:

On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey  wrote:

On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:

This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the Android userland
code to get this fully validated.

This patchset tries to implement the per-heap devices for ION.
The main benefit is that it avoids multiplexing heap operations
through the /dev/ion interface, and allows for each heap to have
its own permissions/sepolicy rules.


In general, I've always thought that having a device node per-heap is
a bit messy for userspace. Multiplexing through the single node
doesn't seem like an insurmountable problem, but the point about


Hrm. I guess for me having a custom enumeration interface over ioctl
seems less ideal compared to a directory list.


permissions/sepolicy is reasonably compelling if it's a real
requirement. What would be the reasons for that?


Its a bit second hand for me, so hopefully I don't have it wrong. I've
cc'ed some additional google folks and Benjamin for extra context, but
my sense of it is that you may have some less-trusted code that we're
fine with allocating system heap dma-bufs, but don't want to to be
giving access to more limited heaps like carveout or cma, or more
potentially security troubling heaps like system-contig.

thanks
-john



Yes, the discussion was always based on being able to set separate
security policy for each heap. It's not clear to me how strong a
requirement is these days or if there's other options to enforce
the same thing.

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

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
> >
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > >
> > > > From: Jérôme Glisse 
> > > >
> > > > Since last version [4] i added the extra bits needed for the change_pte
> > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > > it).
> > >
> > > The users look small and straightforward. Why not await acks and
> > > reviewed-by's for the users like a typical upstream submission and
> > > merge them together? Is all of the functionality of this
> > > infrastructure consumed by the proposed users? Last time I checked it
> > > was only a subset.
> >
> > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > were ok with it too. I do not want to merge things through Andrew
> > for all of this we discussed that in the past, merge mm bits through
> > Andrew in one release and bits that use things in the next release.
> 
> Ok, I was trying to find the links to the acks on the mailing list,
> those references would address my concerns. I see no reason to rush
> SOFT_DIRTY and CLEAR ahead of the upstream user.

I intend to post user for those in next couple weeks for 5.2 HMM bits.
So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in
time for 5.2.

ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
ACKS RDMA https://lkml.org/lkml/2018/12/6/1473

For KVM Andrea Arcangeli seems to like the whole idea to restore the
change_pte optimization but i have not got ACK from Radim or Paolo,
however given the small performance improvement figure i get with it
i do not see while they would not ACK.

https://lkml.org/lkml/2019/2/18/1530

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel