[Bug 104472] Gigabyte AB350 and Radeon Pro WX2100 crashes with activated ACPI

[bugzilla-daemon]

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

--- Comment #1 from LCID Fire  ---
So far tested kernels 4.4, 4.13, 4.15. All fail, although at different
functions.

-- 
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 104472] Gigabyte AB350 and Radeon Pro WX2100 crashes with activated ACPI

[bugzilla-daemon]

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

Bug ID: 104472
   Summary: Gigabyte AB350 and Radeon Pro WX2100 crashes with
activated ACPI
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lcid-f...@gmx.net

Downstream prompted to file a bug for
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1740019

I am running a Ubuntu 16.04 on a Gigabyte AB350-Gaming 3 board. It runs fine
with a Nvidia Quadro GPU. When I switch the Quadro with a Radeon Pro WX2100 the
system stops booting (leads to kernel panics).
The only way to boot is then to add `acpi=off`.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

[Jani Nikula]

On Tue, 02 Jan 2018, Chris Wilson  wrote:
> Quoting Rodrigo Vivi (2018-01-02 19:12:18)
>> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
>> > + edid = drm_get_edid(connector, i2c);
>> > +
>> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
>> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO 
>> > bit-banging\n");
>> > + intel_gmbus_force_bit(i2c, true);
>> > + edid = drm_get_edid(connector, i2c);
>> > + intel_gmbus_force_bit(i2c, false);
>> > + }
>> 
>> Approach seems fine for this case.
>> I just wonder what would be the risks of forcing this bit and edid read when 
>> nothing is present on the other end?
>
> Should be no more risky than using GMBUS as the bit-banging is the
> underlying HW protocol; it should just be adding an extra delay to
> the disconnected probe. Offset against the chance that it fixes
> detection of borderline devices.
>
> I would say that given the explanation above, the question is why not
> apply it universally? (Bonus points for including the explanation as
> comments.)

I'm wondering, is gmbus too fast for the adapters, does gmbus generally
have different timing for the ack/nak as described in the commit message
than bit banging, or are the adapters just plain buggy? Do we have any
control over gmbus timings (don't have the time to peruse the bpsec just
now)?

BR,
Jani.

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

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/11] clk: sunxi-ng: a83t: Add M divider to TCON1 clock

[Chen-Yu Tsai]

On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec  wrote:
> TCON1 also has M divider, contrary to TCON0.
>
> Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU")
>
> Signed-off-by: Jernej Skrabec 

Added "And the mux is only 2 bits wide, instead of 3." to the commit
message and applied.

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

[Bug 104435] TF2 crashes with out of memory error vega 56

[bugzilla-daemon]

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

