Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
1 file changed, 132
Add necessary device tree nodes for the main LCD backlight.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
Use drm_atomic_helper_dirtyfb() as the dirty callback in the
msm_framebuffer_funcs struct. Call drm_plane_enable_fb_damage_clips()
when the planes are initialized in mdp4, mdp5, and dpu1.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++
The mdp5 drm/kms driver currently does not work on command-mode DSI
panels due to 'vblank wait timed out' errors. This causes a latency
of seconds, or tens of seconds in some cases, before content is shown
on the panel. This hardware does not have the something that we can use
as a frame counter
Add the CMA (Contiguous Memory Allocator) for the MSM DRM/KMS driver,
the simple panel, and the TI LM3630A driver in order to support the
display on the LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
arch/arm/configs/qcom_defconfig | 5 +
1 file
Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 58 +++
1 file changed, 58 insertions(+)
diff --git
This patch series adds working display support to the LG Nexus 5
(hammerhead) phone.
Changes since v2:
- Dropped two drm/msm bug fix patches that have been merged separately.
- New patch: 'add support for per-CRTC max_vblank_count on mdp5'.
Special thanks to Jeffrey Hugo for helping to track
Hi all,
In commit
137caa702f23 ("drm/imx: ipuv3-plane: fix atomic update status query for
non-plus i.MX6Q")
Fixes tag
Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic
update status")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be
On Fri, May 31, 2019 at 12:28 PM Maxime Ripard
wrote:
>
> Hi,
>
> On Wed, May 29, 2019 at 04:26:06PM +0530, Jagan Teki wrote:
> > This is v9 version for Allwinner A64 MIPI-DSI support
> > and here is the previous version set[1].
> >
> > This depends on dsi host controller fixes which were
> >
Hi,
On Wed, May 29, 2019 at 04:26:06PM +0530, Jagan Teki wrote:
> This is v9 version for Allwinner A64 MIPI-DSI support
> and here is the previous version set[1].
>
> This depends on dsi host controller fixes which were
> supported in this series[2].
>
> All these changes are tested in Allwinner
On Wed, May 29, 2019 at 04:26:07PM +0530, Jagan Teki wrote:
> The MIPI DSI controller in Allwinner A64 is similar to A33.
>
> But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
> to with separate compatible for A64 on the same driver.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Rob
On Wed, May 29, 2019 at 04:26:08PM +0530, Jagan Teki wrote:
> The MIPI DSI PHY controller on Allwinner A64 is similar
> on the one on A31.
>
> Add A64 compatible and append A31 compatible as fallback.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Rob Herring
> ---
>
On Fri, May 31, 2019 at 12:29 PM Maxime Ripard
wrote:
>
> On Wed, May 29, 2019 at 04:26:07PM +0530, Jagan Teki wrote:
> > The MIPI DSI controller in Allwinner A64 is similar to A33.
> >
> > But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
> > to with separate compatible for A64 on
On Wed, 29 May 2019, Mauro Carvalho Chehab wrote:
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
> return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
>
Quoting Mauro Carvalho Chehab (2019-05-30 02:23:43)
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
> return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #8 from Richard Thier ---
I became a bit uncertain now as after every bisect I am choosing "git
bisect bad" and see no change so far. There is 4 more bisect to do
still, but I expected at least one change so far.
Maybe it is in
https://bugs.freedesktop.org/show_bug.cgi?id=110803
Bug ID: 110803
Summary: Coruption and flickering on polaris with mesa 19.0.5
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Quoting Colin King (2019-05-31 11:32:01)
> From: Colin Ian King
>
> The assignment of err is using the incorrect pointer vaddr that has
> not been initialized. Fix this by using the correct pointer obj instead.
>
> Addresses-Coverity: ("Uninitialized pointer read")
> Fixes: 6501aa4e3a45
On 31/05/2019 14:09, Tomeu Vizoso wrote:
> On Fri, 31 May 2019 at 14:03, Neil Armstrong wrote:
>>
>> Hi Tomeu,
>>
>> On 31/05/2019 13:59, Tomeu Vizoso wrote:
>>> On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
Hi,
I have rebase my kernel on latest 5.2-rc2, and my panfrost
On Tue, May 28, 2019 at 10:53 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 28/05/2019 18:09, Adam Ford wrote:
> > On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen
> > wrote:
> >>
> >> Hi,
> >>
> >> On 10/05/2019 22:42, Adam Ford wrote:
> >>> Currently the source code is compiled using hard-coded
On 30/05/2019 00:55, Sebastian Reichel wrote:
Oh sorry, I missed the part that omap_irq_wait_init() actually
enables the framedone irq. It should be enough to just drop the
warning (and the curly brackets) to keep existing behaviour. The
code exits early with the above warning for any existing
On Wed, 29 May 2019 at 11:18, Boris Brezillon
wrote:
>
> mmu_ops->unmap() will fail when called on a BO that has not been
> previously mapped, and the error path in panfrost_ioctl_create_bo()
> can call drm_gem_object_put_unlocked() (which in turn calls
> panfrost_mmu_unmap()) on a BO that has
On 27.05.2019 15:47, Jyri Sarha wrote:
> I think these should be ready for applying to drm-misc.
>
> Changes since v7:
> - Debased on top of the lasts drm-misc-next and tested
> - "dt-bindings: display: sii902x: Add HDMI audio bindings"
>- Dropped off "or higher to avoid conflict with video
Hi,
[add Daniel Vetter]
[cc dri-devel]
Den 29.05.2019 15.09, skrev Pierre Yves MORDRET:
> Hello Noralf,
>
> Sorry for bothering you with question but I need to better understand the
> rational about a patch you did in DRM/GEM.
>
> First of all, let me introduce myself.
> I'm currently employee
https://bugs.freedesktop.org/show_bug.cgi?id=110730
Lakshmi changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=110730
--- Comment #4 from Lakshmi ---
Moving to IGT to fix the test.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0
Hello,
On Mon, May 27, 2019 at 06:22:31PM +0200, megous via linux-sunxi wrote:
> From: Ondrej Jirman
>
> This series implements support for Xunlong Orange Pi 3 board.
>
> Unfortunately, this board needs some small driver patches, so I have
> split the boards DT patch into chunks that require
On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes wrote:
>
> Hi,
>
> [add Daniel Vetter]
> [cc dri-devel]
>
> Den 29.05.2019 15.09, skrev Pierre Yves MORDRET:
> > Hello Noralf,
> >
> > Sorry for bothering you with question but I need to better understand the
> > rational about a patch you did in
On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
>
> Hi,
>
> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
> no more probing.
>
> The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e
> drm/panfrost: Select devfreq
>
> Currently, there is some logic
On Fri, 31 May 2019 at 14:03, Neil Armstrong wrote:
>
> Hi Tomeu,
>
> On 31/05/2019 13:59, Tomeu Vizoso wrote:
> > On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
> >>
> >> Hi,
> >>
> >> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
> >> no more probing.
> >>
> >> The
On 28.05.2019 10:27, Tomi Valkeinen wrote:
> Add support for interrupt and hotplug handling. Both are optional.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v7: Export drm_client_panel_rotation() (Gerd Hoffmann)
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h
From: Colin Ian King
The assignment of err is using the incorrect pointer vaddr that has
not been initialized. Fix this by using the correct pointer obj instead.
Addresses-Coverity: ("Uninitialized pointer read")
Fixes: 6501aa4e3a45 ("drm/i915: add in-kernel blitter client")
Signed-off-by:
Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
on Amlogic S912 SoCs missin the "operating-points-v2" property.
Make it optional again, leaving PM_DEVFREQ is selected by default.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Neil Armstrong
---
https://bugs.freedesktop.org/show_bug.cgi?id=110361
Lakshmi changed:
What|Removed |Added
Component|DRM/Intel |IGT
QA
Am 29.05.19 um 18:29 schrieb Emil Velikov:
> On 2019/05/29, Koenig, Christian wrote:
>> Am 29.05.19 um 15:03 schrieb Emil Velikov:
>>> On 2019/05/29, Dave Airlie wrote:
On Wed, 29 May 2019 at 02:47, Emil Velikov
wrote:
> On 2019/05/28, Koenig, Christian wrote:
>> Am 28.05.19 um
On 28.05.2019 10:27, Tomi Valkeinen wrote:
> Hi,
>
> tc358767 bridge was originally implemented for eDP use with an embedded
> panel. I've been working to add DP and HPD support, and this series is
> the result. I did have a lot of issues with link training, but with
> these, it's been working
Am 30.05.19 um 01:23 schrieb Mauro Carvalho Chehab:
This file was renamed, but docs weren't updated accordingly.
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
PRIME Buffer Sharing ./drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c' failed with
return code 1
Hi Tomeu,
On 31/05/2019 13:59, Tomeu Vizoso wrote:
> On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
>>
>> Hi,
>>
>> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
>> no more probing.
>>
>> The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e
>>
On Fri, 2019-05-31 at 14:37 +0200, Neil Armstrong wrote:
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missin the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ is selected by default.
>
> Fixes: f3617b449d
On 31/05/2019 13:04, Tomeu Vizoso wrote:
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
[snip]
[ 345.204813] panfrost 180.gpu: mmu irq status=1
[ 345.209617] panfrost 180.gpu:
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
use that directly instead and attach it as a modeset array onto
drm_client_dev. drm_fb_helper will use this array to store its modesets
which means it will always initialize a drm_client, but it will not
register the client
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Declare drm_mode_set and drm_plane_state in patch 1
- Export drm_client_panel_rotation() (Gerd Hoffmann)
- Rebase
Noralf.
Cc: Gerd Hoffmann
Noralf Trønnes (8):
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81
On Fri, May 31, 2019 at 10:00 AM Christian König
wrote:
>
> Am 30.05.19 um 01:23 schrieb Mauro Carvalho Chehab:
> > This file was renamed, but docs weren't updated accordingly.
> >
> > WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno
> > -function PRIME Buffer Sharing
Hello,
On 3/13/19 9:20 PM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Cc: # v4.14+
> Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
> Suggested-by: Boris Brezillon
https://bugs.freedesktop.org/show_bug.cgi?id=110725
Ville Syrjala changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
We need to mark the output polling as disabled to prevent concurrent
irqs from queuing new work as shutdown the probe -- causing that work to
execute after we have freed the structs:
<4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
<4> [341.846497] WARNING: CPU: 3 PID: 3300 at
The pull request you sent on Fri, 31 May 2019 11:12:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-31
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ca1918049673a9be507c41fb7e4a69a57601a017
Thank you!
--
Deet-doot-dot, I am a bot.
Quoting Chris Wilson (2019-05-31 18:16:15)
> We need to mark the output polling as disabled to prevent concurrent
> irqs from queuing new work as shutdown the probe -- causing that work to
> execute after we have freed the structs:
>
> <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
>
We need to mark the output polling as disabled to prevent concurrent
irqs from queuing new work as shutdown the probe -- causing that work to
execute after we have freed the structs:
<4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
<4> [341.846497] WARNING: CPU: 3 PID: 3300 at
Boris Brezillon writes:
> Right now, the BO is mapped as a cached region when ->vmap() is called
> and the underlying object is not a dmabuf.
> Doing that makes cache management a bit more complicated (you'd need
> to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
> to be
We need to mark the output polling as disabled to prevent concurrent
irqs from queuing new work as shutdown the probe -- causing that work to
execute after we have freed the structs:
<4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
<4> [341.846497] WARNING: CPU: 3 PID: 3300 at
This patch fixes below warning reported by coccicheck
./drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:63:13-31: WARNING:
dma_alloc_coherent use in ih -> ring already zeroes out memory, so
memset is not needed
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 1 -
1 file
On Fri, May 31, 2019 at 10:54 AM Helen Koike wrote:
>
> Hello,
>
> On 3/13/19 9:20 PM, Helen Koike wrote:
> > Async update callbacks are expected to set the old_fb in the new_state
> > so prepare/cleanup framebuffers are balanced.
> >
> > Cc: # v4.14+
> > Fixes: 224a4c970987 ("drm/msm: update
On 2019-05-30 12:12 p.m., Colin King wrote:
> From: Colin Ian King
>
> The variable status is initialized with a value that is never read
> and status is reassigned several statements later. This initialization
> is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
>
The opening comment mark "/**" is reserved for kernel-doc comments, so
it will generate a warning with "make W=1".
drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file
drm_memory.c
Also, silence a checkpatch warning,
WARNING: Missing or malformed SPDX-License-Identifier tag in
https://bugs.freedesktop.org/show_bug.cgi?id=110658
--- Comment #6 from Alexander Mezin ---
(In reply to Timothy Arceri from comment #4)
> I've run it on llvm 8 and mesa 19.0.5 and was unable to reproduce the issues
> seen in the screen capture on my Vega 64.
What kernel version and distro are
https://bugs.freedesktop.org/show_bug.cgi?id=110805
Bug ID: 110805
Summary: All the friends in the friend list is not listed
Product: Mesa
Version: 18.3
Hardware: x86 (IA32)
OS: All
Status: NEW
Severity:
Before loading the zap shader we should ensure that the reserved memory
region is big enough to hold the loaded file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=110805
Andre Klapper changed:
What|Removed |Added
Component|Drivers/DRI/i915|Two
Version|18.3
https://bugzilla.kernel.org/show_bug.cgi?id=203627
--- Comment #4 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
Nothing changed with 4.19.46 and 4.19.47
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
When panel probe happens after DSI probe, the DSI probe is deferred as
per current design. In the probe defer path dsi device is destroyed.
This NULL dsi device could be deferenced by the panel probe in the
mipi_dsi_attach path.
Check for NULL dsi device before accessing it.
Changes in v2:
-
On Fri 31 May 15:09 PDT 2019, Jordan Crouse wrote:
> Before loading the zap shader we should ensure that the reserved memory
> region is big enough to hold the loaded file.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8
70 matches
Mail list logo
