On Mon, 17 Jul 2023 at 14:54, Simon Ser wrote:
>
> On Monday, July 17th, 2023 at 15:24, Emil Velikov
> wrote:
>
> > > > For going forward, here is one way we can shave this yak:
> > > > - update libdrm to max 64 nodes
> > > > - roll libdrm rel
On Mon, 17 Jul 2023 at 10:45, Simon Ser wrote:
>
> On Monday, July 17th, 2023 at 09:30, Emil Velikov
> wrote:
>
> > > I'm worried what might happen with old user-space, especially old libdrm.
> >
> > I also share the same concern. Although the bigger
On Fri, 14 Jul 2023 at 11:32, Simon Ser wrote:
>
> (cc Daniel Vetter and Pekka because this change has uAPI repercussions)
>
> On Friday, June 30th, 2023 at 13:56, James Zhu wrote:
>
> > From: Christian König
> >
> > This makes room for up to 128 DRM devices.
> >
> > Signed-off-by: Christian Kön
Hi Tvrtko
Sorry for the delay, real life and other obligations got in the way.
On Thu, 8 Jun 2023 at 15:26, Tvrtko Ursulin
wrote:
> On 21/04/2023 13:13, Emil Velikov wrote:
> Are you okay if I just paste your very fine explanation verbatim, with
> credits?
>
Yes, feel free to us
Hi Dmitry,
Saw v3 fly by, so I had a quick look. Original RB still stands,
although I noticed a couple of non-blocking nitpicks.
On Sun, 21 May 2023 at 22:00, Dmitry Osipenko
wrote:
> -static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> +static int drm_gem_shmem_get_
polish this commit
is:
Reviewed-by: Emil Velikov
I also had a brief look at 01/10, although I cannot find many
references for the pid <> tguid mappings. Be that on the kernel side
or userspace - do you have any links that I can educate myself?
Thanks
Emil
On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
wrote:
> On 21/04/2023 11:26, Emil Velikov wrote:
> > On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >
> >> +/**
> >> + * enum drm_gem_object_status - bitmask of object state for fdinfo
> >> reporting
&g
ly_
> + * become puregeable until it becomes idle. The status gem object func does
nit: s/puregeable/purgeable/
I think we want a similar note in the drm-usage-stats.rst file.
With the above the whole series is:
Reviewed-by: Emil Velikov
Fwiw: Keeping the i915 patch as part of this ser
? Consistency across drivers and all that.
>
> Hmm, I guess I could _also_ store the overridden comm/cmdline in
> drm_file. I still need to track it in ctx (msm_file_private) because
> I could need it after the file is closed.
>
> Maybe it could be useful to have a gl extension to let the app set a
> name on the context so that this is useful beyond native-ctx (ie.
> maybe it would be nice to see that "chrome: lwn.net" is using less gpu
> memory than "chrome: phoronix.com", etc)
>
/me awaits for the series to hit the respective websites ;-)
But seriously - the series from Tvrtko (thanks for the link, will
check in a moment) makes sense. Although given the livespan issue
mentioned above, I don't think it's applicable here.
So if it were me, I would consider the two orthogonal for the
short/mid term. Fwiw this and patch 1/3 are:
Reviewed-by: Emil Velikov
HTH
-Emil
if (ret) {
> + virtio_gpu_free_post_deps(post_deps, i);
> + return ret;
> + }
> +
> + submit->num_out_syncobjs = num_out_syncobjs;
> + submit->post_deps = post_deps;
> +
> + return 0;
> +}
> +
With the two issues in virtio_gpu_parse_post_deps() addressed, the series is:
Reviewed-by; Emil Velikov
HTH
Emil
DRIVER_RENDER |
> DRIVER_ATOMIC |
> DRIVER_MODESET |
> + DRIVER_SYNCOBJ_TIMELINE |
This line should probably be its own patch. AFAICT it was supported
since ab723b7a992a19b843f798b183f53f7472f598c8, although explicitly
kept disabled until there's userspace/turnip support.
With the above line removed, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
s &= ~DRM_GEM_OBJECT_PURGEABLE;
Is MSM capable of marking the object as both purgeable and resident or
is this to catch other drivers? Should we add a note to the
documentation above - resident memory cannot be purgeable
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
Ditto.
With the above nits, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
avoid other branch build fail after merge
> drm-misc-next, just revert the lima patchset on drm-misc-next too.
>
The bug/revert is unfortunate, although we better keep the build clean
or Linus will go bananas ^_^
Fwiw for the series:
Acked-by: Emil Velikov
HTH
-Emil
Greetings Sui Jingfeng,
I haven't been around drm-land for a while and this is the first
driver I skim through in a few years. So take the following
suggestions with a healthy pinch of salt.
Hope that helps o/
On Mon, 3 Apr 2023 at 18:13, Sui Jingfeng wrote:
> v7 -> v8:
>1) Zero a compil
On Mon, 3 Apr 2023 at 15:50, Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.04.23 um 16:27 schrieb Emil Velikov:
> > On Mon, 3 Apr 2023 at 11:41, Thomas Zimmermann wrote:
> >>
> >> Move code from ad-hoc fbdev callbacks into DRM client functions
> >>
On Mon, 3 Apr 2023 at 11:41, Thomas Zimmermann wrote:
>
> Move code from ad-hoc fbdev callbacks into DRM client functions
> and remove the old callbacks. The functions instruct the client
> to poll for changed output or restore the display. The DRM core
> calls both, the old callbacks and the new
cked(struct drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + drm_WARN_ON(obj->dev, obj->import_attach);
> +
Ditto.
With that the series is:
Reviewed-by; Emil Velikov
HTH
-Emil
On Mon, 3 Apr 2023 at 14:00, Emil Velikov wrote:
> > > I think we should zero num_(in|out)_syncobjs when the respective parse
> > > fails. Otherwise we get one "cleanup" within the parse function itself
> > > and a second during the cleanup_submit. Haven&#
On Sun, 2 Apr 2023 at 18:45, Dmitry Osipenko
wrote:
>
> On 3/30/23 20:24, Emil Velikov wrote:
> > Hi Dmitry,
> >
> > Have you considered creating a few DRM helpers for this functionality?
> >
> > AFAICT this is the third driver which supports syncobj tim
Hi Dmitry,
Have you considered creating a few DRM helpers for this functionality?
AFAICT this is the third driver which supports syncobj timelines and
looking at one of the implementations ... it is not great. Note that
this suggestion is _not_ a blocker.
On 2023/03/24, Dmitry Osipenko wrote:
>
Hey Dmitry,
On 2023/03/24, Dmitry Osipenko wrote:
> Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file
> and refactor the code along the way to ease addition of new features to
> the ioctl.
>
At a glance, we have a handful of no-op as well as some functional
changes - let's s
option to disable KMS support")
> > Signed-off-by: Dmitry Osipenko
> > ---
>
> Added r-b from Emil and applied to misc-next
>
For anyone wondering: I've sent that in private, adding here for posterity
Reviewed-by: Emil Velikov
-Emil
On 2023/03/06, Dmitry Osipenko wrote:
> VirtIO-GPU got a new config option for disabling KMS. There were two
> problems left unnoticed during review when the new option was added:
>
> 1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was
> inverted, hence KMS was disabled when it shou
On Sat, 3 Dec 2022 at 09:45, Cai Huoqing wrote:
>
> Commit 399516ab0fee ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers")
> marked these drivers obsolete 7 years ago.
As the author of said patch - calling them obsolete was a bad decision
on my part.
They are effectively orphan with no main
t; Daniel Vetter
> Cai Huoqing
> Neil Roberts
> Marek Szyprowski
> Emil Velikov
> Sam Ravnborg
> Boris Brezillon
> Dan Carpenter
>
> Signed-off-by: Robert Swindells
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> include/drm/drm_gem_shmem_helper.h
On 2022/07/05, Gerd Hoffmann wrote:
> Hi,
>
> > > Also note that pci is not the only virtio transport we have.
> >
> > The VirtIO indeed has other transports, but only PCI is really supported
> > in case of the VirtIO-GPU in kernel and in Qemu/crosvm, AFAICT. Hence
> > only the PCI transport wa
On 2022/07/05, Dmitry Osipenko wrote:
> On 7/5/22 18:45, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Also note that pci is not the only virtio transport we have.
> >>
> >> The VirtIO indeed has other transports, but only PCI is really supported
> >> in case of the VirtIO-GPU in kernel and in Qemu/cro
On Mon, 28 Mar 2022 at 03:09, Xiaomeng Tong wrote:
>
> on Sun, 27 Mar 2022 16:59:28 +0100, Emil Velikov wrote:
> > On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
> > >
> > > The bug is here:
> > > return encoder;
> > >
> > > T
spec mention).
But that is for another day.
As-is the series is:
Reviewed-by: Emil Velikov
HTH
Emil
On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
>
> The bug is here:
> return encoder;
>
> The list iterator value 'encoder' will *always* be set and non-NULL
> by drm_for_each_encoder_mask(), so it is incorrect to assume that the
> iterator value will be NULL if the list is empty or no
timate fixes that we want regardless of the shrinker.
Please add the respective "Fixes" tag, so they find their way in the
stable trees. With that, them 3 are:
Reviewed-by: Emil Velikov
HTH
Emil
Greetings everyone,
Food for thought: Would it make sense to have the madvise ioctl as
generic DRM one?
Looking around - i915, msm & panfrost already have one and the virtio
implementation [below] seems as generic as it gets.
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
wrote:
> +#define VIRTG
On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> >
On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
>
Greetings everyone,
Padron for joining in so late o/
On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_re
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc",
> { "gvt: cmd: ", "command processing" },
> { "gvt: core: ", "core help" },
> { "gvt: dpy: ", "display help" },
> { "gvt: el: ", "help" },
>
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> +struct dyndbg_bitdesc {
> + /* bitpos is inferred from index in containing array */
> + char *prefix;
> + char *help;
AFAICT these two should also be constant, right?
> +int param_set_dyndbg(const char *instr, const s
Hi Jim,
On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote:
> Use of this new data member will be rare, it might be worth redoing
> this as a separate/sub-type to keep the base case.
>
> Signed-off-by: Jim Cromie
> ---
> include/linux/moduleparam.h | 11 +--
> 1 file changed, 9 insertions(
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
> @@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
> struct drm_master *master;
>
;get lease for %d\n", lessee->lessee_id);
>
> + mutex_lock(&dev->master_mutex);
As-is we're dereferencing an uninitialised pointer in DRM_DEBUG_LEASE.
Move the lock and assignment before the DRM_DEBUG_LEASE, just like
you've done in the list ioctl.
With this fix, the patch is;
Reviewed-by: Emil Velikov
-Emil
we implement
> drm_is_current_master_locked() to be used within drm_auth.c, and
> modify drm_is_current_master() to grab the device's master mutex
> before checking the master status.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Emil Velikov
-Emil
On Fri, 11 Jun 2021 at 10:47, Daniel Vetter wrote:
>
> On Thu, Jun 10, 2021 at 02:36:59PM -0700, Dongwon Kim wrote:
> > Render clients should be able to create/destroy dumb object to import
> > and use it as render buffer in case the default DRM device is different
> > from the render device (i.e.
On Thu, 10 Jun 2021 at 11:10, Daniel Vetter wrote:
>
> On Wed, Jun 09, 2021 at 05:21:19PM +0800, Desmond Cheong Zhi Xi wrote:
> > This patch eliminates the following smatch warning:
> > drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access
> > 'master' (line 318) expected lock
On Fri, 4 Jun 2021 at 16:49, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Currently as the workaround is applied the screen flickers. As a result
> we do not achieve seamless boot experience.
>
> Avoiding the issue in the common use-case might be hard, although we can
>
On Fri, 4 Jun 2021 at 15:08, Ville Syrjälä
wrote:
>
> On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote:
> > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote:
> > >
> > > Hi Ville,
> > >
> > > On Tue, 18 May 2021 at 12:17, Ville Syrj
From: Emil Velikov
Currently as the workaround is applied the screen flickers. As a result
we do not achieve seamless boot experience.
Avoiding the issue in the common use-case might be hard, although we can
resolve it for dual GPU setups - when the "other" GPU is primary and/or
o
On Wed, 26 May 2021 at 17:21, Emil Velikov wrote:
>
> Hi Ville,
>
> On Tue, 18 May 2021 at 12:17, Ville Syrjälä
> wrote:
> >
> > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > > Hi Ville,
> > >
> > > On Mon, 17 May 2021 at
o see if there is a privacy-screen (and to which
> GPU,output combo it should be mapped). So if CONFIG_DRM_PRIVACY_SCREEN
> is enabled and drm.ko is builtin then it must be builtin too, at which
> point it is easiest to just make it part of drm.ko .
>
Yes, the initialisation is called
- /dev/null
> +++ b/include/drm/drm_privacy_screen_consumer.h
> +#include
Ditto
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_driver.h
> +#include
Ditto
I like how you avoided leaking any DRM details within the new code,
modulo the includes above. With above tweaks
Hi Ville,
On Tue, 18 May 2021 at 12:17, Ville Syrjälä
wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> > wrote:
> > >
> > > On Sun, May 16, 2021 at 06
On Tue, 18 May 2021 at 12:17, Ville Syrjälä
wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> > wrote:
> > >
> > > On Sun, May 16, 2021 at 06:14:32PM +0
Hi Ville,
On Mon, 17 May 2021 at 18:24, Ville Syrjälä
wrote:
>
> On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> > From: Vivek Das Mohapatra
> >
> > This patch is to do with seamless handover, eg when the sequence is
> > bootloader → plymouth → de
ra
Signed-off-by: Emil Velikov
---
Greetings all,
This patch has been downstream for a while now yet it seems perfectly
reasonable thing to have in the Linux kernel.
https://github.com/ValveSoftware/steamos_kernel/commit/5431b5b1999c3d3b5efee817fb3373fbbd473063
drivers/gpu/drm/i915/display/i
On Tue, 4 May 2021 at 15:58, Simon Ser wrote:
>
> Continuing on that idea to push for enabling the cap in more cases: do
> we have a policy to require new drivers to always support modifiers?
>
> That would be nice, even if it's just about enabling LINEAR.
Sounds perfectly reasonable IMHO. I thin
Hi Daniel,
Thanks for the extra clarification.
On Tue, 27 Apr 2021 at 13:22, Daniel Vetter wrote:
>
> On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> > Hi Daniel,
> >
> > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote:
> >
> &
one says "if
it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
Sadly, nothing comes to mind atm wrt alternative wording.
With the WARN_ON() added or s/must/should/ in the documentation, the series is:
Reviewed-by: Emil Velikov
HTH
-Emil
__
On Mon, 8 Mar 2021 at 13:57, Philipp Zabel wrote:
>
> Hi Emil,
>
> On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The current imx8 code does not use the jpeg encoder. Remove the
> > unnecessary include.
> >
Seems like I messed up the to line and this ended in the wrong list.
Apologies for the noise o/
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Emil Velikov
The Hantro G1 IRQ and reset handling it pretty standard. I was this
close to duplicating it, yet again, before reconsidering and refactoring
it to a separate file.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
From: Emil Velikov
The SoC features a Hantro G1 compatible video decoder.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
arch/arm/boot/dts/sama5d4.dtsi| 9 ++
arch/arm/configs
From: Emil Velikov
While enabling an extra config, I've noticed that savedefconfig produced
a notable delta. Split out the no-op changes for clarity sake.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Ve
From: Emil Velikov
The current imx8 code does not use the jpeg encoder. Remove the
unnecessary include.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c
From: Emil Velikov
The vpu->dec_base is already set by the hantro driver itself.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c | 1 -
1 file changed
From: Emil Velikov
Swap the hardcoded 16 with MB_DIM define.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov
---
drivers/staging/media/hantro/imx8m_vpu_hw.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Emil Velikov
Use the register directly over the existing SWREG().
Ideally we'll port the driver away from the local registers, but for
now this is enough. For context - I was reading through the IRQ register
handling across the variants.
Cc: Ezequiel Garcia
Cc: Philipp Zabel
Cc:
small cleanups.
As you may have noticed, this is my first patches series to linux-media,
so any tips how to make this as smoother process are appreciated.
Looking forward to your feedback,
Emil
Emil Velikov (7):
media: hantro: use G1_REG_INTERRUPT directly for the mpeg2
media: hantro: imx
Greetings everyone,
On Mon, 15 Feb 2021 at 08:52, Lee Jones wrote:
>
> On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote:
>
> > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> > credits and remove the sep
On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
>
> Quoting Emil Velikov (2021-02-12 14:57:56)
> > Hi Chris,
> >
> > On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
> > >
> > > Register with /proc/gpu to provide the client runtimes for generic
Hi Chris,
On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
>
> Register with /proc/gpu to provide the client runtimes for generic
> top-like overview, e.g. gnome-system-monitor can use this information to
> show the per-process multi-GPU usage.
>
Exposing this information to userspace sounds grea
On Fri, 12 Feb 2021 at 14:01, Michel Dänzer wrote:
>
> On 2021-02-12 1:57 p.m., Emil Velikov wrote:
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >>
> >> Userspace has discovered the functionality offered by SYS_kcmp and has
> >> started to d
On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote:
>
> On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
> wrote:
>
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> > >
> > > Userspace has discovered the functionality offered by SYS_kcmp and has
On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
>
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf)
As you rightfully
On Thu, 4 Feb 2021 at 18:17, James Park wrote:
>
> On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > wrote:
> > >
> > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
&
On Wed, 3 Feb 2021 at 14:21, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
> wrote:
>
> > As said before, there are multiple ways to handle this without
> > introducing yet another UAPI header. I don't see why you're dismissing
DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
also using -pedantic _and_ the header lives outside of the standard
/usr/include (like BSDs normally do).
v2:
- Add corner-case handling, based on popular demand.
Cc: James Park
Cc: Pekka Paalanen
Cc: Simon Ser
Signed-off-by: Emil Velikov
On Wed, 3 Feb 2021 at 17:58, Xiong, Jianxin wrote:
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Wednesday, February 03, 2021 9:53 AM
> > To: Xiong, Jianxin
> > Cc: Leon Romanovsky ; Jason Gunthorpe ; Gal
> > Pressman ; Yishai Hadas
> > ; linux-rdma ; Edward
> > Srouji ; d
On Wed, 3 Feb 2021 at 13:47, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
> wrote:
>
> > No issue then, great. Let's merge this trivial solution and move on to
> > other things.
>
> Just because one compositor isn't affe
On Wed, 3 Feb 2021 at 10:15, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 11:08 AM, Emil Velikov
> wrote:
>
> > On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
> > >
> > > On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
>
> On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> emil.l.veli...@gmail.com wrote:
>
> > As summed in the commit message the burden is only applicable when all
> > of the following are set:
>
On Tue, 2 Feb 2021 at 23:25, James Park wrote:
>
> On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov wrote:
> >
> > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > At the same time drm.h pulls a lot of unneeded symbols.
> >
> > Add ne
Hi james,
On Tue, 2 Feb 2021 at 18:15, James Park wrote:
>
> I'm not sure what your suggestion is. Move which #ifdef block where?
>
Fair enough. Just sent out a patch which demonstrates what I have in mind.
Thanks
Emil
P.S. Please try to avoid top-posting and HTML emails in public discussions.
c99
mode. One is welcome to ignore the warning, silence it or use c11. If neither
of the three is an option, then do _not_ set the new guard.
Cc: James Park
Cc: Pekka Paalanen
Cc: Simon Ser
Signed-off-by: Emil Velikov
---
As mentioned before - there's little point in having yet another h
ince. So I
> think it's safe to retire those export types now.
>
I believe you're spot on - based on reading through git log and
checking the ML archives.
Shame I didn't get to finish a similar series I had locally. Patches
11-13 match what I have here so:
Reviewed-by: Emil Vel
Hi James,
On Tue, 2 Feb 2021 at 08:27, James Park wrote:
>
> Hello,
>
> Is there something I can do to help move this patch along?
>
> Thanks,
> James Park
>
> On Thu, Dec 10, 2020 at 1:13 AM James Park wrote:
>>
>> Create drm_basic_types.h to define types previously defined by drm.h.
>>
>> Use
Hey Keith,
Most of the cool kids prefer gitlab MR, can you open one going forward?
That aside, here is some long overdue input on the patch itself.
My biggest concern that we expose the extension, even when it's not implemented.
The rest are rather minor - more documentation/comments, style fixes
Hi Pekka,
Thanks for the patch - merged to drm-misc-next.
While applying the patch the following warning popped-up.
-:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed
SPDX-License-Identifier tag in line 1
#37: FILE: Documentation/gpu/drm-uapi.rst:1:
+.. Copyright 2020 DisplayLink (UK) Ltd.
On Wed, 17 Jun 2020 at 07:28, Thomas Zimmermann wrote:
> Maybe I can write a better commit message to highlight the change.
>
That would be amazing, thank you.
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
Hi Stephen,
On Wed, 17 Jun 2020 at 08:03, Stephen Rothwell wrote:
>
> Hi Thomas,
>
> On Wed, 17 Jun 2020 08:33:24 +0200 Thomas Zimmermann
> wrote:
> >
> > We recently dropped the _unlock() suffix from drm_gem_object_put(). This
> > patch should be ok.
>
> Yes, but what it shows is that the drm-
On Tue, 16 Jun 2020 at 18:20, Dmitry Osipenko wrote:
>
> 16.06.2020 18:48, Emil Velikov пишет:
> > On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko wrote:
> >>
> >> 16.06.2020 01:26, Emil Velikov пишет:
> >>> Hi Dmitry,
> >>>
>
Hi all,
Allow me to compare this approach with some work Linus W [1] did a
while back, which I've just noticed.
Pauls' approach:
- Perhaps the shortest one possible
Porting an existing DSI panel to DBI is 3 lines of code - compat line
in the SPI/DSI bridge, a bus_type and
mipi_dsi_maybe_registe
Hi all,
Inspired by Linus and my personal confusion with the report, allow me
to put some suggestions. Followed by an illustrative example.
On Wed, 10 Jun 2020 at 08:38, kernel test robot wrote:
>
> Hi Linus,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on dr
On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko wrote:
>
> 16.06.2020 01:26, Emil Velikov пишет:
> > Hi Dmitry,
> >
> > On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko wrote:
> >>
> >> Hello!
> >>
> >> This series adds 180° display plane r
On Mon, 15 Jun 2020 at 22:47, Manasi Navare wrote:
>
> On Mon, Jun 15, 2020 at 10:36:28PM +0100, Emil Velikov wrote:
> > Hi Manasi,
> >
> > On Sat, 13 Jun 2020 at 00:55, Manasi Navare
> > wrote:
> > >
> > > From: Bhanuprakash Modem
> > &
Hi Thomas,
On Tue, 16 Jun 2020 at 15:26, Thomas Zimmermann wrote:
>
> The original modesetting code set MISC to 0x2d, which is ,
> and
>
> With the conversion to atomic modesetting, accidentally
> got enabled as well. Revert this change and initialize MISC with a
> constant value of and . The
Hi all,
On Tue, 16 Jun 2020 at 13:12, Daniel Vetter wrote:
>
> On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> > I want to remove the above API this cycle, and just a few patches have
> > not made it into 5.8-rc1. They have been reviewed and most had been
> > promised to get into
On Tue, 16 Jun 2020 at 07:50, Daniel Vetter wrote:
>
> On Mon, Jun 15, 2020 at 11:35 PM Emil Velikov
> wrote:
> >
> > Hi Daniel,
> >
> > On Fri, 12 Jun 2020 at 17:01, Daniel Vetter wrote:
> > >
> > > The atomic helpers try really hard to
Hi Rong,
Thanks for the prompt reply and information. Can I suggest including
the suggested information in future reports.
I've included a command for each one, to aid automating things.
Namely:
Xorg: 1.20.4 (or None)
$ which Xorg 2>/dev/null || echo None && Xorg -version |& grep -o "X
Server.*"
Hi Linus,
On Sat, 13 Jun 2020 at 23:30, Linus Walleij wrote:
>
> The following bug appeared in the MCDE driver/display
> initialization during the recent merge window.
>
> First the place we call drm_fbdev_generic_setup() in the
> wrong place: this needs to be called AFTER calling
> drm_dev_regis
P_AST2000, NULL),
> AST_VGA_DEVICE(PCI_CHIP_AST2100, NULL),
> - /* AST_VGA_DEVICE(PCI_CHIP_AST1180, NULL), - don't bind to 1180
> for now */
Since we don't bind to this pciid, the (removed) code is never
used/dead. For the series:
Reviewed-by: Emil Veliko
Hi Dmitry,
On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko wrote:
>
> Hello!
>
> This series adds 180° display plane rotation support to the NVIDIA Tegra
> DRM driver which is needed for devices that have display panel physically
> mounted upside-down, like Nexus 7 tablet device for example [1]. Si
1 - 100 of 2172 matches
Mail list logo