--- Comment #7 from Roland Scheidegger  ---
This is a 32bit app, it's just running out of virtual memory, not physical.
It is apparently also happening with intel graphics drivers (for instance
discussed here: https://github.com/ValveSoftware/Source-1-Games/issues/2212),
and macs may be affected too.
So this looks more like a game issue to me, albeit it might be possible the
driver also "wastes" virtual memory (vram/gtt mappings?). (I have no idea if
this is something which could be reasonably expected to be improved.)

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

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 01/02, Bryan O'Donoghue wrote:
> On 02/01/18 19:01, Stephen Boyd wrote:
> >On 12/31, Bryan O'Donoghue wrote:
> >>On 30/12/17 16:36, Mikko Perttunen wrote:
> >>>FWIW, we had this problem some years ago with the Tegra CPU clock
> >>>- then it was determined that a simpler solution was to have the
> >>>determine_rate callback support unsigned long rates - so clock
> >>>drivers that need to return rates higher than 2^31 can instead
> >>>implement the determine_rate callback. That is what's currently
> >>>implemented.
> >>>
> >>>Mikko
> >>
> >>Granted we could work around it but, having both zero and less than
> >>zero indicate error means you can't support larger than LONG_MAX
> >>which is I think worth fixing.
> >>
> >
> >Ok. But can you implement the determine_rate op instead of the
> >round_rate op for your clk?
> 
> Don't know .

Please try.

> 
> >It's not a work-around, it's the
> >preferred solution. That would allow rates larger than 2^31 for
> >the clk without pushing through a change to all the drivers to
> >express zero as "error" and non-zero as the rounded rate.
> >
> >I'm not entirely opposed to this approach, because we probably
> >don't care to pass the particular error value from a clk provider
> >to a clk consumer about what the error is.
> 
> Which was my thought. The return value of clk_ops->round_rate()
> appears not to get pushed up the stack, which is what the last patch
> in this series deals with.
> 
> [PATCH 33/33] clk: change handling of round_rate() such that only
> zero is an error

Hmm? clk_core_determine_round_nolock() returns 'rate' if rate < 0
from the round_rate op. clk_core_round_rate_nolock() returns that
value to clk_round_rate() which returns it to the consumer.

> 
> >It's actually what we
> >proposed as the solution for clk_round_rate() to return values
> >larger than LONG_MAX to consumers. But doing that consumer API
> >change or this provider side change is going to require us to
> >evaluate all the consumers of these clks to make sure they don't
> >check for some error value that's less than zero. This series
> >does half the work,
> 
> Do you mean users of clk_rounda_rate() ? I have a set of patches for
> that but wanted to separate that from clk_ops->round_rate() so as
> not to send ~70 patches out to LKML at once - even if they are in
> two blocks.

Ok. What have you done to the consumers of clk_round_rate()?
Made them treat 0 as an error instead of less than zero? The
documentation in clk.h needs to be updated. See this patch from
Paul Wamsley[1] for one proposed patch that went nowhere. Also
include Russell King please. It was also proposed to change the
function signature of clk_round_rate() to return unsigned long,
but that didn't go anywhere either.

> 
> If so, I can publish that set too for reference.
> 
> AFAICT on clk_ops->round_rate the last patch #33 ought to cover the
> usage of the return value of clk_ops->round_rate().
> 
> Have I missed something ?

Hopefully not!

> 
> >by changing the provider side, while ignoring
> >the consumer side and any potential fallout of the less than zero
> >to zero return value change.
> >
> 
> Can you look at #33 ? I'm not sure if you saw that one.
> 

Yeah I looked at it. From what I can tell it makes
clk_round_rate() return 0 now instead of whatever negative value
the clk_ops::round_rate function returns.

[1] https://lkml.kernel.org/r/alpine.DEB.2.02.1311251603310.23090@tamien

-- 
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 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

--- Comment #9 from Jonathan Williams  ---
I also have this problem on Arch Linux with a Radeon HD 7770, mesa 17.3.1-2,
gnome-shell 3.26.2+9+ga3736d3a3-1.  The Gnome Wayland session starts, but
several XWayland apps (Firefox, Thunderbird, steam client) do not.  glxinfo
shows no response when run, as reported above.

Downgrading to mesa 17.2.6 appears to fix it, but for this card I can also work
around it by switching to the amdgpu kernel module instead of the default
radeon, which appears to resolve the issues under mesa 17.3.

-- 
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 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #11 from yunt...@gmail.com ---
Created attachment 136506
  --> https://bugs.freedesktop.org/attachment.cgi?id=136506=edit
oxygen not included - bt full

-- 
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 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #10 from yunt...@gmail.com ---
Created attachment 136505
  --> https://bugs.freedesktop.org/attachment.cgi?id=136505=edit
oxygen not included - bt

-- 
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 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #9 from yunt...@gmail.com ---
"Oxygen Not Included" also crashes on startup. Backtraces attached.

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

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Bryan O'Donoghue]

On 02/01/18 19:01, Stephen Boyd wrote:

On 12/31, Bryan O'Donoghue wrote:

On 30/12/17 16:36, Mikko Perttunen wrote:

FWIW, we had this problem some years ago with the Tegra CPU clock
- then it was determined that a simpler solution was to have the
determine_rate callback support unsigned long rates - so clock
drivers that need to return rates higher than 2^31 can instead
implement the determine_rate callback. That is what's currently
implemented.

Mikko


Granted we could work around it but, having both zero and less than
zero indicate error means you can't support larger than LONG_MAX
which is I think worth fixing.



Ok. But can you implement the determine_rate op instead of the
round_rate op for your clk?


Don't know .


It's not a work-around, it's the
preferred solution. That would allow rates larger than 2^31 for
the clk without pushing through a change to all the drivers to
express zero as "error" and non-zero as the rounded rate.

I'm not entirely opposed to this approach, because we probably
don't care to pass the particular error value from a clk provider
to a clk consumer about what the error is.


Which was my thought. The return value of clk_ops->round_rate() appears 
not to get pushed up the stack, which is what the last patch in this 
series deals with.


[PATCH 33/33] clk: change handling of round_rate() such that only zero 
is an error



It's actually what we
proposed as the solution for clk_round_rate() to return values
larger than LONG_MAX to consumers. But doing that consumer API
change or this provider side change is going to require us to
evaluate all the consumers of these clks to make sure they don't
check for some error value that's less than zero. This series
does half the work,


Do you mean users of clk_rounda_rate() ? I have a set of patches for 
that but wanted to separate that from clk_ops->round_rate() so as not to 
send ~70 patches out to LKML at once - even if they are in two blocks.


If so, I can publish that set too for reference.

AFAICT on clk_ops->round_rate the last patch #33 ought to cover the 
usage of the return value of clk_ops->round_rate().


Have I missed something ?


by changing the provider side, while ignoring
the consumer side and any potential fallout of the less than zero
to zero return value change.



Can you look at #33 ? I'm not sure if you saw that one.


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

[Bug 104463] RX 460 fan speed 100%

[bugzilla-daemon]

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

Bug ID: 104463
   Summary: RX 460 fan speed 100%
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: terapy-sess...@bk.ru

Created attachment 136504
  --> https://bugs.freedesktop.org/attachment.cgi?id=136504=edit
Screenshot of the problem

100% fan speed without load and overheating. Screenshot attached. It is
sometimes possible to reduce the speed of the cooler by running the benchmark
Tomb Rider.

P.S. model Sapphire, distr Arch

-- 
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 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

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

yunt...@gmail.com changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #7 from yunt...@gmail.com ---
Both games use the Unity engine. Marking this as duplicate of 103769.

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

-- 
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 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #8 from yunt...@gmail.com ---
*** Bug 103850 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: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

[Chris Wilson]

Quoting Rodrigo Vivi (2018-01-02 19:12:18)
> On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> > + edid = drm_get_edid(connector, i2c);
> > +
> > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO 
> > bit-banging\n");
> > + intel_gmbus_force_bit(i2c, true);
> > + edid = drm_get_edid(connector, i2c);
> > + intel_gmbus_force_bit(i2c, false);
> > + }
> 
> Approach seems fine for this case.
> I just wonder what would be the risks of forcing this bit and edid read when 
> nothing is present on the other end?

Should be no more risky than using GMBUS as the bit-banging is the
underlying HW protocol; it should just be adding an extra delay to
the disconnected probe. Offset against the chance that it fixes
detection of borderline devices.

I would say that given the explanation above, the question is why not
apply it universally? (Bonus points for including the explanation as
comments.)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

[Rodrigo Vivi]

On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote:
> The ACK/NACK implementation as found in e.g. the G965 has the falling
> clock edge and the release of the data line after the ACK for the received
> byte happen at the same time.
> 
> This is conformant with the I2C specification, which allows a zero hold
> time, see footnote [3]: "A device must internally provide a hold time of
> at least 300 ns for the SDA signal (with respect to the V IH(min) of the
> SCL signal) to bridge the undefined region of the falling edge of SCL."
> 
> Some HDMI-to-VGA converters apparently fail to adhere to this requirement
> and latch SDA at the falling clock edge, so instead of an ACK
> sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
> transfer.
> 
> The bitbanging releases the data line for the ACK only 1/4 bit time after
> the falling clock edge, so a slave will see the correct value no matter
> if it samples at the rising or the falling clock edge or in the center.
> 
> Fallback to bitbanging is already done for the CRT connector.
> 
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685

s/Bug:/Bugzilla:

Did we get the confirmation that this also fix the Skylake issue
initially reported?

> 
> Signed-off-by: Stefan Brüns 
> 
> ---
> 
> Changes in v2:
> - Fix/enhance commit message, no code changes
> 
>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 4dea833f9d1b..847cda4c017c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>   struct edid *edid;
>   bool connected = false;
> + struct i2c_adapter *i2c;
>  
>   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>  
> - edid = drm_get_edid(connector,
> - intel_gmbus_get_adapter(dev_priv,
> - intel_hdmi->ddc_bus));
> + i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +
> + edid = drm_get_edid(connector, i2c);
> +
> + if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
> + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO 
> bit-banging\n");
> + intel_gmbus_force_bit(i2c, true);
> + edid = drm_get_edid(connector, i2c);
> + intel_gmbus_force_bit(i2c, false);
> + }

