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
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
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 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
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
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
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,
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
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 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
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
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
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
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).
>
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.
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Andre Klapper changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=108827
Andre Klapper changed:
What|Removed |Added
Version|XOrg git|unspecified
Resolution|FIXED
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
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
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.
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
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
Commit 24937c540917 ("dt-bindings: drm/msm/a6xx: Document GMU and update
GPU bindings") mistakenly omitted the GMU bindings as seen in [1].
Return them to their rightful place.
[1] https://patchwork.freedesktop.org/patch/268679/
Signed-off-by: Jordan Crouse
Reviewed-by: Rob Herring
---
.../de
On Mon, 14 Jan 2019 09:43:28 +, wrote:
> From: Cristian Birsan
>
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
> Adding Device Tree bindings for this panel.
>
> Signed-off-by: Cristian Birsan
>
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #7 from Hans D ---
Can confirm that enabling redshift causes occasional stutters every 2-4 seconds
with amdgpu.dc=1 with linux 5.0rc2. Without redshift everything (scrolling in
browser, video playback)is buttery smooth. With amdgpu.
https://bugs.freedesktop.org/show_bug.cgi?id=109331
andrew.m.mcma...@gmail.com changed:
What|Removed |Added
Blocks||77449
Version|18
Since modesetting locks by default were added to private objects in:
commit b962a12050a3 ("drm/atomic: integrate modeset lock with private
objects")
This means that the atomic state of a drm_dp_mst_topology_mgr is now
protected by drm_dp_mst_topology_mgr->base.lock as opposed to the main
connecti
This is a very minute issue I introduced that I just noticed when
scrolling through drm_dp_mst_topology.c: if a driver uses
drm_dp_atomic_find_vcpi_slots() incorrectly, we'll forget to release the
topology reference we grabbed on port.
So, fix this by jumping to 'out' instead of returning -EINVAL
Another drive-by fix. If slots < 0, or drm_dp_init_vcpi() fails, we'll
end up returning from the function without dropping the topology ref
that we grabbed at the very start. This would result in an MST hub
and/or it's ports staying around even after the MST topology has been
removed from the syste
Two not terribly important fixes, and one actually important fix. Should
be pretty easy to review :)
Lyude Paul (3):
drm/dp_mst: Remove lock check in drm_atomic_get_mst_topology_state()
drm/dp_mst: Fix potential topology ref leak in
drm_dp_atomic_find_vcpi_slots()
drm/dp_mst: Fix topolog
Adam Jackson writes:
> If the kernel wanted to expose its quirks db somehow the library could
> certainly be taught to use it. However there are likely to be quirks
> relevant only to userspace (see below), making the kernel carry that
> doesn't make a ton of sense.
We do expose some of the quir
Hi Daniel, Dave,
Here is a re-run of the previous drm-misc-next as asked by Daniel.
Thanks!
Maxime
drm-misc-next-2019-01-16:
drm-misc-next for 5.1:
UAPI Changes:
- New fourcc identifier for ARM Framebuffer Compression v1.3
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_devic
On Wed, Jan 16, 2019 at 10:46:21AM -0800, 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 adj
On Wed, 2019-01-16 at 20:35 +0200, Pekka Paalanen wrote:
> I would agree with an effort to establish a userspace EDID parsing
> library in any case. As mentioned above, there will probably be too
> much to expose via kernel UABI, or it will become just another
> encoded format that again should ha
Hi Priit,
On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote:
> > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > to initialize properly every 6-7 boots. The display itself is also
> > > somewhat fla
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 Sitronix ST7701 IC
> > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/201
On Sun, Jan 13, 2019 at 09:47:44AM +0100, Julia Lawall wrote:
> The device node iterators perform an of_node_get on each
> iteration, so a jump out of the loop requires an of_node_put.
>
> Remote and port also have augmented reference counts, so drop them
> on each iteration and at the end of the
On Wed, Jan 16, 2019 at 3:06 PM Linus Walleij wrote:
>
> Hi, I am using drm_simple_kms_helper and writing a new driver.
>
> The code is here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=ux500-mcde
> It's starting to look acceptable, but I just don't wanna p
Hi,
On Wed, Jan 16, 2019 at 10:03 AM Jordan Crouse wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices for sdm845.
>
> Signed-off-by: Jordan Crouse
> Reviewed-by: Douglas Anderson
> Tested-by: Douglas Anderson
> ---
> This has the following dependencies:
>
> [v11,1/9] dt-bindin
https://bugs.freedesktop.org/show_bug.cgi?id=108711
--- Comment #1 from mittorn ---
Re-uploaded traces here
http://mittorn.the-swank.pp.ua/xash64.1.trace.xz
http://mittorn.the-swank.pp.ua/xash64.trace.xz
--
You are receiving this mail because:
You are the assignee for the bug.__
On Wed, Jan 16, 2019 at 08:35:26PM +0200, Pekka Paalanen wrote:
> On Mon, 7 Jan 2019 17:07:09 +
> Brian Starkey wrote:
>
> > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > > Daniel Vetter writes:
> > >
> > > > Best to pull in some other compositor people and get them t
On Tue, Jan 8, 2019 at 5:47 PM Otto Sabart wrote:
>
> The primecell.txt and cpus.txt files were converted into YAML. This
> patch updates old references with new ones.
>
> Fixes: d3c207eeb905 ("dt-bindings: arm: Convert primecell binding to
> json-schema")
> Fixes: 672951cbd1b7 ("dt-bindings: arm
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #23 from Alex Deucher ---
(In reply to iive from comment #22)
>
> It is code refactoring. It doesn't remove, add or modify any functionality.
> It just changes how some functions are called. (1 function pointer and
> switch/case, in
The patch ("OPP: Add support for parsing the 'opp-level' property")
adds an API enabling a cleaner way to read the opp-level. Let's use
the new API.
Signed-off-by: Douglas Anderson
Reviewed-by: Jordan Crouse
---
Obviously this can't land until we have a tree that contains the patch
adding the A
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 adjusting the old
string 'qcom,level' to the new string 'opp-level'. See the p
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 Rafael J. Wysocki wrote:
> > >
> > > On Fri, Jan 11, 2019 at 3:49 PM Russell King -
On Mon, 7 Jan 2019 17:07:09 +
Brian Starkey wrote:
> On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter writes:
> >
> > > Best to pull in some other compositor people and get them to agree. From a
> > > kernel pov I'm fine with whatever userspace preferes.
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).
- tests reorganized into subdirecto
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #103 from Hans D ---
With the latest xf86 DDX driver 3d works better in amdgpu.dc=0, but still lags,
even though a built-in counter is showing high fps. Does amdgpu.dc=1 improve
3d performance that much?
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=202261
--- Comment #5 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
With the change from
https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html see
bug seems to be fixed. I've not encountered any Oops since testing with this
Hi Daniel.
> v5: Actually try to sort them, and while at it, sort all the ones I
> touch.
Applied this variant on top of drm-misc and did a build test.
Looked good for ia64, x86 and alpha.
Took a closer look at the changes to atmel_hlcd - and they looked OK.
But I noticed that atmel_hlcdc uses
Add the nodes to describe the Adreno GPU and GMU devices for sdm845.
Signed-off-by: Jordan Crouse
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
---
This has the following dependencies:
[v11,1/9] dt-bindings: opp: Introduce opp-level bindings
https://patchwork.kernel.org/patch/10755
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #22 from i...@yahoo.com ---
(In reply to Alex Deucher from comment #21)
> (In reply to iive from comment #20)
> > Anyway, bisect was done successfully.
> >
> > I just still kind of don't understand why it landed on that commit.
> > I
On Mon, Jan 14, 2019 at 03:16:54PM -0700, Jason Gunthorpe wrote:
> On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> > On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote:
> > > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > > > On Fri, Jan 04, 2019 at
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 wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>> The heap name can be used for debugging but otherwise does not seem
>> to be required and no other part of the code will fail if left NULL
>> except here. We can make it re
On 1/16/19 9:19 AM, Brian Starkey wrote:
> Hi :-)
>
> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
>>> On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> On 1/14/19 11:13 AM, Liam Mark
Hi,
On Wed, 2019-01-16 at 09:24 -0500, Rob Clark wrote:
> So, I guess this is to do w/ the magic of merge commits, but it looks
> like the hunk changing the crtc_ww_class got lost:
So what happened here is that this commit changed it to
DEFINE_WD_CLASS
and the following commit changed it back ag
On 01/07/2019 11:35 AM, Peter Rosin wrote:
> On 2019-01-07 10:11, Geert Uytterhoeven wrote:
>> Hi Peter,
>>
>> On Mon, Jan 7, 2019 at 10:03 AM Peter Rosin wrote:
>>> On 2019-01-07 09:59, Peter Rosin wrote:
On 2019-01-07 09:40, Geert Uytterhoeven wrote:
> On Mon, Jan 7, 2019 at 9:26 AM Pe
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #21 from Alex Deucher ---
(In reply to iive from comment #20)
> Anyway, bisect was done successfully.
>
> I just still kind of don't understand why it landed on that commit.
> It doesn't look like this is the commit that changes the
On Wed, Jan 16, 2019 at 04:27:58PM +0100, Lucas Stach wrote:
> The Vivante GPU cores are found in many different SoCs and the driver
> does not depend on anything architecture specific, so just drop the
> architecture restriction.
>
> Signed-off-by: Lucas Stach
For good measure I throwed this af
On Wed, 16 Jan 2019 at 16:06, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> > To summarize once more: We have an array of struct pages and want to
> > coherently map that to a device.
>
> And the answer to that is very simple: you can't. What is so hard
Am Mittwoch, den 16.01.2019, 08:21 -0800 schrieb Christoph Hellwig:
> On Mon, Jan 14, 2019 at 07:31:57PM +0300, Eugeniy Paltsev wrote:
> > ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC.
> >
> > Signed-off-by: Eugeniy Paltsev
> > ---
> > drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> >
On Mon, Jan 14, 2019 at 07:31:57PM +0300, Eugeniy Paltsev wrote:
> ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
On 1/15/19 1:11 PM, Laura Abbott wrote:
> On 1/15/19 10:43 AM, Laura Abbott wrote:
>> On 1/15/19 7:58 AM, Andrew F. Davis wrote:
>>> On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
> The "unmapped" heap is very similar to the carveout heap except
> t
On 1/15/19 1:05 PM, Laura Abbott wrote:
> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may no
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #9 from Emre Işık (e.isi...@gmail.com) ---
Thank you, too, for writing the patch so quickly.
It has been a great pleasure to cooperate with you, Alex Deucher.
It's a great thing helping other people's.
Which u a nice day!
Best regar
On Tue, Jan 15, 2019 at 02:25:01PM -0700, Jason Gunthorpe wrote:
> RDMA needs something similar as well, in this case drivers take a
> struct page * from get_user_pages() and need to have the DMA map fail
> if the platform can't DMA map in a way that does not require any
> additional DMA API calls
On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> To summarize once more: We have an array of struct pages and want to
> coherently map that to a device.
And the answer to that is very simple: you can't. What is so hard
to understand about? If you want to map arbitrary memory
On 1/15/19 12:58 PM, Laura Abbott wrote:
> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current s
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Emre Işık from comment #7)
> Thanks for the patch.
> Do you gonna commit this patch to the official kernel?
> Maybe others have the same error like me.
Yes, I'll make sure
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 wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
Am 11.01.19 um 16:37 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 wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
On 01/11/2019 04:42 AM, Koenig, Christian wro
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #3 from Rafał Miłecki ---
It didn't apply cleanly on top of 5.0.0-rc2 (a trivial conflict in the
dc_link.c.rej). After fixing that, compiling & testing I can confirm is solves
the problem for me! Thanks!
Before suspend:
> cat /sys/c
On Wed, Jan 16, 2019 at 11:04:40AM +0100, Daniel Vetter wrote:
> The fbdev subsystem is closed for new drivers, those need to become
> drm ones (which generally results in smaller drivers nowadays, with
> the massive amounts of shared infrastructure and helper libraries drm
> has).
>
> Although gi
Am Montag, den 14.01.2019, 13:49 +0300 schrieb Dan Carpenter:
> The etnaviv_gem_get_pages() never returns NULL. It returns error
> pointers on error.
>
> Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver")
> Signed-off-by: Dan Carpenter
Thanks, applied to etnaviv/next.
> ---
>
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
> The heap name can be used for debugging but otherwise does not seem
> to be required and no other part of the code will fail if left NULL
> except here. We can make it required and check for it at some point,
> for now l
The Vivante GPU cores are found in many different SoCs and the driver
does not depend on anything architecture specific, so just drop the
architecture restriction.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/et
Hi :-)
On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> > On 1/15/19 11:45 AM, Liam Mark wrote:
> >> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> >>
> >>> On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Da
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #2 from Leo Li ---
Created attachment 143141
--> https://bugs.freedesktop.org/attachment.cgi?id=143141&action=edit
drm/amd/display: Detach backlight from stream
Hi Rafał,
Please give the attached patch a shot. It's in our staging
https://bugs.freedesktop.org/show_bug.cgi?id=109370
MIka R changed:
What|Removed |Added
Severity|minor |normal
Priority|low
On Fri, 11 Jan 2019 14:29:28 +
Peter Rosin wrote:
> On 2019-01-10 20:25, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 18:51:21 +
> > Peter Rosin wrote:
> >
> >> On 2019-01-10 18:29, Boris Brezillon wrote:
> >>> On Thu, 10 Jan 2019 15:10:48 +
> >>> Peter Rosin wrote:
> >>>
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #20 from i...@yahoo.com ---
(In reply to Alex Deucher from comment #12)
> (In reply to iive from comment #10)
[...]
> > Most of the new changes are done before RC1 and it is quite common that
> > there are major breakages there, in sy
So, I guess this is to do w/ the magic of merge commits, but it looks
like the hunk changing the crtc_ww_class got lost:
~/src/linux master git show --pretty=short
08295b3b5beec9aac0f7a9db86f0fc3792039da3
drivers/gpu/drm/drm_modeset_lock.c
commit 08295b3b5beec9aac0f7a9db86f0fc3792039da3
Au
Hi, I am using drm_simple_kms_helper and writing a new driver.
The code is here:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=ux500-mcde
It's starting to look acceptable, but I just don't wanna post the driver
until I get a clean probe.
This is using a comman
https://bugs.freedesktop.org/show_bug.cgi?id=108940
--- Comment #14 from H.Habighorst ---
Can confirm.
But I'm a bit worried - there is a part before the "core_link_enable_stream"
that seems wrong to me in initializing the device, which seems to occure in all
dmesg outputs.
I've attached line
https://bugs.freedesktop.org/show_bug.cgi?id=108940
H.Habighorst changed:
What|Removed |Added
CC||h.habigho...@protonmail.com
--- Comment
On Wed, Jan 16, 2019 at 12:28:00PM +0100, Gerd Hoffmann wrote:
> > > +static int qxl_check_mode(struct qxl_device *qdev,
> > > + unsigned int width,
> > > + unsigned int height)
> > > +{
> > > + if (width * height * 4 > qdev->vram_size)
> >
> > Is someone checki
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:54:08AM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if
On Monday, January 7, 2019 3:21:49 PM CET Rafael J. Wysocki wrote:
> On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot
> wrote:
> >
> > Hi Tvrtko,
> >
> > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 21/12/2018 13:26, Vincent Guittot wrote:
> > > > On Fri, 21 Dec 2018
On Wed, Jan 16, 2019 at 11:40:41AM +, Emil Velikov wrote:
> On 2019/01/14, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > Currently we fail to free and detach the drm_file when drm_setup() fails.
> > > Use the drm_cl
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently we fail to free and detach the drm_file when drm_setup() fails.
> > Use the drm_close_helper to do address that.
> >
> > Signed-off-by: Emil Velikov
> > -
https://bugzilla.kernel.org/show_bug.cgi?id=202263
Emre Işık (e.isi...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolut
> > +static int qxl_check_mode(struct qxl_device *qdev,
> > + unsigned int width,
> > + unsigned int height)
> > +{
> > + if (width * height * 4 > qdev->vram_size)
>
> Is someone checking for integer overflows already?
Need to have a look. This is just .
Am 15.01.19 um 22:25 schrieb Jason Gunthorpe:
On Tue, Jan 15, 2019 at 02:17:26PM +, Thomas Hellstrom wrote:
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
Changes since the RFC:
- Rework vmwgfx to
On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> It's a debug hack flag useful to work around driver bugs. That's not a
> good idea for a new driver. Especially for a new drm driver.
>
> Aside: the fbdev support should probably be converted over to the new
> generic fbdev support.
On Wed, Jan 16, 2019 at 09:47:17AM +0200, Jani Nikula wrote:
> On Tue, 15 Jan 2019, Lyude Paul wrote:
> > Something that I completely missed when implementing the new MST VCPI
> > atomic helpers is that with those helpers, there's technically a chance
> > of us having to grab additional modeset lo
1 - 100 of 124 matches
Mail list logo
