From: Ville Syrjälä
The vblank timestamp ringbuffer only has two entries, so if the
vblank->count is incremented by an even number readers may end up seeing
the new vblank timestamp alongside the old vblank counter value.
Fix the problem by storing the vblank counter in a ringbuffer as well,
a
From: Ville Syrjälä
When lacking am accurate hardware frame counter, we can fall back to
using the vblank timestamps to guesstimagte how many vblanks have
elapsed since the last time the vblank counter was updated.
Take the oppostunity to unify the vblank_disable_and_save() and
drm_handle_vbla
From: Ville Syrjälä
Remove the NULL 't_vblank' checks from store_vblank() since that will
never happen.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/dr
From: Ville Syrjälä
Avoid confusion and don't use 'vbl_status' as both the
.get_scanout_position() return value and the return value from
drm_calc_vbltimestamp_from_scanoutpos().
While at it make 'vbl_status' unsigned and print it as hex in the
debug prints since it's a bitmask.
Signed-off-by
From: Ville Syrjälä
Pontential infinite loops in the vblank code are a bad idea. Add some
limits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index
From: Ville Syrjälä
We'll soon have use for the 'flags' in drm_update_vblank_count() so pass
it in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
From: Ville Syrjälä
The vblank counts are u32 so make flip_queued_vblank and
flip_ready_vblank u32 as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/g
From: Ville Syrjälä
pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns
is also currently unused but we will have use for it in the near future
so leave it be. linedur_ns is still used by nouveau for some internal
delays.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm
From: Ville Syrjälä
linedur_ns, and especially pixeldur_ns are becoming rather inaccurate
to be used for the vblank timestamp correction. With 4k at 60 the pixel
duration is already below 2ns, so the amount of error due to the
truncation to nanoseconds is introducing quite a bit of error.
We c
From: Ville Syrjälä
Collect the timestamping constants alongside the rest of the relevant
stuff under drm_vblank_crtc.
We can now get rid of the 'refcrtc' parameter to
drm_calc_vbltimestamp_from_scanoutpos().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2
From: Ville Syrjälä
Finish the recent replacement of 'int pipe' with 'unsigned int pipe'
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/g
From: Ville Syrjälä
This series has a few goals:
- make timestamps more accurate by not using rounded pixel/line durations
- avoid infinite loops in vblank code
- use the timestamps to guesttimate the number of missed vblanks, in case
there's no hardware frame counter, or it can't be trusted
https://bugzilla.kernel.org/show_bug.cgi?id=103271
--- Comment #17 from Kevin McCormack ---
I have been bisecting when I have a chance and it is coming along slowly. I did
figure out a nice way to reduce compile times from 90min+ down to 20min using
`MAKEFLAGS=-j8 makepkg -e` with my FX-8370. I h
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/27049ac1/attachment.html>
Hi,
On 9/14/2015 3:35 PM, Dave Airlie wrote:
> (this time with correct email address).
>
> On 14 September 2015 at 20:04, Dave Airlie wrote:
>>>
If drm_fb_helper_alloc_fbi() fails then we were directly returning
without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
(this time with correct email address).
On 14 September 2015 at 20:04, Dave Airlie wrote:
>>
>>> If drm_fb_helper_alloc_fbi() fails then we were directly returning
>>> without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
>>> mgag200_framebuffer_init() fails then we were not rele
>
>> If drm_fb_helper_alloc_fbi() fails then we were directly returning
>> without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
>> mgag200_framebuffer_init() fails then we were not releasing sysram and
>> we were not releasing fbi helper also.
>>
>> Signed-off-by: Sudip Mukherjee
Hi Enric,
Partial review for now, thanks for you work.
Best,
On Thu, Sep 10, 2015 at 06:35:52PM +0200, Enric Balletbo i Serra wrote:
> At the moment it only supports ANX7814.
>
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> This
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/5f50c0ea/attachment.html>
This patch add a config to support to create multi buffer for cma fbdev. Such as
double buffer and triple buffer.
Cma fbdev is convient to add a legency fbdev. And still many Android devices use
fbdev now and at least double buffer is needed for these Android devices, so
that a buffer flip can be
https://bugzilla.kernel.org/show_bug.cgi?id=100351
--- Comment #6 from yaroslav.sapozhnik at gmail.com ---
Seems like it's fixed with 4.1.6-200.fc22.x86_64. I'll monitor this for some
time.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Dave,
-rc1 is out the door and here's my first pull request for drm-next. It's
all over:
- better atomic helpers for runtime pm drivers
- atomic fbdev
- dp aux i2c STATUS_UPDATE handling (for short i2c replies from the sink)
- bunch of constify patches
- various polish all over
There's a few a
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_aux-N.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
the connector device pointer was correct
This is useful to determine which connector owns this AUX channel.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/i915/intel_dp.c | 1 +
include/drm/drm_dp_helper.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
i
This list will be used to get the aux channels registered through the
helpers. Two functions are provided to register/unregister notifier
listeners on the list, and another functiont to iterate over the list of
aux channels.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/drm_dp_helper.c |
This is a tentative implementation of a module that allows reading/writing
arbitrary dpcd registers, following the suggestion from Daniel Vetter. It
assumes the drm aux helpers were used by the driver.
I tried to follow the i2c-dev implementation as close as possible, but the only
operations that
On Mon, Sep 14, 2015 at 08:05:37PM +1000, Dave Airlie wrote:
> (this time with correct email address).
>
> On 14 September 2015 at 20:04, Dave Airlie wrote:
> >>
> >>
> >> There's a new regression: v4.3-rc1 crashes on bootup on non-supported
> >> hardware, if
> >> CONFIG_DRM_MGAG200=y (built int
On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must always be
> allocated inside the 32-bit address range.
>
> In specific, any resource used with flat/heapless (0x-0xf000)
> General State Heap (GSH) or Instru
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/e7443386/attachment.html>
On Sun, Sep 13, 2015 at 09:08:31PM +0900, Masanari Iida wrote:
> This patch fix following warnings while "make xmldocs".
> .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description
> found for parameter 'req'
> .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
> parameter 'r
On Sun, Sep 13, 2015 at 11:36:07AM +0200, Ingo Molnar wrote:
>
> * Sudip Mukherjee wrote:
>
>
> There's a new regression: v4.3-rc1 crashes on bootup on non-supported
> hardware, if
> CONFIG_DRM_MGAG200=y (built into the kernel).
I am not able to reproduce it with and without my patch applie
> Recent commits to kernel/git/torvalds/linux.git have made the following
> functions able to tolerate NULL arguments:
>
> kmem_cache_destroy (commit 3942d29918522)
> mempool_destroy (commit 4e3ca3e033d1)
> dma_pool_destroy (commit 44d7175da6ea)
How do you think about to extend an other SmPL scrip
Hi,
I just wanted to pass along a few XDC updates:
- I have made some changes to the schedule, but it should still be
considered tentative. I will let announce once it has been finalized.
- There is an informal get together planned for Tuesday night if you
are in town early. Please sign up on
Op 02-09-15 om 17:24 schreef Daniel Vetter:
> On Wed, Sep 02, 2015 at 03:36:33PM +0100, Daniel Stone wrote:
>> On 2 September 2015 at 09:42, Maarten Lankhorst
>> wrote:
>>> This removes the need to separately track fb changes i915.
>>> That will be done as a separate commit, however.
>>>
>>> Chang
* Sudip Mukherjee wrote:
> On Sun, Sep 13, 2015 at 11:36:07AM +0200, Ingo Molnar wrote:
> >
> > * Sudip Mukherjee wrote:
> >
>
> >
> > There's a new regression: v4.3-rc1 crashes on bootup on non-supported
> > hardware, if
> > CONFIG_DRM_MGAG200=y (built into the kernel).
>
> I am not abl
nts/20150914/b8d64e21/attachment.html>
On Mon, Sep 14, 2015 at 9:52 AM, Geert Uytterhoeven
wrote:
> On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart
> wrote:
>> This patch series adds support for the Display Unit found in the R-Car Gen3
>> SoC series.
>>
>> The third generation differs significantly from the previous ones in that th
Hi Laurent,
On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart
wrote:
> This patch series adds support for the Display Unit found in the R-Car Gen3
> SoC series.
>
> The third generation differs significantly from the previous ones in that the
> DU has lost its ability to source data from memory.
On Mon, Sep 14, 2015 at 01:50:55AM +0300, Laurent Pinchart wrote:
> Plane sources are configured by the VSPS bit in the PnDDCR4 register.
> Although the datasheet states that the bit is updated during vertical
> blanking, it seems that updates only occur when the DU group is held in
> reset through
On Fri, Sep 11, 2015 at 10:10 AM, Lucas Stach wrote:
> From: Christian Gmeiner
>
> This is a squashed commit of the complete etnaviv DRM driver in order
> to make it easy for people to review the code by seeing the driver as a
> whole and is not intended for merging in this form.
>
> If you are i
On Mon, Sep 14, 2015 at 4:44 AM, Alex Vazquez wrote:
> Hi!
> I want to know if when i use drmModeFreeResources() i need free the
> resources crtc, encoder and connector before or it is not necessary.
drmModeFreeResources() only frees the drmModeResPtr object (including
it's arrays of connector-i
On 09/13/2015 05:58 PM, Daniel Vetter wrote:
> On Sun, Sep 13, 2015 at 9:13 PM, Jonathan Corbet wrote:
>> On Sun, 13 Sep 2015 12:36:07 +0200
>> Daniel Vetter wrote:
>>
>>> Personally I don't care which kind of text markup we pick and wich
>>> converter, as long as the project looks reasonable far
g/archives/dri-devel/attachments/20150914/57544491/attachment.html>
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/56cd7ebc/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/2ad46bf2/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/df645afb/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/b4dc1f76/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/f37023d2/attachment.html>
From: Koji Matsuoka
The LVDS encoder differs slightly in Gen3 SoCs in its PLL configuration.
Add support for the Gen3 LVDS PLL parameters and startup procedure.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 4 +-
drivers/gpu/drm
The bit is named PLLON in the datasheet, rename it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
b/
The frequency checks don't match the datasheet, fix them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
Replace the duplicate code by a single central function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 7 ++-
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 9 +
drivers/gpu/drm/rcar-du/rcar_du_lvdse
Document the R8A7795-specific DT bindings and support them in the
driver. The HDMI and LVDS outputs are currently not supported.
Cc: devicetree at vger.kernel.org
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/video/renesas,du.txt | 16 ---
dr
The ODDF signal, output by default on the ODDF pin, isn't used on any
board supported in the kernel. As the Gen3 Salvator-X board uses the
ODDF pin as a DISP signal, hardcode that configuration in the driver.
Use of the ODDF signal will be implemented later through proper DT-based
configuration of
The DE signal is currently configured to be identical to the DISP
signal and is used for the same purpose. To make it clearer that the
DISP pin outputs the DISP signal, select it explicitly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 inse
From: Koji Matsuoka
The Gen3 R8A7795 DU has 4 CRTCs, support them all.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 1 +
3 files changed,
LVDS support depends on DRM_RCAR_DU which already depends on OF. Drop
the explicit dependency.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 7c465ee7ae
From: Koji Matsuoka
The R8A7795 SoC is ARM64-based and include a DU. Enable driver
compilation on ARM64.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-
From: Koji Matsuoka
Use %tu instead of %u to print difference between pointers.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 18 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 4
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 7 +
drivers/gpu/drm/rcar-du/Makefile| 2 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 42 +++-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +
drivers/gpu/
The plane allocator is specific to DU planes and won't be used for
VSP-based planes, move it with the rest of the DU planes code where it
belongs.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 276 +-
drivers/gpu/drm/rcar-du/rcar_du_pla
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Signed-off-
Configure the plane source at plane setup time to source frames from
memory or from the VSP1.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 24 +
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
drivers/gpu/dr
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
Rename plane setup functions using more explicit names, and use local
variables to store intermediate values to increase readability. This
also prepares for VSP compositor support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 39 ++---
There's no need for a read-modify-write pattern, all register bits can
be set explicitly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/driv
The R8A7794 DU has a fixed output routing configuration with one RGB
output per CRTC and thus lacks the RGB output routing register field.
Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/video/renesas,du.txt | 4 +++-
drivers/gpu/drm/rcar-du/r
The R8A7793 DU is identical to the R8A7791 and thus only requires a new
DT compatible string.
Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/video/renesas,du.txt | 12 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c |
A disabled CRTC can't display planes, the driver shouldn't try to
configure it when updating planes. The DRM core will store the plane
state for us, and the plane will be configured appropriately the next
time the CRTC is enabled.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_
Hello,
This patch series adds support for the Display Unit found in the R-Car Gen3
SoC series.
The third generation differs significantly from the previous ones in that the
DU has lost its ability to source data from memory. It must instead use an
external hardware composer named VSP to read plan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/e9450c8d/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/1d5e8305/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150914/c30d6952/attachment.html>
On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote:
> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary
> wrote:
> > Hello,
> > I have a PC Chips A31G board with AGPro slot and found that nouveau does
> > not work properly with it. Console works but reverts to software mode,
> > X11 hangs with mou
75 matches
Mail list logo