Approach seems fine for this case.
I just wonder what would be the risks of forcing this bit and edid read when 
nothing is present on the other end?

>  
>   intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
>  
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 12/31, Bryan O'Donoghue wrote:
> On 30/12/17 16:36, Mikko Perttunen wrote:
> >FWIW, we had this problem some years ago with the Tegra CPU clock
> >- then it was determined that a simpler solution was to have the
> >determine_rate callback support unsigned long rates - so clock
> >drivers that need to return rates higher than 2^31 can instead
> >implement the determine_rate callback. That is what's currently
> >implemented.
> >
> >Mikko
> 
> Granted we could work around it but, having both zero and less than
> zero indicate error means you can't support larger than LONG_MAX
> which is I think worth fixing.
> 

Ok. But can you implement the determine_rate op instead of the
round_rate op for your clk? It's not a work-around, it's the
preferred solution. That would allow rates larger than 2^31 for
the clk without pushing through a change to all the drivers to
express zero as "error" and non-zero as the rounded rate.

I'm not entirely opposed to this approach, because we probably
don't care to pass the particular error value from a clk provider
to a clk consumer about what the error is. It's actually what we
proposed as the solution for clk_round_rate() to return values
larger than LONG_MAX to consumers. But doing that consumer API
change or this provider side change is going to require us to
evaluate all the consumers of these clks to make sure they don't
check for some error value that's less than zero. This series
does half the work, by changing the provider side, while ignoring
the consumer side and any potential fallout of the less than zero
to zero return value change.

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

Re: [PATCH v2] drm/msm: Fix NULL deref in adreno_load_gpu

[Jordan Crouse]

On Fri, Dec 22, 2017 at 03:41:13PM +0530, Archit Taneja wrote:
> The msm/kms driver should work even if there is no GPU device specified
> in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
> since the driver assumes that priv->gpu_pdev is non-NULL.
> 
> Perform an additional check on priv->gpu_pdev before trying to retrieve
> the msm_gpu pointer from it.
> 
> v2: Incorporate Jordan's comments:
> - Simplify the check to share the same error message.
> - Use dev_err_once() to avoid an error message every time we open the
>   drm device fd.
> 
> Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time)
> 
> Signed-off-by: Archit Taneja 

Acked-by: Jordan Crouse 

> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 05022ea2a007..bfb3d689f47d 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -125,11 +125,14 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
>  {
>   struct msm_drm_private *priv = dev->dev_private;
>   struct platform_device *pdev = priv->gpu_pdev;
> - struct msm_gpu *gpu = platform_get_drvdata(priv->gpu_pdev);
> + struct msm_gpu *gpu = NULL;
>   int ret;
>  
> + if (pdev)
> + gpu = platform_get_drvdata(pdev);
> +
>   if (!gpu) {
> - dev_err(dev->dev, "no adreno device\n");
> + dev_err_once(dev->dev, "no GPU device was found\n");
>   return NULL;
>   }

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

Re: [RFC PATCH v2 1/1] drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out

[Jon Hunter]

On 20/12/17 18:15, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 11:32:23AM +, Guillaume Tucker wrote:
>> When neither HDMI nor DP is supported such as on the tegra124, the
>> sor->clk_out is not initialised and remains NULL.  In this case, the
>> parent clock can't be assigned to it so revert to the previous
>> behaviour of assigning it to the main sor->clk instead.
>>
>> This fixes a kernel hang on tegra124 and should also affect tegra210
>> as they both don't support HDMI and DP.  Tested on tegra124 only.
>>
>> Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
>> Signed-off-by: Guillaume Tucker 
>> CC: Thierry Reding 
>> ---
>>  drivers/gpu/drm/tegra/sor.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> How about just the below instead? It's one more line than your patch,
> but it will automatically handle all occurrences of clk_out properly.
> 
> --- >8 ---
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index f6313c4d612e..4be9edf9c6fe 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -3047,6 +3047,8 @@ static int tegra_sor_probe(struct platform_device *pdev)
> name, err);
> goto remove;
> }
> +   } else {
> +   sor->clk_out = sor->clk;
> }
>  
> sor->clk_parent = devm_clk_get(>dev, "parent");
> --- >8 ---
> 
> That said, I suspect the SOR might be compatible from a clock point of
> view with later versions and perhaps we just didn't implement clocks
> correctly back in the Tegra124 timeframe.
> 
> Maybe Peter knows.

So the above change from Thierry works for me and we need this for v4.15
(otherwise nyan-big does not boot) so you can have my ...

Tested-by: Jon Hunter 

However, would be good to have Peter's ACK, especially seeing that
Tegra210 sor0 does not support HDMI and DP. So we need to make sure this
is correct for Tegra210 as well (although I have not seen any
regressions for Tegra210).

Cheers
Jon

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

RE: FOSDEM 2018: Graphics DevRoom: Call for speaker.

[Navare, Manasi D]

Hi Luc,

I have submitted a proposal for a talk in Graphics Dev Room, but haven’t heard 
anything regarding the selection. Is there a timeline by which the 
notifications will be sent so that the travel can be planned accordingly?

Has anyone else heard about the submissions?

Regards
Manasi


Hi,

At FOSDEM on saturday the 3rd of february 2018, there will be another graphics 
DevRoom. URL: https://fosdem.org/2018/

The focus of this DevRoom is of course the same as the previous editions, 
namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel or 
userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management, low level toolkit stuff, and other areas which i 
might have overlooked above are accepted.

Slots will be handed out on a first come, first serve basis. The best slots 
will go to those who apply the earliest. We have the devroom from
10:30 til 19:00, giving us 8h30, so eight 50 minute talkes and one 20 minute 
talk are available.

Talk Submission:


Like the last few years, the pentabarf system will be used for talk submission.

https://penta.fosdem.org/submission/FOSDEM18

Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with 
a sliding schedule which only gets filled out on the last day. Upwards of 1 
people are visiting this event, and most of them get a printed booklet or use 
the schedule on the FOSDEM website or an app for their phone to figure out what 
to watch or participate in next. 
So please put some effort in your talk submission and details.

