Hello,
some recent work I did on Exynos. Patches are based on [1] and [2].
Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes
While testing the NV12MT part, I made these interesting observations.
(1) I used 1920x1080 XRGB888
The video processor supports a tiled variant of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12MT with a special memory layout.
With the introduction of FB modifiers, we
The current comment sounds like the division is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 2
DRM core already checks the validity of the pixelformats, to we
can simplify the checks here. The same applies to the FB modifier,
which is now check in common Exynos plane code.
Also rename the booleans to reflect what true/false actually
encodes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/d
In some of drivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This is not always true, in particular
DRM core does not check for pitch alignment in the common case.
Introduce a new cap which signals
We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register.
We leave the register defines (in regs_mixer.h) in place, since
they document the hardware.
Signed-off-by: Tobias Jakobi
---
drivers/gpu
Both FIMD and DECON5433 support a pitch in bytes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu
A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].
Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.
S
DRM core already checks the validity of the pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 +---
3 files changed, 3 insertions(+
Hi Dave,
The following changes since commit e1b489d207c73e67810659a88c45b8db4bd62773:
Merge tag 'omapdrm-4.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
(2017-04-04 05:45:49 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.g
https://bugs.freedesktop.org/show_bug.cgi?id=100531
Shawn Starr changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.kernel.org/show_bug.cgi?id=195159
Urgau (lolo.branst...@numericable.fr) changed:
What|Removed |Added
Severity|high|normal
--
You ar
On 04.04.2017 13:33, Christian König wrote:
Am 03.04.2017 um 18:22 schrieb Nicolai Hähnle:
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS
instead of a placement limit. That allows us to better handle C
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> To match the drm_ioctl.c we already have.
>
> v2: Remove spurious space (Ville).
>
> Cc: Ville Syrjälä
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> - remove docs for internal func, doesn't add value
> - add short overview snippet instead explaining that drivers don't
> have to bother themselves with reg/unreg concerns
> - drop the ttm comment about drmP.h, drmP.h is disappearing ...
>
> Signed-
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> Also unify/merge with the existing stuff.
>
> I was a bit torn where to put this, but in the end I decided to put
> all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
> have a bit a split with the other uapi related stuff used internal
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> There's really no reason for anything more:
> - Calling this while the crtc vblank stuff isn't set up is a driver
> bug. Those places arlready DRM_ERROR.
s/arlready/already/
> - Calling this when the crtc is off is either a driver bug (callin
s/calli
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> It's overkill to have a flag parameter which is essentially used just
> as a boolean. This takes care of core + adjusting drivers.
>
> Adjusting the scanout position callback is a bit harder, since radeon
> also supplies it's own driver-private flags
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> This is going to be a bit too much, but good to have at least a small
> note about where this should all head towards.
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_drv.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> If we restrict this helper to only kms drivers (which is the case) we
> can look up the correct mode easily ourselves. But it's a bit tricky:
>
> - All legacy drivers look at crtc->hwmode. But that is update already
is updated ?
> at the beginning o
On Mon, Apr 3, 2017 at 4:24 AM, Christian König wrote:
> Am 03.04.2017 um 05:35 schrieb r...@ubuntu.com:
>>
>> From: Christopher James Halse Rogers
>>
>>
>> BOs shared via dma-buf, either imported or exported, cannot sensibly be
>> migrated to VRAM
>> without breaking the dma-buf sharing. Refuse
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> - We can drop the different return value flags, the only caller only
> cares about whether the scanout position is valid or not. Also, it's
> entirely undefined what "accurate" means, if we'd really care we
> should probably wire the max_error th
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> Drive-by cleanup.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_probe_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> inde
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> In the previous patch we've implemented hwmode tracking a la i915 for
> the vblank timestamp calculations. But that was just the basic
> semantics, i915 has some nice sanity checks to make sure we keep
> getting this right. Move them over too.
>
> Cc:
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> v2: Keep a bunch of the todos, Gabriel is working on them.
>
> Cc: Gabriel Krisman Bertazi
> S
On Tue, Apr 04, 2017 at 05:17:44PM +0300, Laurent Pinchart wrote:
> Hi Dave,
>
> The following changes since commit e1b489d207c73e67810659a88c45b8db4bd62773:
>
> Merge tag 'omapdrm-4.12' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
> (2017-04-04 05:45:49 +1000)
https://bugs.freedesktop.org/show_bug.cgi?id=100531
--- Comment #7 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
(In reply to Shawn Starr from comment #6)
> This patch is master and fixes corruption from this
> https://www.youtube.com/watch?v=lmdJTptF2go also.
Just a note: If comment #6 isn't a sp
https://bugs.freedesktop.org/show_bug.cgi?id=100531
--- Comment #8 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
(In reply to Marek Olšák from comment #4)
> Created attachment 130650 [details] [review]
> possible fix
>
> Would you please try this patch?
Tomb Raider benchmark renders correctly wit
Hi Thierry,
On Tuesday 04 Apr 2017 17:21:47 Thierry Reding wrote:
> On Tue, Apr 04, 2017 at 05:17:44PM +0300, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > The following changes since commit
e1b489d207c73e67810659a88c45b8db4bd62773:
> > Merge tag 'omapdrm-4.12' of
> >
> > git://git.kernel.org/
On 04/04/2017 02:31 PM, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
>
> Thanks to Laurent Pinchart's changes, the HW report the following :
> Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_ph
On 04/04/2017 02:15 PM, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
>
> This patchset depends on Laurent Pinchart patchset merged in drm-misc-next
> and my v6 patchset at [1] to permit PHY control from out
On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > The multi-seat thing sounds like vapourware, I think we should care about
> > the vr use-case for now, and only that one.
>
> Ok, I can live with that, even if I like the idea of a slightly more
> genera
On Tue, Apr 04, 2017 at 06:38:15PM +0300, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Tuesday 04 Apr 2017 17:21:47 Thierry Reding wrote:
> > On Tue, Apr 04, 2017 at 05:17:44PM +0300, Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > The following changes since commit
> e1b489d207c73e67810659a8
On 3 April 2017 at 21:55, Erik Faye-Lund wrote:
> On Mon, Apr 3, 2017 at 6:59 PM, Emil Velikov wrote:
>> On 29 March 2017 at 23:24, Erik Faye-Lund wrote:
>>> I get a few more symbols in my build tegra-libraries, so let's
>>> include these in the whitelist as well.
>>>
>>> While we're at it, upda
Hi,
Following the annual tradition, I've rebased Ander/Maarten's patches
to include the CRTC ID in vblank events. Specifically, this makes it
possible to know which CRTC an atomic request-completion event refers
to.
I'm using this in Weston, for which I can ack it as good API, and a
second opinion
From: Ander Conselvan de Oliveira
With the atomic API, it is possible that a single commit affects
multiple crtcs. If the user requests an event with that commit, one
event will be sent for each CRTC, but it is not possible to distinguish
which crtc an event is for in user space. To solve this, t
From: Ander Conselvan de Oliveira
When using the atomic API, one request can span multiple CRTCs, however
one event is generated per CRTC. As we cannot disambiguate the CRTC with
user data (since we only have one piece of user data to pass in), newer
kernels can include the CRTC ID in the page fl
https://bugs.freedesktop.org/show_bug.cgi?id=100465
--- Comment #8 from Julien Isorce ---
(In reply to Michel Dänzer from comment #3)
> Doesn't seem to happen with my Tonga after 30 minutes.
>
> One thing to keep in mind is that FurMark is designed to stress the GPU. Do
> the systems you're test
Hi Daniel,
Zero objections against the patch, just a couple of small notes.
On 4 April 2017 at 17:52, Daniel Stone wrote:
> From: Ander Conselvan de Oliveira
>
> When using the atomic API, one request can span multiple CRTCs, however
> one event is generated per CRTC. As we cannot disambiguate
Hi Emil,
On Tue, 2017-04-04 at 18:12 +0100, Emil Velikov wrote:
> On 4 April 2017 at 17:52, Daniel Stone wrote:
> > @@ -846,7 +847,7 @@ struct drm_event_vblank {
> > __u32 tv_sec;
> > __u32 tv_usec;
> > __u32 sequence;
> > - __u32 reserved;
> > + __u32 crtc_id;
On Tue, Apr 04, 2017 at 09:47:38PM +0800, Shawn Guo wrote:
> On Mon, Apr 03, 2017 at 11:23:51AM +0200, Daniel Vetter wrote:
> > > +static int zx_vga_ddc_register(struct zx_vga *vga)
> > > +{
> > > + struct device *dev = vga->dev;
> > > + struct i2c_adapter *adap;
> > > + struct zx_vga_i2c *ddc;
> >
On Tue, Mar 21, 2017 at 08:15:56PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> It adds VGA driver support, which needs to configure corresponding VOU
> interface in RGB_888 format, and thus the following changes are needed
> on zx_vou.
>
> - Rename the CSC block of Graphic Layer a bit to make
On Tue, Mar 21, 2017 at 08:15:54PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The CSC (Color Space Conversion) block in VOU is used by not only
> Graphic Layer (plane) but also channel (CRTC) module. Let's move
> its register definitions into a common header, so that CRTC driver can
> include
On Tue, Mar 21, 2017 at 08:15:53PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> Some VOU modules do not work well with clock auto-gating. For example,
> VGA I2C bus will fail to read EDID data from monitor. Let's not enable
> this feature by default, and leave it to the possible future low-pow
On Tue, Apr 04, 2017 at 05:52:21PM +0100, Daniel Stone wrote:
> From: Ander Conselvan de Oliveira
>
> With the atomic API, it is possible that a single commit affects
> multiple crtcs. If the user requests an event with that commit, one
> event will be sent for each CRTC, but it is not possible t
On Tue, Apr 04, 2017 at 02:15:13PM +0100, John Keeping wrote:
> Hi Sean,
>
> On Sun, 12 Mar 2017 07:06:59 -0500, Rob Herring wrote:
>
> > On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote:
> > > This reset is required in order to fully reset the internal state of the
> > > MIPI control
On Tue, Apr 04, 2017 at 04:46:06PM +0200, Neil Armstrong wrote:
> On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > v2: Remove spurious space (Ville).
> >
> > Cc: Ville Syrjälä
> > Reviewed-by: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
> >
On Tue, Apr 04, 2017 at 05:12:59PM +0200, Neil Armstrong wrote:
> On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> > Drive-by cleanup.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a
On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> driver, we will finally have two types of layer.
>
> Abstract the layer type to void * and a ops struct, which contains the
> only function used by crtc -- get
https://bugs.freedesktop.org/show_bug.cgi?id=100563
Bug ID: 100563
Summary: Compile fails with radeonsi / LLVM (git)
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity
On 17-04-04 11:07:26, Daniel Stone wrote:
Hi,
On 1 April 2017 at 19:47, Rob Clark wrote:
On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
wrote:
This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
information about the modifiers that will work with each format.
So, just to
On Sat, Apr 01, 2017 at 07:35:25PM +0800, Jeffy Chen wrote:
Hi Jeffy,
Could you please add commit messages describing *why* you're making the change?
It might be obvious to you (and maybe me), but others will benefit from better
descriptions.
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v2:
On Sat, Apr 01, 2017 at 07:35:26PM +0800, Jeffy Chen wrote:
> We should not cleanup iommu before cleanup other resources.
>
> Reorder unload sequence, follow exynos drm.
This doesn't match the cleanup sequence in rockchip_drm_bind. Also make sure
that you're unwinding the setup sequence when you
From: Ander Conselvan de Oliveira
When using the atomic API, one request can span multiple CRTCs, however
one event is generated per CRTC. As we cannot disambiguate the CRTC with
user data (since we only have one piece of user data to pass in), newer
kernels can include the CRTC ID in the page fl
Generated using make headers_install, based on drm-misc-next commit
5db06a8a98f515f67446a69c57577c4c363ec65d.
This clarifies the comments around modifiers such that they are
per-framebuffer rather than per-plane, adds the beginnings of aspect
ratio mode flags, link status properties, and updates t
Hi,
On 4 April 2017 at 18:58, Sean Paul wrote:
> On Tue, Apr 04, 2017 at 05:52:21PM +0100, Daniel Stone wrote:
>> With the atomic API, it is possible that a single commit affects
>> multiple crtcs. If the user requests an event with that commit, one
>> event will be sent for each CRTC, but it is
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #2 from aceman ---
I can test patches if you have any ideas. Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fr
On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter wrote:
> On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
> wrote:
> >> If I could guarantee that I'd only ever run on 4.13-or-later kernels
> >> (I think that's when the previous patches will land?), then this would
> >> indeed be mostly unnecessary. It
Hi all,
After merging the drm-misc tree, today's linux-next build
(arm_multi_v7_defconfig) produced this warning:
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning:
'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_form
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: 983e43e08f9a585c473cd2260ede84df228db38d
commit: 798dc4bd063b3536ba962cc92833a3798822771c [25/44] drm/amdgpu: handle CPU
access for split VRAM buffers
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (De
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #14 from sephirot...@gmail.com ---
TLDR: The issue is with LLVM >3.9.
I started bisecting between the two versions I knew had differences (13.0.5 and
17.0.1). I started with 17.0.1 and was using LLVM 4.0, but then to compile
13.0.5 I
On Tue, Apr 04, 2017 at 01:32:39PM -0400, Sean Paul wrote:
> On Tue, Apr 04, 2017 at 09:47:38PM +0800, Shawn Guo wrote:
> > On Mon, Apr 03, 2017 at 11:23:51AM +0200, Daniel Vetter wrote:
> > > > +static int zx_vga_ddc_register(struct zx_vga *vga)
> > > > +{
> > > > + struct device *dev = vga-
On Wed, Apr 05, 2017 at 02:08:52PM +0800, Shawn Guo wrote:
> On Tue, Apr 04, 2017 at 01:32:39PM -0400, Sean Paul wrote:
> > On Tue, Apr 04, 2017 at 09:47:38PM +0800, Shawn Guo wrote:
> > > On Mon, Apr 03, 2017 at 11:23:51AM +0200, Daniel Vetter wrote:
> > > > > +static int zx_vga_ddc_register(struc
On Wed, Apr 05, 2017 at 12:20:46AM +, Christopher James Halse Rogers wrote:
> On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter wrote:
>
> > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
> > wrote:
> > >> If I could guarantee that I'd only ever run on 4.13-or-later kernels
> > >> (I think that's w
On Tue, Apr 04, 2017 at 12:59:25PM +0200, Maarten Lankhorst wrote:
> mode_valid() called from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected
As the DRM LVDS panel driver uses a different approach to DT bindings
compared to what Thierry Reding advocates, add a specific MAINTAINERS
entry to avoid bothering Thierry with requests related to that driver.
Signed-off-by: Laurent Pinchart
---
MAINTAINERS | 8
1 file changed, 8 inser
On Wed, Apr 5, 2017 at 4:27 PM, Daniel Vetter wrote:
On Wed, Apr 05, 2017 at 12:20:46AM +, Christopher James Halse
Rogers wrote:
On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter
wrote:
> On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
> wrote:
> >> If I could guarantee that I'd only ev
On 03/01/17 14:06, Tomi Valkeinen wrote:
> I got this with your series. AM5 EVM, dual display, I run "kmstest --flip"
> and then
> exit by pressing enter, which is when I see the warning. It happens only
> sometimes,
> but having lots of cpu load (I used "stress -c 4") makes the driver spam the
Hi Dave,
On Wednesday 05 Apr 2017 09:51:27 Laurent Pinchart wrote:
> As the DRM LVDS panel driver uses a different approach to DT bindings
> compared to what Thierry Reding advocates, add a specific MAINTAINERS
> entry to avoid bothering Thierry with requests related to that driver.
>
> Signed-of
101 - 169 of 169 matches
Mail list logo
