Hi all.
> Commit
>
> 94520db52fc0 ("drm: fix alpha build after drm_util.h change")
>
> has a malformed Fixes tag:
>
> Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
>
> The SHA1 does not reference a commit currently in the tree. Maybe it
> was meant to be e9eafcb58921.
On Mon, Jan 14, 2019 at 3:29 PM Mathieu Malaterre wrote:
>
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> this place in the code produced a warning (W=1).
>
> This commit remove the following warning:
>
> drivers/gpu/drm/radeon/evergreen_cs.c:1301:11: warning: this state
On Tue, Jan 15, 2019 at 2:58 AM Gustavo A. R. Silva
wrote:
>
> Replace kzalloc() function with its 2-factor argument form, kcalloc().
>
> This patch replaces cases of:
>
> kzalloc(a * b, gfp)
>
> with:
> kcalloc(a, b, gfp)
>
> Also, improve the coding style and the use of sizeof du
https://bugs.freedesktop.org/show_bug.cgi?id=108827
Andre Klapper changed:
What|Removed |Added
Version|XOrg git|unspecified
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Andre Klapper changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
The kerneldoc comment for struct dma_fence_array lacks a description
of the "work" member, leading to this docs-build warning:
./include/linux/dma-fence-array.h:54: warning: Function parameter or member
'work' not described in 'dma_fence_array'
Add a description and make the warning go away.
Daniel Vetter writes:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> concerns raised in the RFC discussions).
>
On Wednesday, January 16, 2019 7:42:45 PM CET Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 11:47 PM Rafael J. Wysocki wrote:
> >
> > [CC Greg]
> >
> > On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote:
> > > [CC Lukas and linux-pm]
> > >
> > > On Mon, Jan 14, 2019 at 1:32 PM Ra
Hi Dave, Daniel,
Fixes for 5.0:
- Fix KFD on ARM64
- Fix KFD topology with mixed APU and dGPU systems
- Powerplay fix for vega12
- DC Raven fixes
- Freesync fix
The following changes since commit e2d3c414ec0f9d1557c8c5ff2c32166e68bbc4ad:
Merge tag 'drm-intel-fixes-2019-01-11' of
git://anongit
s
On Wed, Jan 16, 2019 at 1:46 PM Douglas Anderson wrote:
>
> The bindings for Qualcomm opp levels changed after being Acked but
> before landing. Thus the code in the GPU driver that was relying on
> the old bindings is now broken.
>
> Let's change the code to match the new bindings by adjustin
On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
> > > As far as I know Power doesn't really supports un-cached memory at all,
> > > except for a very very old and odd configuration with AGP.
> >
> > Hopefully Michael/Ben can elaborate here, but I was under the (possibly
> > mistaken) i
Before the driver fully moved to drm_bridge and drm_panel, it was
necessary to parse DT and locate encoder and connector nodes. The
connector node is now unused and can be removed as a parameter to
rcar_du_encoder_init(). As a consequence rcar_du_encoders_init_one() can
be greatly simplified, remov
Hello,
This series adds support for the DPAD0 output for the D3 and E3 SoCs. On
the Draak and Ebisu boards, DPAD0 is used for the VGA output.
Patches 1/6 and 2/6 prepare the grounds by successfully probing LVDS
encoders that have no connected output. This is required in order to
provide a dot clo
On the D3 and E3 SoCs the LVDS encoder has an extended internal PLL and
supplies a clock to the DU. That clock is used not only for the LVDS
outputs but also for the DPAD output. The LVDS encoder thus needs to be
available to the DU even when its output is disabled. Don't fail probe
in that cose on
On the D3 and E3 SoCs the LVDS PLL clock output provides the dot clock
to the DU channels, even when the LVDS outputs are not in use. Enable
and disable the LVDS clock output when enabling or disabling a CRTC
connected to the DPAD0 output.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar
https://bugs.freedesktop.org/show_bug.cgi?id=109229
--- Comment #7 from smt ---
Created attachment 143144
--> https://bugs.freedesktop.org/attachment.cgi?id=143144&action=edit
apitrace of godot including glLinkProgram lock up
I don't know how useful this is in this situation and I haven't done
The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
output when the LVDS0 encoder is used. Enable it despite its output not
being connected.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arc
On the D3 and E3 platforms, the LVDS internal PLL supplies the pixel
clock to the DU. This works automatically for LVDS outputs as the LVDS
encoder is enabled through the bridge API, enabling the internal PLL and
clock output. However, when using the DU DPAD output with the LVDS
outputs turned off,
The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
output when the LVDS0 encoder is used. Enable it despite its output not
being connected.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arc
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_gem.c
between commit:
dd847a706974 ("drm/i915: Compile fix for 64b dma-fence seqno")
from the drm tree and commit:
9f58892ea996 ("drm/i915: Pull all the reset functionality together into
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
wrote:
>
> On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > Again, I cannot help you without the datasheet for the panels
> > > > > > > you're
> > > > > > > trying to submit.
> > > > > >
> > > > > > The panel bound with Sitro
On Wed, 2019-01-16 at 07:35 +, Koenig, Christian wrote:
> No, but you answer the wrong question.
>
> See we don't want to have different mappings of cached and non-cached on
> the CPU, but rather want to know if a snooped DMA from the PCIe counts
> as cached access as well.
>
> As far as I
On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote:
> > As far as I know on x86 it doesn't, so when you have an un-cached page
> > you can still access it with a snooping DMA read/write operation and
> > don't cause trouble.
> >
>
> I think it is the other way around. The question is, on an
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On 01/11/2019 05:03 PM, Andrey Grodzovsky wr
101 - 124 of 124 matches
Mail list logo