Since this an open source community event, please refrain from turning in a 
talk that is a pure corporate or product commercial. Also, if you are unsure on 
whether you can come or not (this is FOSDEM, why are you not there anyway?), 
please wait with submitting your talk. Submitting a talk and then not turning 
up because you could not be bothered is a sure-fire way to get larted and then 
to never be allowed to talk again.

When in pentabarf, please give the abstract and description, for both the event 
and the speaker, some thought. The abstract should be a shortened description, 
and the event abstract will sometimes even be printed directly in the booklet. 
BUT, on the website the abstract is immediately followed by the full 
description. If your abstract is fully descriptive, while terse, you might get 
away with just the abstract.

All talks will be recorded, and will be streamed out live, and will later be 
made available as CC-BY after a few days.

As for deadlines, the fosdem organizers want to have a finished schedule by the 
15th of december. Don't count on this deadline: first come first serve! The 
worst slots will be assigned to those who come last, which could be pretty dire 
given that there is the traditional FOSDEM beer event the night before ;)

Please try to re-use your accounts from the previous years, i hope that this 
year you can actually recycle your data. If you have forgotten your password, 
then you can reset it here: 
https://penta.fosdem.org/user/forgot_password If there are any issues, just 
poke me here or on IRC.

Necessary information:
--

Below is a list of what i need to see filled in in pentabarf when you apply for 
a devroom before i consider it a valid submission. Remember: 
first come, first serve. The best slots (which are on saturday
afternoon) are for the earliest submissions.

On your personal page:
* General:
  * First and last name
  * Nickname
  * Image
* Contact:
  * email address
  * mobile number (this is a very hard requirement as there will be no
   other reliable form of emergency communication on the day)
* Description:
  * Abstract
  * Description

Create an event:
* On the General page:
  * Event title
  * Event subtitle.
  * Track: Graphics Devroom
  * Event type: Lecture (talk) or Meeting (BoF)
* Persons:
  * Add yourself as speaker.
* Description:
  * Abstract:
  * Full Description
* Links:
  * Add relevant links.

Everything else can be ignored or will be filled in by me or the FOSDEM 
organizers. Remember, i will only schedule your talk after the basics are 
somewhat filled in (you still can change them until december 15th).

I will be keeping a keen eye on your submissions and will come back with 
further questions or make small fixes as needed. Feel free to poke me with any 
questions or anything, both on irc (libv@freenode) and on email.

That's about it. Hope to see you all at FOSDEM :)

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

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 26.12.2017 07.39, skrev Meghana Madhyastha:

On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:

Den 11.12.2017 18.56, skrev Noralf Trønnes:

Den 11.12.2017 18.45, skrev Noralf Trønnes:

Den 11.12.2017 15.58, skrev Meghana Madhyastha:

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
    drm/tinydrm: Move helper functions from tinydrm-helpers to
backlight.h
    drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
    drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[    8.057792] Unable to handle kernel paging request at virtual
address
fe6b



[    9.144181] ---[ end trace 149c05934b6a6dcc ]---

Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ?
tinydrm_enable_backlight and
tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
 DRM_ERROR("Failed to enable backlight %d\n", ret);

I'm not sure, just asking whether this could be a possible reason
for the above trace.

The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.

I have set up the raspberry pi and have built and boot into the custom
kernel
but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.

of_find_backlight() can return an error pointer (-EPROBE_DEFER):

diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device
*devm_of_find_backlight(struct device *dev)
     int ret;

     bd = of_find_backlight(dev);
-   if (!bd)
-   return NULL;
+   if (IS_ERR_OR_NULL(bd))
+   return bd;

     ret = devm_add_action(dev, devm_backlight_put, bd);
     if (ret) {

That solved the crash, but the backlight didn't turn on.
I had to do this as well:

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct
backlight_device *bd)
     if (!bd)
     return 0;

+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;

No, this is wrong, it should happen on probe, not every time it's enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().


I'm not happy with this brightness hack of mine really.

Since I last looked at this I see that pwm_bl has gained the ability to
start in a power off state (pwm_backlight_initial_power_state()).
However the gpio_backlight driver doesn't do this. gpio_backlight has a
'default-on' property, but the problem is that it sets brightness, not
power state. So the absense of the property sets brightness to zero,
which makes the driver turn off backlight on probe. This seems to be
fine, but then systemd-backlight comes along and restores brightness
to 1, since that's what it was on shutdown. This turns on backlight and
now I have a glaring white uninitialized panel waiting for the display
driver to set it up.

This patch would solve my problem:

diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..54bb722e1ea3 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
     return PTR_ERR(bl);
     }

-   bl->props.brightness = gbl->def_value;
+   bl->props.brightness = 1;
+   bl->props.state = gbl->def_value ? 0 : BL_CORE_FBBLANK;
     backlight_update_status(bl);

     platform_set_drvdata(pdev, bl);

I have a few questions here.

So if I understood the problem correctly, you do not want the backlight
brightness set to 1 by systemd-backlight because it sets the backlight
on before the display driver is set up. My question is, how does pwm_bl
avoid this ? Even if it starts off in a power off state, won't the same
thing happen i.e won't systemd set the brightness and subsequently turn
on the backlight ?


Look at the update_status implementation in both drivers and you'll see
that if blanking is active, they use a value of zero for brightness.

pwm_bl can set the blanking/power state during 

[Bug 104435] TF2 crashes with out of memory error vega 56

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO

--- Comment #6 from Christian König  ---
Well the error message is pretty clear.

Maybe TF2 has a memory leak or something like that?

-- 
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 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #13 from Harry Wentland  ---
(In reply to AceLan Kao from comment #10)
> Hi Harry,
> 
> I'm wondering if there is also an equivalence method to fix it on v4.13
> kernel.

You could try applying the patches mentioned by Michel, plus my patch. I'm not
sure whether they'll apply well or work. The DC patch shouldn't be a problem if
it applies but I'm not sure about the other patches Michel mentioned.

-- 
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] backlight: tdo24m: fix the spi cs between transfers

[Lee Jones]

On Thu, 28 Dec 2017, Robert Jarzmik wrote:

