On 12/11/2017 03:18 PM, Noralf Trønnes wrote:
Den 10.12.2017 23.10, skrev David Lechner:
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
---
+static void st7735r_pipe_enable(struct drm_simple_display
Hi Brian,
On 2017年12月07日 05:52, Brian Norris wrote:
Hi Nickey, others,
I just want to highlight a thing or two here. Otherwise, my
'Reviewed-by' still basically stands (FWIW).
On Wed, Dec 06, 2017 at 05:08:21PM +0800, Nickey Yang wrote:
Add the ROCKCHIP DSI controller driver that uses the Sy
From: Brian Norris
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
Signed-off-by: Brian Norris
Signed-off-by: Nickey Yang
Link:https://pat
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.
Signed-off-by: Nickey Yang
Signed-off-by: Brian Norris
Reviewed-by: Brian Norris
Reviewed-by: Sean Paul
---
changes:
v2:
add err_pllref, remove unnecessary encoder.enable & disable
We now have a generic dw-mipi-dsi bridge driver.So we send
this patchs to moving rockchip dw-mipi-dsi driver to that
in order to add new features(dual mipi support).
Update ROCKCHIP DSI controller driver that uses the Synopsys
DesignWare MIPI DSI host controller bridge.
ChangeLog:
v2:
add err_p
This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
Reviewed-by: Brian Norris
---
.../display/rockchip/dw_mipi_dsi_roc
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #2 from Deposite Pirate (dpir...@metalpunks.info) ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?
Hi,
I'm working on it. I haven't compiled a kernel in a few years so I had to set
up all this stuff. This PC is quite
https://bugzilla.kernel.org/show_bug.cgi?id=197851
Tyler McLean (sonarsoundapplicati...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.14.0-041400rc8-generic|4.15.0-0
Hi Emil,
On Fri, Dec 01, 2017 at 02:40:11PM +, Emil Velikov wrote:
> On 30 November 2017 at 23:49, Sudip Mukherjee
> wrote:
> > Hi Daniel,
> >
> > On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter wrote:
> > submit it to dri-devel.
> >
> A crazy idea, mostly towards Tedd and Sudip:
>
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #4 from jerry@amd.com ---
(In reply to dwagner from comment #3)
> (In reply to Jordan L from comment #2)
> > Thanks, we can reproduce this too, should have something shortly.
>
> Any news on this?
>
> I am asking, because the cu
Den 10.12.2017 23.10, skrev David Lechner:
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
---
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+ st
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > + Daniel, Chris
> >
> > On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
> > > On 04/12/2017 15:02, Lionel Landwerlin wrote:
> > > > Hi,
> > > >
> > > > After discussion with
Hi Kieran,
I found this e-mail already written and sitting in my outbox, so even if it's
quite outdated I decided to still send it.
On Tuesday 01 Aug 2017 15:06:20 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > The H3 ES1.x exhibits dot clock duty cycle stability issues.
On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote:
> Add the defacto-standard "iturbt_709" property to the overlay plane to
> control the YUV to RGB colorspace conversion. This is mutually
> exclusive with the CSC_YUV CRTC property - the last property to be set
> determines the resultin
On Mon, Dec 11, 2017 at 12:31:06PM +0200, Joonas Lahtinen wrote:
> + GVT folks.
>
> On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commit
> >
> > 365ad5df9caa ("drm/i915/gvt: Export
> > intel_gvt_render_mmio_to_ring_id()")
> >
> > is missing a Signed-off-by fro
On 11 December 2017 at 03:51, Chih-Wei Huang wrote:
> Please rebase to the latest master and re-submit the patch.
> In particular, please consider the master already has
> a Rob Herring's patch which moved libdrm* to /vendor.
>
This please.
>
>
> 2017-07-26 18:08 GMT+08:00 Jiyong Park :
>> libdr
Quoting Chris Wilson (2017-12-11 12:51:42)
> Quoting Arnd Bergmann (2017-12-11 12:46:22)
> > The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
> > to shrink the i915 kernel module by around 1000 bytes. However, the
> > downside is a size regression with CONFIG_KASAN, as I
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, s
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/
On Mon, Dec 11, 2017 at 6:27 PM, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-12-11 17:20:32)
>> On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson
>> wrote:
>> > Teach lockdep to track the device's internal mmapping separately
>> > from the generic lockclass over all other inodes. Since this i
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #8 from Andrew ---
Correct you are about _not_ disabling the "accel". I was trying to figure
out what is breaking X this time around (i have a long thread on forums
trying to get amdgpu to work on this laptop).
I run on init3. And u
Quoting Daniel Vetter (2017-12-11 17:20:32)
> On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson
> wrote:
> > Teach lockdep to track the device's internal mmapping separately
> > from the generic lockclass over all other inodes. Since this is device
> > private we wish to allow a different locking hi
On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson wrote:
> Teach lockdep to track the device's internal mmapping separately
> from the generic lockclass over all other inodes. Since this is device
> private we wish to allow a different locking hierarchy than is typified
> by the requirement for the m
Den 10.12.2017 23.10, skrev David Lechner:
This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.
Signed-off-by: David Lechner
Acked-by: Rob Herring
---
v2: changes:
* None, but...
I'm wondering about my choice of compatible here. I chose the
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #77 from Kelly Anderson ---
4.15rc3 also seems to be fine with respect to this problem.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #7 from Michel Dänzer ---
(In reply to Andrew from comment #6)
> the X doesn't hard crash when i turn an acceleration off.
Normally you'd want Option "Accel" "off" to disable accleration, not
"AccelMethod" "none".
> X still doesn'
On 12/11/2017 07:37 AM, Noralf Trønnes wrote:
Den 11.12.2017 13.45, skrev Noralf Trønnes:
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
The
https://bugs.freedesktop.org/show_bug.cgi?id=104206
Michel Dänzer changed:
What|Removed |Added
Attachment #136083|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #6 from Andrew ---
Created attachment 136083
--> https://bugs.freedesktop.org/attachment.cgi?id=136083&action=edit
x log with "Aceel" turned off
the X doesn't hard crash when i turn an acceleration off. X still doesn't work
- just
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #5 from Andrew ---
Created attachment 136082
--> https://bugs.freedesktop.org/attachment.cgi?id=136082&action=edit
messages.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #4 from Andrew ---
Created attachment 136081
--> https://bugs.freedesktop.org/attachment.cgi?id=136081&action=edit
Xlog
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=103987
--- Comment #6 from Harry Wentland ---
Been busy and haven't gotten it in yet. It's still staged. Hope to queue it up
for next RC this week.
--
You are receiving this mail because:
You are the assignee for the bug._
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/
Hi Ville,
On Monday, 11 December 2017 16:24:32 EET Ville Syrjälä wrote:
> On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> >> On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> >>> On Tuesday, November
On 11/12/17 14:38, Tvrtko Ursulin wrote:
On 11/12/2017 10:50, Joonas Lahtinen wrote:
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit
On 11/12/2017 10:50, Joonas Lahtinen wrote:
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card
On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> > On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> > > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> > >> On Mon, Nov 27, 20
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
Me
Hi Ville,
On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> >> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> >>> From: Jeffrey Mouroux
> >>>
>
Hi Hyun,
Thank you for the patch.
On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> From: Satish Kumar Nagireddy
>
> 'cpp_scale' can be used as a multiplying factor to calculate
> bytes per component based on color format.
> For eg. scaling factor of YUV420 8 bit format is 1
>
Den 11.12.2017 13.45, skrev Noralf Trønnes:
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
The spi controller driver has told the spi core to
On 11/12/17 10:50, Joonas Lahtinen wrote:
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card thr
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #3 from Andrew ---
Michael,
Thank you for your reply.
Why pastebin is not good? ( Thought fedora's one is blessed/approved)
The rawhide mesa rpms versions are the same as in f27. Should i
recompile/reconfigure them somehow?
On D
https://bugs.freedesktop.org/show_bug.cgi?id=104192
--- Comment #11 from Tom Englund ---
(In reply to Tom Englund from comment #10)
> (In reply to Michel Dänzer from comment #9)
> > FWIW, I bisected some piglit regressions to LLVM SVN r319894.
>
> thanks, that gave me some starting points to bis
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/t
https://bugs.freedesktop.org/show_bug.cgi?id=104192
--- Comment #10 from Tom Englund ---
(In reply to Michel Dänzer from comment #9)
> FWIW, I bisected some piglit regressions to LLVM SVN r319894.
thanks, that gave me some starting points to bisecting, narrowed things down
now to where r319882 w
The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
to shrink the i915 kernel module by around 1000 bytes. However, the
downside is a size regression with CONFIG_KASAN, as I found from stack size
warnings with gcc-7.0.1:
before:
drivers/gpu/drm/i915/intel_dpll_mgr.c: In fun
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync ->
On Tue, Mar 21, 2017 at 12:23 PM, Jani Nikula
wrote:
> On Tue, 21 Mar 2017, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote:
>>> On Tue, Mar 21, 2017 at 9:26 AM, Jani Nikula
>>> wrote:
>>> > On Mon, 20 Mar 2017, Arnd Bergmann wrote:
>>> >> The varargs macro
On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote:
> The submit object lifetime will get extended to the actual GPU
> execution. As multiple users will depend on this, add a kref to
> properly control destuction of the object.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regard
https://bugs.freedesktop.org/show_bug.cgi?id=102985
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #2 from Michel Dänzer ---
... instead of referencing external sites, especially pastebins.
Looks like there's a Mesa installation / configuration issue which prevents
hardware acceleration from working, and the xf86-video-amdgpu dri
https://bugs.freedesktop.org/show_bug.cgi?id=104206
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
https://bugs.freedesktop.org/show_bug.cgi?id=104205
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Product|xorg
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> There is no need to store this in the gpu struct. MMU flushes are triggered
> correctly in reaction to MMU maps and unmaps, independent of the current ctx
> and required pipe switches can be infered from the current and the desired
> GPU exec state.
>
> Si
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
> On 04/12/2017 15:02, Lionel Landwerlin wrote:
> > Hi,
> >
> > After discussion with Chris, Joonas & Tvrtko, this series adds an
> > additional commit to link the render node back to the card through a
> > symlink. Making i
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> Flush and prefetch are properly handled in the buffer code, data endianess
> would need much wider changes than adding something to this single function.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etn
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> Inserting the END command when suspending the GPU is changing the
> command buffer state, which requires the GPU to be held.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
> 1 file c
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> This function never fails, as it does nothing more than adding the GEM
> object to the global device list. Making this explicit through the void
> return type allows to drop some unnecessary error handling.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Chr
https://bugs.freedesktop.org/show_bug.cgi?id=104192
--- Comment #9 from Michel Dänzer ---
FWIW, I bisected some piglit regressions to LLVM SVN r319894.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> The current userptr page population will defer work to a work item if
> needed to avoid ever taking the mmap_sem in the direct call path. With
> the more fine-grained locking in etnaviv this isn't needed anymore, so
> a future commit will simplify this cod
2017-12-01 11:36 GMT+01:00 Lucas Stach :
> This function has only one caller and it isn't expected that there will
> be any more in the future. Folding this function into the caller is
> helping the readability.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=104159
--- Comment #3 from Michel Dänzer ---
FWIW, I bisected some piglit regressions to LLVM SVN r319894.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Teach lockdep to track the device's internal mmapping separately
from the generic lockclass over all other inodes. Since this is device
private we wish to allow a different locking hierarchy than is typified
by the requirement for the mmap_rwsem being the outermost lock for
handling pagefaults. By
https://bugs.freedesktop.org/show_bug.cgi?id=104159
Christoph Haag changed:
What|Removed |Added
Summary|llvm 6.0svn: GPU fault/hang |llvm 6.0svn: firefox GPU
+ GVT folks.
On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 365ad5df9caa ("drm/i915/gvt: Export
> intel_gvt_render_mmio_to_ring_id()")
>
> is missing a Signed-off-by from its committer.
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
https://bugs.freedesktop.org/show_bug.cgi?id=104159
--- Comment #1 from Lorenzo Bona ---
I can confirm this bug on svn320332 too.
I'm using vanilla kernel.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Move writes of LCD_SPU_SRAM_PARA1 under the irq lock, so that we can
add this to the frame updates at interrupt time when disabling a
plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 10 ++
drivers/gpu/drm/armada/armada_overlay.c | 5 +++--
2 files change
Avoid powering down the overlay SRAM banks when disabling the primary
plane, thereby masking any overlay video. This feature is supposed to
allow us to cut the bandwidth required while displaying full-frame
overlay video.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 9
We must wait for the previous plane work to complete before moving
the overlay window, as it could overwrite our positioning update.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
>
> if
Hi Tomi,
On Fri, Dec 01, 2017 at 02:58:13PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 24/07/17 20:32, Sebastian Reichel wrote:
> > Hi,
> >
> > This adds support for command mode DSI panels to
> > omapdrm. I tested the patches on Nokia N950 (omap3)
> > and Motorola Droid 4 (omap4). This is basica
Re-organise overlay register generation so that we do not have to wait
for the previous update to complete while creating the new state. This
allows the update to be fully prepared before queueing it for the next
interrupt.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c
Move the overlay plane work out from under the spinlock so that both the
primary and overlay planes run their work in the same context. This is
necessary so that we can use frame works with the overlay plane.
However, we must update the CRTC registers under the spinlock, so fix up
the overlay cod
Add the defacto-standard "iturbt_709" property to the overlay plane to
control the YUV to RGB colorspace conversion. This is mutually
exclusive with the CSC_YUV CRTC property - the last property to be set
determines the resulting colorspace conversion.
Signed-off-by: Russell King
---
drivers/gp
Hi,
the commit 253696ccd613 ("drm/vc4: Account for interrupts in flight") triggers
a warning during boot of Raspberry Pi 2 with multi_v7_defconfig:
[7.962699] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping
ok
[7.962732] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
Merge armada_drm_primary_disable() into armada_drm_crtc_plane_disable()
and rename to armada_drm_plane_disable(). Use this to simplify
armada_ovl_plane_disable().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 21 +
drivers/gpu/drm/armada/armada_cr
Add CRTC and source positions to the Armada overlay trace entry.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_trace.h | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_trace.h
b/drivers/gpu/drm/armada/arm
Avoid printing an error message when armada_drm_plane_work_queue() is
unable to get the vblank (eg, because we're doing a modeset.) Continue
to report the failure to the caller, so the caller can handle this.
Move the error message into armada_ovl_plane_update().
Signed-off-by: Russell King
---
Disable planes at the next blanking period rather than immediately.
In order to achieve this, we need to delay the clearing of dcrtc->plane
until after the next blanking period, so move that into a separate
work function. To avoid races, we also need to move its assignment in
the overlay code.
Si
Wait for a second, and if we time out, cancel any pending work when
disabling the primary plane. This ensures that any pending work is
completed or cleaned up prior to the disable taking effect.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 28 ++-
Lookup the drm_format_info structure once when computing all the
framebuffer plane addresses by using drm_format_info(), rather than
repetitive lookups via drm_format_plane_cpp().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 d
Move the overlay plane register update generation to a separate function
as this is independent of the legacy or atomic update.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.h| 2 +
drivers/gpu/drm/armada/armada_overlay.c | 203 +---
2 files
On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
> On 12/06/17 13:35, Russell King wrote:
> > We no longer use the CEC client to access the CEC part itself, so we can
> > move this later in the initialisation sequence.
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 24 +---
drivers/gpu/drm/armada/armada_crtc.h| 3 +++
drivers/gpu/drm/armada/armada_overlay.c | 11 +++
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/armad
From: Kees Cook
> Sent: 06 December 2017 20:29
>
> There's no good reason to separate the access_ok() from the copy,
> especially since the access_ok() size is hard-coded instead of using
> sizeof(). Instead, just use copy_from_user() directly.
Looks like an optimisation to save doing the access_o
Store the plane in the armada_plane_work structure rather than passing
it around; it doesn't get used very much in the work structures, so
passing it around is a needless expense.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 27 +++
drivers/gp
Clear the plane enable bit in the software state within
armada_drm_plane_disable() when disabling either the primary or
overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 10 ++
drivers/gpu/drm/armada/armada_overlay.c | 2 --
2 files changed, 6 ins
On Fri, 08 Dec 2017 22:44:27 +,
Stefan Wahren wrote:
>
> Hi,
>
> the commit 253696ccd613 ("drm/vc4: Account for interrupts in
> flight") triggers a warning during boot of Raspberry Pi 2 with
> multi_v7_defconfig:
>
> [7.962699] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi
> m
Only enable the HSMOOTH control bit if we are scaling horizontally,
otherwise it makes no sense to enable the horizontal scaler.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 5 +++--
drivers/gpu/drm/armada/armada_overlay.c | 10 +-
2 files changed, 8 inserti
On Wed, Dec 06, 2017 at 02:50:44PM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> Thanks for this patch series!
>
> On 12/06/17 13:35, Russell King wrote:
> > The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
> > onto the same die. Add support for the TDA9950 CEC engine to the
Hi David,
This series fixes some issues in the Armada DRM driver:
- A memory leak while cleaning up in the CRTC initialisation path
- Avoid powering down YUV FIFOs when disabling the graphics plane
- Several fixes for the overlay plane positioning
Minor updates for the comments from Sean Paul, an
Add a work cancel callback, so that work items can add functionality to
clean themselves up when they are cancelled.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 23 ---
drivers/gpu/drm/armada/armada_crtc.h | 1 +
2 files changed, 17 insertions(+),
Extract the register generation from armada_drm_primary_set(), so that
it can be re-used.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/dr
Linus,
On Fri, Dec 8, 2017 at 10:16 PM, Linus Torvalds
wrote:
> On Thu, Dec 7, 2017 at 5:20 PM, Dave Airlie wrote:
>>
>> This pull is a bit larger than I'd like but a large bunch of it is
>> license fixes, AMD wanted to fix the licenses for a bunch of files
>> that were missing them,
>
> Oh Chri
Both the primary and overlay planes retire framebuffers in a similar
manner; this can be consolidated by moving the retirement up to the
armada_plane_work layer.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 12 +++-
drivers/gpu/drm/armada/armada_crtc.h|
Move the sending of events into the armada_plane_work structure, and
combine the processing in armada_drm_plane_work_call().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 27 +--
drivers/gpu/drm/armada/armada_crtc.h | 1 +
2 files changed, 14 ins
On Fri, Dec 8, 2017 at 2:17 AM, David Laight wrote:
> From: Kees Cook
>> Sent: 06 December 2017 20:29
>>
>> There's no good reason to separate the access_ok() from the copy,
>> especially since the access_ok() size is hard-coded instead of using
>> sizeof(). Instead, just use copy_from_user() dire
Move the register update structure out of the overlay private structure
into armada_plane_work, as this is common to both the primary and
overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 42 --
drivers/gpu/drm/armada/armada_crt
On Sat, 09 Dec 2017 14:17:58 +,
Stefan Schake wrote:
>
> On Sat, Dec 9, 2017 at 1:34 PM, Marc Zyngier wrote:
> > On Fri, 08 Dec 2017 22:44:27 +,
> > Stefan Wahren wrote:
> >>
> >> Hi,
> >>
> >> the commit 253696ccd613 ("drm/vc4: Account for interrupts in
> >> flight") triggers a warning d
1 - 100 of 126 matches
Mail list logo