> Currently the LCD display (TD035S) on the cm-x300 platform is broken and
> remains blank.
> 
> The TD0245S specification requires that the chipselect is toggled
> between commands sent to the panel. This was also the purpose of the
> former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip
> select changes between transfers").
> 
> Unfortunately, the "cs_change" field of a SPI transfer is
> misleading. Its true meaning is that for a SPI message holding multiple
> transfers, the chip select is toggled between each transfer, but for the
> last transfer it remains asserted.
> 
> In this driver, all the SPI messages contain exactly one transfer, which
> means that each transfer is the last of its message, and as a
> consequence the chip select is never toggled.
> 
> Actually, there was a second bug hidding the first one, hence the
> problem was not seen until v4.6. This problem was fixed by commit
> a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based
> boards.
> 
> This fix makes the TD035S work again on a cm-x300 board. The same
> applies to other PXA boards, ie. corgi and tosa.
> 
> Fixes: a52db659c79c ("spi: pxa2xx: Fix cs_change management")

Since this fixes an old kernel, I'm not going to apply it for -fixes.

> Reported-by: Andrea Adami 
> Signed-off-by: Robert Jarzmik 
> Acked-by: Daniel Thompson 
> ---
> Since v1: added 2 other panels
> Since v2: added Daniel's ack
> ---
>  drivers/video/backlight/corgi_lcd.c | 2 +-
>  drivers/video/backlight/tdo24m.c| 2 +-
>  drivers/video/backlight/tosa_lcd.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Applied to -next, thanks.

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

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Julia Lawall]

On Tue, 2 Jan 2018, Bart Van Assche wrote:

> On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote:
> > On Tue, 2 Jan 2018, Bob Peterson wrote:
> > > - Original Message -
> > > > - Original Message -
> > > >
> > > Still, the GFS2 and DLM code has a plethora of broken-up printk messages,
> > > and I don't like the thought of re-combining them all.
> >
> > Actually, the point of the patch was to remove the unnecessary \n at the
> > end of the string, because log_print will add another one.  If you prefer
> > to keep the string broken up, I can resend the patch in that form, but
> > without the unnecessary \n.
>
> Please combine any user-visible strings into a single line for which the
> unneeded newline is dropped since these strings are modified anyway by
> your patch.

That is what the submitted patch (2/12 specifically) did.

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

[Bug 103788] [DC] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

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

coolo...@gmail.com changed:

   What|Removed |Added

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

--- Comment #9 from coolo...@gmail.com ---
Appears to be fixed, at least on the latest mesa-git

-- 
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 104435] TF2 crashes with out of memory error vega 56

[bugzilla-daemon]

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

coolo...@gmail.com changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|REOPENED

--- Comment #5 from coolo...@gmail.com ---
Surely it cant be memory, the gpu has 8gb of vram and I have installed 16gb of
ddr3 ram.

-- 
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 104456] unsupported feature 'separate color planes' in VCE x264 high profile

[bugzilla-daemon]

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

--- Comment #1 from Janpieter Sollie  ---
Created attachment 136496
  --> https://bugs.freedesktop.org/attachment.cgi?id=136496=edit
ffmpeg encoding output

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

[Bug 104456] unsupported feature 'separate color planes' in VCE x264 high profile

[bugzilla-daemon]

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

Bug ID: 104456
   Summary: unsupported feature 'separate color planes' in VCE
x264 high profile
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: janpieter.sol...@dommel.be
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136495
  --> https://bugs.freedesktop.org/attachment.cgi?id=136495=edit
mplayer decoding output

The VAAPI encoder using Tonga and Fiji cards produces a correct stream when
using the Baseline or Main profile, but using the High profile, the VCE uses
the separate color planes feature, which produces an unplayable stream.  I
tried looking through the code, but couldn't find anything which looks like the
root of the error.  View attachment for mplayer output

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

Re: [PATCH v3] drm/ttm: check the return value of kzalloc

[Christian König]

Am 02.01.2018 um 14:24 schrieb Xiongwei Song:

In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.

Signed-off-by: Xiongwei Song 


Reviewed-by: Christian König 

Going to pick that up for the next release.

Thanks,
Christian.


---
v2->v3: delete goto expression
v1->v2: delete kfree _manager
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..5d252fb27a82 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
pr_info("Initializing pool allocator\n");
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);

+   if (!_manager)
+   return -ENOMEM;
  
  	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  


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

[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3

[bugzilla-daemon]

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

kaspar.t...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
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 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3

[bugzilla-daemon]

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

--- Comment #7 from kaspar.t...@gmail.com ---
Can confirm that updates to either X.org or Mesa fixed this issue already. Can
close this I guess.

-- 
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: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Julia Lawall]

On Tue, 2 Jan 2018, Bob Peterson wrote:

> - Original Message -
> | - Original Message -
> | | Drop newline at the end of a message string when the printing function 
> adds
> | | a newline.
> |
> | Hi Julia,
> |
> | NACK.
> |
> | As much as it's a pain when searching the source code for output strings,
> | this patch set goes against the accepted Linux coding style document. See:
> |
> | 
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings
> |
> | Regards,
> |
> | Bob Peterson
> |
> |
> Hm. I guess I stand corrected. The document reads:
>
> "However, never break user-visible strings such as printk messages, because 
> that breaks the ability to grep for them."
>
> Still, the GFS2 and DLM code has a plethora of broken-up printk messages,
> and I don't like the thought of re-combining them all.

Actually, the point of the patch was to remove the unnecessary \n at the
end of the string, because log_print will add another one.  If you prefer
to keep the string broken up, I can resend the patch in that form, but
without the unnecessary \n.

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

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Bob Peterson]

- Original Message -
| - Original Message -
| | Drop newline at the end of a message string when the printing function adds
| | a newline.
| 
| Hi Julia,
| 
| NACK.
| 
| As much as it's a pain when searching the source code for output strings,
| this patch set goes against the accepted Linux coding style document. See:
| 
| 
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings
| 
| Regards,
| 
| Bob Peterson
| 
| 
Hm. I guess I stand corrected. The document reads:

"However, never break user-visible strings such as printk messages, because 
that breaks the ability to grep for them."

Still, the GFS2 and DLM code has a plethora of broken-up printk messages,
and I don't like the thought of re-combining them all.

Regards,

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

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

[Julia Lawall]

On Tue, 2 Jan 2018, Bob Peterson wrote:

> - Original Message -
> | Drop newline at the end of a message string when the printing function adds
> | a newline.
>
> Hi Julia,
>
> NACK.
>
> As much as it's a pain when searching the source code for output strings,
> this patch set goes against the accepted Linux coding style document. See:
>
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings

I don't think that's the case:

"However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them."

julia

>
> Regards,
>
> Bob Peterson
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #5 from Carlo Caione  ---
Created attachment 136493
  --> https://bugs.freedesktop.org/attachment.cgi?id=136493=edit
journal corrupted screen amd-staging-drm-next

Unfortunately I just verified that this is still reproducible on the
development branch (agd5f/amd-staging-drm-next), it's just a bit more
difficult.

In attachment the log captured when the system is resumed and the screen is
corrupted.

-- 
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 104435] TF2 crashes with out of memory error vega 56

[bugzilla-daemon]

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

--- Comment #4 from Christian König  ---
The error message is a known issue, but harmless.

That TF2 is crashing is simply because it runs out of system memory.

Try to install more memory and/or add a swap partition.

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

[GIT PULL] omapdrm fix for 4.15

[Tomi Valkeinen]

Hi Dave,

Please pull an omapdrm fix for 4.15, if it's not too late.

 Tomi

The following changes since commit 03bfd4e19b935adb8be4f7342f13395fb7f11096:

  Merge tag 'drm-intel-fixes-2017-12-22-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-12-28 05:20:07 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.15-fixes

for you to fetch changes up to df29c9db8ace4497a61f3b3d33c2b8a7fd4b7b8e:

  omapdrm/dss/hdmi4_cec: fix interrupt handling (2018-01-02 14:20:10 +0200)


omapdrm fixes for 4.15

* Fix OMAP4 HDMI CEC interrupt handling and a possible buffer overflow


Hans Verkuil (1):
  omapdrm/dss/hdmi4_cec: fix interrupt handling

 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 46 +++--
 1 file changed, 9 insertions(+), 37 deletions(-)

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/ttm: check the return value of kzalloc

[Christian König]

Am 02.01.2018 um 13:35 schrieb Xiongwei Song:

In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.

Signed-off-by: Xiongwei Song 
---
v1->v2: delete kfree _manager
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..583d73edb7df 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,10 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
pr_info("Initializing pool allocator\n");
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);

+   if (!_manager) {
+   ret = -ENOMEM;
+   goto out;
+   }


A simpler "return -ENOMEM" should do here as well.

Regards,
Christian.

  
  	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
@@ -1041,6 +1045,8 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)

ttm_pool_mm_shrink_init(_manager);
  
  	return 0;

+out:
+   return ret;
  }
  
  void ttm_page_alloc_fini(void)


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

[Bug 104435] TF2 crashes with out of memory error vega 56

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Christian König  ---


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

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 CC||coolo...@gmail.com

--- Comment #6 from Christian König  ---
*** Bug 104435 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

[Bug 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #7 from Nannerpuss  ---
(In reply to lethalwp from comment #5)
> other unity games affected:
> candle
> silence
> grow home
> pulse
> mousecraft
> wasteland 2
> broforce
> habitat
> munin
> the last tinker
> agatha christie the abc murders
> plague inc evolved
> pillars of eternity
> monochroma
> foosball
> superhot
> layers of fear
> glare
> space hilk ascension
> hitmango
> leisure suit larry reloaded
> action henk
> never alone kisima ingitchuna
> interplanetary
> cities skylines
> cities skylines snowfall
> cities in motion 2
> star horizon
> oddworld
> 
> 
> 
> 
> I tried to env variable: 
> R600_DEBUG=vs,tcs,tes,gs,ps,cs ./SUPERHOT.x86_64
> but there was no debug output (not like the variable with glxgears...)

I wanted to add The Longest Dark to your list as this seems very close to the
issues I'm having with it on Arch Linux. The strange thing is I'm experiencing
other, random OpenGL and radeon errors and bugs, with Unity x64 binaries being
the only ones that will no longer load, period. We have both a runtime and
native steam client on Arch and the 32bit blob for TLD does work after a very
slow start and long error output.

 Here's some basic system info:

OpenGL vendor string: X.Org
OpenGL renderer string: AMD CAPE VERDE (DRM 2.50.0 / 4.14.10-1-ARCH, LLVM
5.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.1
OpenGL core profile shading language version string: 4.50

-- 
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: [RFC HACK 1/2] gpu: drm: meson: HACK - Meson8/Meson8b/Meson8m2 support - WiP

[Neil Armstrong]

Hi Martin,

Thanks for the research !!!

Let me clarify this OSD1/2 stuff.

There is 2 OSD planes (that can get single-buffer input), and 2 Video plane 
that can get multi-planar video like YUV or NV12.
Only the OSD1 is enabled since it needs the Super Scaler in passthrought to 
automatically change the interlace field needed when you output in interlace 
mode on CVBS.

So :
- the OSD1 needs a CANVAS id where to get the data from, with other infos in 
the VIU_OSD1_BLK0_CFG_W0 reg
- the CANVAS id is only a logical id to define an entry in the CANVAS Manager 
where you can store every planes, so you only change the CANVAS ID in the 
VIU_OSD1_BLK0_CFG_W0 reg
- the Super Scaler needs a source to be configured from, my code is incorrect, 
I should not enable BIT(2), bits 0-1 should be 0
- The VPP_MISC register describes which OSD is enabled, and en eventual 
ordering, you may check in the kernel source if this register layout is the same

Looking at your code, you seem to still use ISD1, and only change a virtual 
logical CANVAS id, and you changed the Super Scaler register to use OSD2 as 
source, but it may be disabled.

Neil

On 01/01/2018 22:35, Martin Blumenstingl wrote:
> TODO:
> - canvas registers offsets on Meson8 / Meson8b are different
> - hardcoded register values
> - OSD2 is used for CVBS on Meson8 (at least on Meson8m2)
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../bindings/display/amlogic,meson-vpu.txt | 18 +-
>  drivers/gpu/drm/meson/meson_canvas.c   | 11 +
>  drivers/gpu/drm/meson/meson_canvas.h   |  4 ++--
>  drivers/gpu/drm/meson/meson_drv.c  |  3 +++
>  drivers/gpu/drm/meson/meson_plane.c|  5 ++--
>  drivers/gpu/drm/meson/meson_vclk.c | 21 ++--
>  drivers/gpu/drm/meson/meson_venc_cvbs.c|  5 +++-
>  drivers/gpu/drm/meson/meson_viu.c  |  5 +++-
>  drivers/gpu/drm/meson/meson_vpp.c  | 28 
> ++
>  9 files changed, 86 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt 
> b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
> index 00f74bad1e95..f416cdc88f25 100644
> --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
> @@ -53,6 +53,9 @@ VPU: Video Processing Unit
>  
>  Required properties:
>  - compatible: value should be different for each SoC family as :
> + - Meson8 (S802) : "amlogic,meson8-vpu"
> + - Meson8b (S805) : "amlogic,meson8b-vpu"
> + - Meson8m2 (S812) : "amlogic,meson8m2-vpu"
>   - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>   - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>   - GXM (S912) : "amlogic,meson-gxm-vpu"
> @@ -72,12 +75,15 @@ bindings specified in 
> Documentation/devicetree/bindings/graph.txt.
>  The following table lists for each supported model the port number
>  corresponding to each VPU output.
>  
> - Port 0  Port 1
> --
> - S905 (GXBB) CVBS VDAC   HDMI-TX
> - S905X (GXL) CVBS VDAC   HDMI-TX
> - S905D (GXL) CVBS VDAC   HDMI-TX
> - S912 (GXM)  CVBS VDAC   HDMI-TX
> + Port 0  Port 1
> +---
> + S802 (Meson8)   CVBS VDAC   not implemented yet
> + S805 (Meson8b)  CVBS VDAC   not implemented yet
> + S812 (Meson8m2) CVBS VDAC   not implemented yet

Maybe N/A is better.

> + S905 (GXBB) CVBS VDAC   HDMI-TX
> + S905X (GXL) CVBS VDAC   HDMI-TX
> + S905D (GXL) CVBS VDAC   HDMI-TX
> + S912 (GXM)  CVBS VDAC   HDMI-TX
>  
>  Example:
>  
> diff --git a/drivers/gpu/drm/meson/meson_canvas.c 
> b/drivers/gpu/drm/meson/meson_canvas.c
> index 08f6073d967e..cc741d06ccc4 100644
> --- a/drivers/gpu/drm/meson/meson_canvas.c
> +++ b/drivers/gpu/drm/meson/meson_canvas.c
> @@ -43,6 +43,17 @@
>  #define CANVAS_LUT_WR_EN(0x2 << 8)
>  #define CANVAS_LUT_RD_EN(0x1 << 8)
>  
> +u8 meson_canvas_id_osd1(struct meson_drm *priv)
> +{
> + if (meson_vpu_is_compatible(priv, "amlogic,meson8-vpu") ||
> + meson_vpu_is_compatible(priv, "amlogic,meson8b-vpu") ||
> + meson_vpu_is_compatible(priv, "amlogic,meson8m2-vpu")) {
> + return 0x43; // HACK: OSD1 = 0x40, OSD2 = 0x43
> + } else {
> + return 0x4e;
> + }
> +}

This canvas ID is purely logical and any number should work here, since this 
same number is used to update the OSD config register aswell.

> +
>  void meson_canvas_setup(struct meson_drm *priv,
>   uint32_t canvas_index, uint32_t addr,
>   uint32_t stride, uint32_t height,
> diff --git a/drivers/gpu/drm/meson/meson_canvas.h 
> 

[Bug 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.

[bugzilla-daemon]

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

--- Comment #12 from Kai-Heng Feng  ---
(In reply to Harry Wentland from comment #9)
> Created attachment 136321 [details] [review]
> DC scatter gather patch
> 
> You'll need this DC patch.

I can confirm that the issue is fixed by this patch (with the additional two
patches above).

Thanks.

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

Re: [PATCH] staging: vboxvideo adapt to new TTM interface

[Christian König]

Hi Roger,

you already pinged the right persons, just be a bit more patience about it.

They are probably just on vacation.

Regards,
Christian.

PS: Happy new year!

Am 02.01.2018 um 03:15 schrieb He, Roger:

+Alex

Do you know who can help about it?


Thanks
Roger(Hongbo.He)

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
He, Roger
Sent: Thursday, December 28, 2017 6:21 PM
To: dri-devel@lists.freedesktop.org; Bridgman, John ; Gregory, Robert 
; Khan, Tahir ; Shamim, Zafar 

Cc: hdego...@redhat.com; Koenig, Christian ; 
gre...@linuxfoundation.org
Subject: RE: [PATCH] staging: vboxvideo adapt to new TTM interface

Seems I have no permission to push the patch into amd-staging-drm-next.
Needs Whitelisted.

http://git.amd.com:8080/#/c/124051/1
anyone can help?

Thanks
Roger(Hongbo.He)
-Original Message-
From: Zhou, David(ChunMing)
Sent: Thursday, December 28, 2017 12:24 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: hdego...@redhat.com; gre...@linuxfoundation.org; Koenig, Christian 
; Zhou, David(ChunMing) 
Subject: Re: [PATCH] staging: vboxvideo adapt to new TTM interface

Reviewed-by: Chunming Zhou 


On 2017年12月28日 11:35, Roger He wrote:

Fixes interface change done in the following commit:
eb86c98 drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver

i missed this driver because it is in staging dir.

Signed-off-by: Roger He 
---
   drivers/staging/vboxvideo/vbox_ttm.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 231c89e..55f14c9 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -213,9 +213,10 @@ static struct ttm_tt *vbox_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
   }
   
-static int vbox_ttm_tt_populate(struct ttm_tt *ttm)

+static int vbox_ttm_tt_populate(struct ttm_tt *ttm,
+   struct ttm_operation_ctx *ctx)
   {
-   return ttm_pool_populate(ttm);
+   return ttm_pool_populate(ttm, ctx);
   }
   
   static void vbox_ttm_tt_unpopulate(struct ttm_tt *ttm)

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


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

Re: [PATCH] drm/ttm: optimize errors checking and free _manager when finishing

[Christian König]

Am 02.01.2018 um 04:05 schrieb He, Roger:


-Original Message-
From: Xiongwei Song [mailto:sxwj...@gmail.com]
Sent: Sunday, December 31, 2017 7:40 PM
To: Koenig, Christian ; He, Roger 
; airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: [PATCH] drm/ttm: optimize errors checking and free _manager when 
finishing

In the function ttm_page_alloc_init, kzalloc call is made for variable 
_manager, we need to check its return value, it may return NULL.

In the function ttm_page_alloc_fini, we need to call kfree for variable 
_manager, instead of make _manager NULL directly.

Signed-off-by: Xiongwei Song 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba6441489f..e20a0b8e352b 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1007,6 +1007,10 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
pr_info("Initializing pool allocator\n");
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);

+   if (!_manager) {
+   ret = -ENOMEM;
+   goto out;
+   }
Seems we only need above here for this patch I think.
The rest is no need, because ttm_pool_kobj_release will kfree _manager.


Yes, agree. Freeing it again in ttm_page_alloc_fini will actually double 
free the memory and probably cause some problems.


Please refine the patch with only the additional error handling.

Regards,
Christian.




Thanks
Roger(Hongbo.He)

ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
@@ -1034,13 +1038,17 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)

   >kobj, "pool");
if (unlikely(ret != 0)) {
kobject_put(&_manager->kobj);
-   _manager = NULL;
-   return ret;
+   goto out_free_mgr;
}
  
  	ttm_pool_mm_shrink_init(_manager);
  
  	return 0;

+out_free_mgr:
+   kfree(_manager);
+   _manager = NULL;
+out:
+   return ret;
  }
  
  void ttm_page_alloc_fini(void)

@@ -1055,6 +1063,7 @@ void ttm_page_alloc_fini(void)
ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES, true);
  
  	kobject_put(&_manager->kobj);

+   kfree(_manager);
_manager = NULL;
  }
  
--

2.15.1



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

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

[Christian König]

Am 01.01.2018 um 19:08 schrieb Ilia Mirkin:

On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith  wrote:

On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote:

On Tue, Dec 19, 2017 at 8:45 AM, Christian König
 wrote:

Am 19.12.2017 um 11:39 schrieb Michel Dänzer:

On 2017-12-19 11:37 AM, Michel Dänzer wrote:

On 2017-12-18 08:01 PM, Tobias Klausmann wrote:

On 12/18/17 7:06 PM, Mike Galbraith wrote:

Greetings,

Kernel bound workloads seem to trigger the below for whatever reason.
I only see this when beating up NFS.  There was a kworker wakeup
latency issue, but with a bandaid applied to fix that up, I can still
trigger this.


Hi,

i have seen this one as well with my system, but i could not find an
easy way to trigger it for bisecting purpose. If you can trigger it
conveniently, a bisect would be nice!

I'm seeing this (with the amdgpu and radeon drivers) when restic takes a
backup, creating memory pressure. I happen to have just finished
bisecting, the result is:

648bc3574716400acc06f99915815f80d9563783 is the first bad commit
commit 648bc3574716400acc06f99915815f80d9563783
Author: Christian König 
Date:   Thu Jul 6 09:59:43 2017 +0200

  drm/ttm: add transparent huge page support for DMA allocations v2

  Try to allocate huge pages when it makes sense.

  v2: fix comment and use ifdef



BTW, I haven't noticed any bad effects other than the dmesg splats, so
maybe it's just noise about transient failures for which there is a
proper fallback in place.


Yeah, I think that is exactly what happens here.

We try to allocate a huge page, but fail and so fall back to using multiple
4k pages instead.

Going to send out a patch to suppress the warning.

Hi Christian,

Did you ever send out such a patch? I didn't see one on the list, but
perhaps I missed it. One definitely hasn't made it upstream yet. (I
just hit the issue myself with Linus's tree from last night.)

Actually, that wants a bit more methinks, because while the stack dump
goes away, you still get spammed, it just comes in smaller chunks.

OK, well this has to either be fixed or reverted. Right now it's
complaining all the time for me after like a day of uptime.


I've already send out a patch to Konrad Rzeszutek Wilk and he wanted to 
queue that up.


But there is another warning I'm currently working on, just didn't had 
time to during the holidays.


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

Re: [PATCH v4 3/3] drm/tinydrm: add driver for ST7735R panels

[Linus Walleij]

On Mon, Jan 1, 2018 at 8:02 PM, David Lechner  wrote:

> This adds a new driver for Sitronix ST7735R display panels.
>
> This has been tested using an Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner 
> Reviewed-by: Noralf Trønnes 

Reviewed-by: Linus Walleij 

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

Re: [PATCH v4 2/3] dt-bindings: Add binding for Sitronix ST7735R display panels

[Linus Walleij]

On Mon, Jan 1, 2018 at 8:02 PM, David Lechner  wrote:

> This adds a new device tree binding for Sitronix ST7735R display panels,
> such as the Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner 
> Reviewed-by: Rob Herring 

Reviewed-by: Linus Walleij 

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

[GIT PULL] imx-drm format modifier support

[Philipp Zabel]

Hi Dave,

Happy New Year! Please consider merging this tag, which adds format modifier
support to allow direct scanout from Vivante tiled buffers on i.MX6QP SoCs.
To improve build coverage, ipu-v3 can now be enabled under COMPILE_TEST.

regards
Philipp

The following changes since commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b:

  Linux 4.15-rc4 (2017-12-17 18:59:59 -0800)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2018-01-02

for you to fetch changes up to 4cfea3c1f2718d945ca44c1aaac47d8d513c4478:

  gpu: ipu-v3: allow to build with COMPILE_TEST (2017-12-19 12:49:11 +0100)


drm/imx: format modifier support

- Add tiled prefetch support to PRE
- Add format modifier support to PRG and imx-drm-core
- Use runtime PM to control PRG clock
- Allow building ipu-v3 under COMPILE_TEST


Lucas Stach (5):
  gpu: ipu-v3: prg: switch to runtime PM
  gpu: ipu-v3: pre: add tiled prefetch support
  gpu: ipu-v3: prg: add modifier support
  drm/imx: add FB modifier support
  drm/imx: advertise supported plane format modifiers

Philipp Zabel (1):
  gpu: ipu-v3: allow to build with COMPILE_TEST

 drivers/gpu/drm/imx/imx-drm-core.c |   1 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 102 ++---
 drivers/gpu/ipu-v3/Kconfig |   4 +-
 drivers/gpu/ipu-v3/ipu-cpmem.c |   1 +
 drivers/gpu/ipu-v3/ipu-ic.c|   1 +
 drivers/gpu/ipu-v3/ipu-pre.c   |  29 +--
 drivers/gpu/ipu-v3/ipu-prg.c   |  84 +-
 drivers/gpu/ipu-v3/ipu-prv.h   |   4 +-
 include/video/imx-ipu-v3.h |   2 +-
 9 files changed, 189 insertions(+), 39 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel