[PATCH v2] drm/qxl: use ttm_tt
qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt
instead, to avoid wasting resources (swiotlb bounce buffers for
example).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 36ea993aac..92f5db5b29 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -204,7 +204,7 @@ static void qxl_ttm_io_mem_free(struct ttm_bo_device *bdev,
* TTM backend functions.
*/
struct qxl_ttm_tt {
- struct ttm_dma_tt ttm;
+ struct ttm_tt ttm;
struct qxl_device *qdev;
u64 offset;
};
@@ -233,7 +233,7 @@ static void qxl_ttm_backend_destroy(struct ttm_tt *ttm)
{
struct qxl_ttm_tt *gtt = (void *)ttm;
- ttm_dma_tt_fini(>t->ttm);
+ ttm_tt_fini(>t->ttm);
kfree(gtt);
}
@@ -253,13 +253,13 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
ttm_buffer_object *bo,
gtt = kzalloc(sizeof(struct qxl_ttm_tt), GFP_KERNEL);
if (gtt == NULL)
return NULL;
- gtt->ttm.ttm.func = &qxl_backend_func;
+ gtt->ttm.func = &qxl_backend_func;
gtt->qdev = qdev;
- if (ttm_dma_tt_init(>t->ttm, bo, page_flags)) {
+ if (ttm_tt_init(>t->ttm, bo, page_flags)) {
kfree(gtt);
return NULL;
}
- return >t->ttm.ttm;
+ return >t->ttm;
}
static void qxl_move_null(struct ttm_buffer_object *bo,
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: gsc: Variable "gscblk_cfg" in function gsc_set_gscblk_fimd_wb() could be uninitialized
Hi
On 2019-01-28 19:28, Yizhuo wrote:
> In function gsc_set_gscblk_fimd_wb(), local variable "gscblk_cfg"
> could be uninitialized of function regmap_read returns -EINVAL.
> However, this value will be write to the register after "or"
> operation. This is potentially unsafe.
>
> Signed-off-by: Yizhuo
> ---
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 0506b2b17ac1..b1d0f974fe80 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -441,11 +441,16 @@ static int gsc_sw_reset(struct gsc_context *ctx)
> static void gsc_set_gscblk_fimd_wb(struct gsc_context *ctx, bool enable)
This function has been completely removed in mainline kernel by commit
8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API"), so
there is no need for any fix anymore.
> {
> unsigned int gscblk_cfg;
> + int ret;
>
> if (!ctx->sysreg)
> return;
>
> - regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, &gscblk_cfg);
> + ret = regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, &gscblk_cfg);
> + if (ret) {
> + DRM_ERROR("gsc: Fail to read system register\n");
> + return;
> + }
>
> if (enable)
> gscblk_cfg |= GSC_BLK_DISP1WB_DEST(ctx->id) |
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
Den 29.01.2019 01.19, skrev Eric Anholt:
> Noralf Trønnes writes:
>
>> Den 28.01.2019 21.57, skrev Rob Herring:
>>> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
Den 30.11.2018 00.58, skrev Eric Anholt:
> Daniel Vetter writes:
>
>> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
>>> Daniel Vetter writes:
>>>
On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
>> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>>> Noralf Trønnes writes:
+static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
+{
+ struct drm_gem_object *obj = vma->vm_private_data;
+ struct drm_gem_shmem_object *shmem =
to_drm_gem_shmem_obj(obj);
+
+ drm_gem_shmem_put_pages(shmem);
+ drm_gem_vm_close(vma);
+}
+
+const struct vm_operations_struct drm_gem_shmem_vm_ops = {
+ .fault = drm_gem_shmem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_shmem_vm_close,
+};
+EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
>>> I just saw a warning from drm_gem_shmem_put_pages() for
>>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
>>> drm_gem_shmem_get_pages().
>> Yeah we need a drm_gem_shmem_vm_open here.
> Adding one of those fixed my refcounting issues, so I've sent out a v6
> with it.
Just realized that I've reviewed this patch already, spotted that vma
management issue there too. Plus a pile of other things. From reading
that
other thread discussion with Noralf concluded with "not yet ready for
prime time" unfortunately :-/
>>> I saw stuff about how it wasn't usable for SPI because SPI does weird
>>> things with DMA mapping. Was there something else?
>> Looking through that mail it was a bunch of comments to improve the
>> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
>> incoherent and horrible (but I guess for vkms we don't care that much).
>> I'm just kinda vary of generic buffer handling that turns out to not be
>> actually all that useful. We have lots of deadends and kinda-midlayers in
>> this area already (but this one here definitely smells plenty better than
>> lots of older ones).
> FWIW, I really want shmem helpers for v3d. The fault handling in
> particular has magic I don't understand, and this is not my first fault
> handler. :/
If you can use it for a "real" hw driver like v3d, I think it makes a lot
sense to have it as a helper. I believe udl and a future simpledrm can
also make use of it.
>>>
>>> FWIW, I think etnaviv at least could use this too.
>>>
>>> I'm starting to look at panfrost and lima drivers and was trying to
>>> figure out where to start with the GEM code. So I've been comparing
>>> etnaviv, freedreno, and vgem implementations. They are all pretty
>>> similar from what I see. The per driver GEM obj structs certainly are.
>>> I can't bring myself to just copy etnaviv code over and do a
>>> s/etnaviv/panfrost/. So searching around a bit, I ended up on this
>>> thread. This seems to be what I need for panfrost (based on my brief
>>> study).
>>>
>>
>> I gave up on this due to problems with SPI DMA.
>> Eric tried to use it with vkms, but it failed. On his blog he speculates
>> that it might be due to cached CPU mappings:
>> https://anholt.github.io/twivc4/2018/12/03/twiv/
>>
>> For tinydrm I wanted cached mappings, but it might not work that well
>> with shmem. Maybe that's why I had problems with SPI DMA.
>
> Actually, for tinydrm buffers that are dma-buf exported through prime, I
> really want tinydrm using WC mappings so that vc4 or v3d rendering (now
> supported on Mesa master with kmsro) works.
>
I thought that the buffer is created by the GPU driver when using PRIME?
And them imported into the tinydrm driver. In which case it doesn't
matter how tinydrm creates it's dumb buffers.
That said, I will stay with CMA buffers for the SPI drivers. It just
works. The reason I looked into shmem, is that tindyrm would then be
able to import buffers that isn't contiguous in memory, thus making it
work with more GPU's. And the reason for cached buffers is that with
partial flushing the rectangle is copied to a separate buffer for
transfer and CPU acccess to WC memory is quite slow. But ofc for these
small buffers it's not that big a deal.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/11] drm/fb-helper: generic: Don't take module ref for fbcon
On Mon, Jan 28, 2019 at 03:40:47PM +0100, Noralf Trønnes wrote:
>
>
> Den 21.01.2019 10.05, skrev Daniel Vetter:
> > On Sun, Jan 20, 2019 at 12:43:18PM +0100, Noralf Trønnes wrote:
> >> It's now safe to let fbcon unbind automatically on fbdev unregister.
> >> The crash problem was fixed in commit 2122b40580dd
> >> ("fbdev: fbcon: Fix unregister crash when more than one framebuffer")
> >>
> >> Signed-off-by: Noralf Trønnes
> >> ---
> >> drivers/gpu/drm/drm_fb_helper.c | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> index 31fcf94bf825..5d0327f603bb 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -2999,7 +2999,8 @@ static int drm_fbdev_fb_open(struct fb_info *info,
> >> int user)
> >> {
> >>struct drm_fb_helper *fb_helper = info->par;
> >>
> >> - if (!try_module_get(fb_helper->dev->driver->fops->owner))
> >> + /* No need to take a ref for fbcon because it unbinds on unregister */
> >> + if (user && !try_module_get(fb_helper->dev->driver->fops->owner))
> >
> > Module refcount != driver refcount. You can always unbind a driver through
> > the sysfs unbind file, no matter whether the module is pinned or not. So I
> > think pinng the module is still the right thing to do, just to avoid races
> > and fun stuff.
> >
> > btw, I looked into making fbdev hotunplug safe (i.e. drm_dev_enter/exit,
> > but for fbdev) over the holidays. Fixing that properly for fbdev userspace
> > clients looks like serious amounts of work, and I think it's impossible
> > for fbcon. Or at least I didn't come up with a workable idea to sprinkle
> > the dev_enter/exit stuff around. For the userspace side the basic
> > infrastructure with get_fb_info() and put_fb_info() is there already.
> >
>
> fbdev blocks file operations after unregister through this function:
>
> static struct fb_info *file_fb_info(struct file *file)
> {
> struct inode *inode = file_inode(file);
> int fbidx = iminor(inode);
> struct fb_info *info = registered_fb[fbidx];
>
> if (info != file->private_data)
> info = NULL;
> return info;
> }
>
> static int do_unregister_framebuffer(struct fb_info *fb_info)
> {
> ...
> registered_fb[fb_info->node] = NULL;
> ...
> }
>
> The only way for fbdev userspace to trigger driver actions is through
> mmap and defio. At first I planned to put drm_dev_enter/exit in
> drm_fb_helper_dirty_work(), but realised that the driver would need to
> do the same in it's dirty function to cover DRM userspace anyways, so I
> dropped it. It's the driver's responsibility to protect it's resources.
The above is all about the driver refcounting. Which does exist (but races
badly) for fbdev. The problem is you're changing the module refcount,
which is there to make sure the functions don't disappear. Note that on
the drm side we do the exact same thing, so least for symmetry reasons I
think we should keep it. The refcounting is done by the file open/close
functions since we set fops->owner, not drm code itself, but it's there.
> As for fbcon, yes this is all a spaghetti monster, so better safe than
> sorry I guess. And it's just developers that would benefit from this
> anyways, not having to unbind fbcon before unlaoding the driver module.
Hm yeah, make sense. On second thought, on this patch:
Reviewed-by: Daniel Vetter
-Daniel
>
> Noralf.
>
> > Cheers, Daniel
> >
> >>return -ENODEV;
> >>
> >>return 0;
> >> @@ -3009,7 +3010,8 @@ static int drm_fbdev_fb_release(struct fb_info
> >> *info, int user)
> >> {
> >>struct drm_fb_helper *fb_helper = info->par;
> >>
> >> - module_put(fb_helper->dev->driver->fops->owner);
> >> + if (user)
> >> + module_put(fb_helper->dev->driver->fops->owner);
> >>
> >>return 0;
> >> }
> >> --
> >> 2.20.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm: Sync errno values for property lookup errors
On Fri, Jan 25, 2019 at 11:01:48PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Use ENOENT consistently for the case where the requested property
> > > isn't found, and EINVAL for the case where the object has no
> > > properties whatsoever. Currenrly these are handled differently
> > > in the atomic and legacy codepaths.
> > >
> > > Signed-off-by: Ville Syrjälä
> >
> > Matches
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
> >
> > Reviewed-by: Daniel Vetter
> >
> > Any igts that blow up with this? We should have at least some trying to do
> > invalid stuff ...
>
> Looks like there was something caught by ci. I'll have to look those
> over.
>
> Also the logs seem to full of my
> <7> [625.952666] [drm:drm_modeset_backoff] Retrying to avoid deadlock
>
> Not sure if that debug print is a good idea after all :/
Make it conditional on !CONFIG_WW_MUTEX_DEBUG_SLOWPATH. With that set
(which CI does) you'll get tons of retries.
Or maybe that's the point of all this? We do an awful lot of retries in
CI, to make sure all the error paths work correctly. ww_mutex locking is
essntially our kms error injection tool :-)
-Daniel
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> > > drivers/gpu/drm/drm_mode_object.c | 1 +
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index 06390307e5a3..2a54f826cf65 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -1330,7 +1330,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > > DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> > >obj_id);
> > > drm_mode_object_put(obj);
> > > - ret = -ENOENT;
> > > + ret = -EINVAL;
> > > goto out;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index e8dac94d576d..31730d935842 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -527,6 +527,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
> > > *dev, void *data,
> > > property = drm_mode_obj_find_prop_id(arg_obj, arg->prop_id);
> > > if (!property) {
> > > DRM_DEBUG_KMS("Unknown property ID %d\n", arg->prop_id);
> > > + ret = -ENOENT;
> > > goto out_unref;
> > > }
> > >
> > > --
> > > 2.19.2
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/qxl: use ttm_tt
Den 29.01.2019 09.25, skrev Gerd Hoffmann: > qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt > instead, to avoid wasting resources (swiotlb bounce buffers for > example). > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm: drop drm_bus from todo
On Sun, Jan 27, 2019 at 12:00:37PM +0100, David Herrmann wrote:
> Hey
>
> On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> > David Herrmann removed the last bits of drm_bus in:
> > c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
> >
> > Remove the todo item.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: David Herrmann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > ---
> > Documentation/gpu/todo.rst | 19 ---
> > 1 file changed, 19 deletions(-)
>
> I miss drm_bus!
>
> Reviewed-by: David Herrmann
Sam, want drm-misc commit rights to start merging your own stuff? Assuming
you plan to stick around ofc ... I'll also ask the drm-misc maintainers
whether that's ok.
Thanks, Daniel
>
> Thanks
> David
>
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 38360ede1221..d9515b17d36f 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -10,25 +10,6 @@ graphics subsystem useful as newbie projects. Or for
> > slow rainy days.
> > Subsystem-wide refactorings
> > ===
> >
> > -De-midlayer drivers
> >
> > -
> > -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer
> > required
> > -to have a ``drm_bus`` structure set up. Drivers can directly set up the
> > -``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
> > -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
> > -``->unload`` callbacks and open-code the load/unload sequence properly,
> > using
> > -the new two-stage ``drm_device`` setup/teardown.
> > -
> > -Once all existing drivers are converted we can also remove those bus
> > support
> > -files for USB and platform devices.
> > -
> > -All you need is a GPU for a non-converted driver (currently almost all of
> > -them, but also all the virtual ones used by KVM, so everyone qualifies).
> > -
> > -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers
> > -
> > -
> > Remove custom dumb_map_offset implementations
> > -
> >
> > --
> > 2.12.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/doc: Add a warning to drm_dev_is_unplugged
It's probably not what you want, definitely not after Noralf's work to
add drm_dev_enter/exit.
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
include/drm/drm_drv.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 9a688cf12881..ca46a45a9cce 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -740,6 +740,10 @@ void drm_dev_unplug(struct drm_device *dev);
* Unplugging itself is singalled through drm_dev_unplug(). If a device is
* unplugged, these two functions guarantee that any store before calling
* drm_dev_unplug() is visible to callers of this function after it completes
+ *
+ * WARNING: This function fundamentally races against drm_dev_unplug(). It is
+ * recommended that drivers instead use the underlying drm_dev_enter() and
+ * drm_dev_exit() function pairs.
*/
static inline bool drm_dev_is_unplugged(struct drm_device *dev)
{
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh
On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Use the drm_mode_vrefresh helper where we need refresh rate in case
> vrefresh is empty.
>
> Signed-off-by: Sean Paul
I think adding a todo to remove these fields and switch everone over to
the helpers would be useful. Recomputing is not going to hurt us I think
in modeset code (the one case where we do care is vblank constants, and
those are somewhere else), and would avoid all these bugs ...
-Daniel
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
> 4 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 941ac25d2a023..dd71cb6ba4f5c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -522,8 +522,8 @@ static void _dpu_encoder_adjust_mode(struct drm_connector
> *connector,
>
> list_for_each_entry(cur_mode, &connector->modes, head) {
> if (cur_mode->vdisplay == adj_mode->vdisplay &&
> - cur_mode->hdisplay == adj_mode->hdisplay &&
> - cur_mode->vrefresh == adj_mode->vrefresh) {
> + cur_mode->hdisplay == adj_mode->hdisplay &&
> + drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
> {
> adj_mode->private = cur_mode->private;
> adj_mode->private_flags |= cur_mode->private_flags;
> }
> @@ -1805,7 +1805,7 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> bool async)
>
> atomic_set(&dpu_enc->frame_done_timeout,
> DPU_FRAME_DONE_TIMEOUT * 1000 /
> - drm_enc->crtc->state->adjusted_mode.vrefresh);
> +
> drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
> mod_timer(&dpu_enc->frame_done_timer, jiffies +
> ((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> index 99ab5ca9bed3b..f21163313d635 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> @@ -404,7 +404,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> return;
> }
>
> - tc_cfg.vsync_count = vsync_hz / (mode->vtotal * mode->vrefresh);
> + tc_cfg.vsync_count = vsync_hz /
> + (mode->vtotal * drm_mode_vrefresh(mode));
>
> /* enable external TE after kickoff to avoid premature autorefresh */
> tc_cfg.hw_vsync_mode = 0;
> @@ -424,7 +425,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> DPU_DEBUG_CMDENC(cmd_enc,
> "tc %d vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
> phys_enc->hw_pp->idx - PINGPONG_0, vsync_hz,
> - mode->vtotal, mode->vrefresh);
> + mode->vtotal, drm_mode_vrefresh(mode));
> DPU_DEBUG_CMDENC(cmd_enc,
> "tc %d enable %u start_pos %u rd_ptr_irq %u\n",
> phys_enc->hw_pp->idx - PINGPONG_0, tc_enable, tc_cfg.start_pos,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index b01183b309b9e..da1f727d74957 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -387,7 +387,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane
> *plane,
> ot_params.width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
> ot_params.height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
> ot_params.is_wfd = !pdpu->is_rt_pipe;
> - ot_params.frame_rate = crtc->mode.vrefresh;
> + ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
> ot_params.vbif_idx = VBIF_RT;
> ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
> ot_params.rd = true;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> index c1962f29ec7d6..6341ac010f7de 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> @@ -59,10 +59,10 @@ static int pingpong_tearcheck_setup(struct drm_encoder
> *encoder,
> return -EINVAL;
> }
>
> - total_lines_x100 = mode->vtotal * mode->vrefresh;
> + total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode);
> if (!total_lines_x100) {
> DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
> - __func__, mode->vtotal, mode->vrefresh);
> + __func__, mode->vtotal, drm_mode
Re: [PATCH] drm/amd/powerplay: Fix missing break in switch
On 1/28/19 10:19 AM, Alex Deucher wrote:
> On Fri, Jan 25, 2019 at 5:31 PM Gustavo A. R. Silva
> wrote:
>>
>> Add missing break statement in order to prevent the code from falling
>> through to the default case.
>>
>> The resoning for this is that pclk_vol_table is an automatic variable.
>> So, it makes no sense to update it just before falling through to the
>> default case and return -EINVAL.
>>
>> This bug was found thanks to the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Fixes: cd70f3d6e3fa ("drm/amd/powerplay: PP/DAL interface changes for
>> dynamic clock switch")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Gustavo A. R. Silva
>
> Applied. Thanks!
>
Great. :)
Thanks, Alex.
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/13] gpu: host1x: Use direct DMA with IOMMU API usage
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> If we use the IOMMU API directly to map buffers into host1x' IOVA space,
> we must make sure that the DMA API doesn't already set up a mapping, or
> else translation will fail.
>
> The direct DMA API allows us to allocate memory that will not be mapped
> through an IOMMU automatically.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/host1x/cdma.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index 91df51e631b2..ccde23a0109c 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -19,6 +19,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -70,6 +71,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer
> *pb)
> */
> static int host1x_pushbuffer_init(struct push_buffer *pb)
> {
> + unsigned long attrs = DMA_ATTR_WRITE_COMBINE;
> struct host1x_cdma *cdma = pb_to_cdma(pb);
> struct host1x *host1x = cdma_to_host1x(cdma);
> struct iova *alloc;
> @@ -91,8 +93,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>
> size = iova_align(&host1x->iova, size);
>
> - pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> - GFP_KERNEL);
> + pb->mapped = dma_direct_alloc(host1x->dev, size, &pb->phys,
> + GFP_KERNEL, attrs);
> if (!pb->mapped)
> return -ENOMEM;
>
> @@ -127,7 +129,10 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
> iommu_free_iova:
> __free_iova(&host1x->iova, alloc);
> iommu_free_mem:
> - dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
> + if (host1x->domain)
> + dma_direct_free(host1x->dev, size, pb->mapped, pb->phys, attrs);
> + else
> + dma_free_wc(host1x->dev, size, pb->mapped, pb->phys);
>
> return err;
> }
>
This variant looks good for the current upstream code. Alternatively we could
check the domain->type==IOMMU_DOMAIN_DMA and skip IOMMU initialization on probe.
I may test that nothing breaks with this series for older Tegra's once it all
will appear in -next. Please address Mikko's review-comments and push the
patches once ready.
Reviewed-by: Dmitry Osipenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/13] drm/tegra: Store parent pointer in Tegra DRM clients
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> Tegra DRM clients need access to their parent, so store a pointer to it
> upon registration. It's technically possible to get at this by going via
> the host1x client's parent and getting the driver data, but that's quite
> complicated and not very transparent. It's much more straightforward and
> natural to let the children know about their parent.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - clarify rationale in commit message
>
> drivers/gpu/drm/tegra/drm.c | 2 ++
> drivers/gpu/drm/tegra/drm.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 4b70ce664c41..61dcbd218ffc 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -1041,6 +1041,7 @@ int tegra_drm_register_client(struct tegra_drm *tegra,
> {
> mutex_lock(&tegra->clients_lock);
> list_add_tail(&client->list, &tegra->clients);
> + client->drm = tegra;
> mutex_unlock(&tegra->clients_lock);
>
> return 0;
> @@ -1051,6 +1052,7 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
> {
> mutex_lock(&tegra->clients_lock);
> list_del_init(&client->list);
> + client->drm = NULL;
> mutex_unlock(&tegra->clients_lock);
>
> return 0;
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index f1763b4d5b5f..2c809755bca7 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -88,6 +88,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
> struct tegra_drm_client {
> struct host1x_client base;
> struct list_head list;
> + struct tegra_drm *drm;
>
> unsigned int version;
> const struct tegra_drm_client_ops *ops;
>
Thanks for improving the commit message! Looks good.
Reviewed-by: Dmitry Osipenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/13] drm/tegra: vic: Load firmware on demand
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> Loading the firmware requires an allocation of IOVA space to make sure
> that the VIC's Falcon microcontroller can read the firmware if address
> translation via the SMMU is enabled.
>
> However, the allocation currently happens at a time where the geometry
> of an IOMMU domain may not have been initialized yet. This happens for
> example on Tegra186 and later where an ARM SMMU is used. Domains which
> are created by the ARM SMMU driver postpone the geometry setup until a
> device is attached to the domain. This is because IOMMU domains aren't
> attached to a specific IOMMU instance at allocation time and hence the
> input address space, which defines the geometry, is not known yet.
>
> Work around this by postponing the firmware load until it is needed at
> the time where a channel is opened to the VIC. At this time the shared
> IOMMU domain's geometry has been properly initialized.
>
> As a byproduct this allows the Tegra DRM to be created in the absence
> of VIC firmware, since the VIC initialization no longer fails if the
> firmware can't be found.
>
> Based on an earlier patch by Dmitry Osipenko .
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - actually request firmware on demand
>
> drivers/gpu/drm/tegra/vic.c | 53 +
> 1 file changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
> index d47983deb1cf..9cb10d1e923a 100644
> --- a/drivers/gpu/drm/tegra/vic.c
> +++ b/drivers/gpu/drm/tegra/vic.c
> @@ -181,13 +181,6 @@ static int vic_init(struct host1x_client *client)
> vic->domain = tegra->domain;
> }
>
> - if (!vic->falcon.data) {
> - vic->falcon.data = tegra;
> - err = falcon_load_firmware(&vic->falcon);
> - if (err < 0)
> - goto detach;
> - }
> -
> vic->channel = host1x_channel_request(client->dev);
> if (!vic->channel) {
> err = -ENOMEM;
> @@ -246,6 +239,30 @@ static const struct host1x_client_ops vic_client_ops = {
> .exit = vic_exit,
> };
>
> +static int vic_load_firmware(struct vic *vic)
> +{
> + int err;
> +
> + if (vic->falcon.data)
> + return 0;
> +
> + vic->falcon.data = vic->client->drm;
> +
> + err = falcon_read_firmware(&vic->falcon, vic->config->firmware);
> + if (err < 0)
> + goto cleanup;
> +
> + err = falcon_load_firmware(&vic->falcon);
> + if (err < 0)
> + goto cleanup;
> +
> + return 0;
> +
> +cleanup:
> + vic->falcon.data = NULL;
> + return err;
> +}
> +
> static int vic_open_channel(struct tegra_drm_client *client,
> struct tegra_drm_context *context)
> {
> @@ -256,19 +273,25 @@ static int vic_open_channel(struct tegra_drm_client
> *client,
> if (err < 0)
> return err;
>
> + err = vic_load_firmware(vic);
> + if (err < 0)
> + goto rpm_put;
> +
> err = vic_boot(vic);
> - if (err < 0) {
> - pm_runtime_put(vic->dev);
> - return err;
> - }
> + if (err < 0)
> + goto rpm_put;
>
> context->channel = host1x_channel_get(vic->channel);
> if (!context->channel) {
> - pm_runtime_put(vic->dev);
> - return -ENOMEM;
> + err = -ENOMEM;
> + goto rpm_put;
> }
>
> return 0;
> +
> +rpm_put:
> + pm_runtime_put(vic->dev);
> + return err;
> }
>
> static void vic_close_channel(struct tegra_drm_context *context)
> @@ -372,10 +395,6 @@ static int vic_probe(struct platform_device *pdev)
> if (err < 0)
> return err;
>
> - err = falcon_read_firmware(&vic->falcon, vic->config->firmware);
> - if (err < 0)
> - goto exit_falcon;
> -
> platform_set_drvdata(pdev, vic);
>
> INIT_LIST_HEAD(&vic->client.base.list);
>
Looks good this time!
Reviewed-by: Dmitry Osipenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: ipu-v3: Variable "val" in function ipu_prg_get_pre() could be uninitialized
In function ipu_prg_get_pre(), local variable "val" could
be uninitialized if function regmap_read() returns -EINVAL.
However, this value is used in if statement. This is
potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/ipu-v3/ipu-prg.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 0013ca9f72c8..df12777d9be7 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -210,6 +210,7 @@ static int ipu_prg_get_pre(struct ipu_prg *prg, int
prg_chan)
if (!ret) {
u32 val, mux;
int shift;
+ int err;
prg->chan[prg_chan].used_pre = i;
@@ -221,7 +222,12 @@ static int ipu_prg_get_pre(struct ipu_prg *prg, int
prg_chan)
/* check other mux, must not point to same channel */
shift = (i == 1) ? 14 : 12;
- regmap_read(prg->iomuxc_gpr, IOMUXC_GPR5, &val);
+ err = regmap_read(prg->iomuxc_gpr, IOMUXC_GPR5, &val);
+ if (err < 0) {
+ dev_err(prg->dev, "read IOMUXC_GPRS failed\n");
+ return err;
+ }
+
if (((val >> shift) & 0x3) == mux) {
regmap_update_bits(prg->iomuxc_gpr, IOMUXC_GPR5,
0x3 << shift,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
Didn't knew about that line, sorry..
Sure you can include that.
I'm hoping patchwork won't thing it got tested twice by me..
Tested-by: Tristan Bastian
Gesendet: Montag, 28. Januar 2019 um 09:10 Uhr
Von: "Thierry Reding"
An: "Tristan Bastian"
Cc: "Wolfram Sang" , "Rob Herring" , "Lucas Stach" , "Andrzej Hajda" , "Vlado Plaga" , linux-...@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-te...@vger.kernel.org
Betreff: Re: [PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
On Mon, Jan 28, 2019 at 09:08:15AM +0100, Thierry Reding wrote:
> On Sat, Jan 26, 2019 at 01:37:34PM +0100, Tristan Bastian wrote:
> > Am 25.01.19 um 14:11 schrieb Thierry Reding:
> > > From: Thierry Reding
> > >
> > > If an I2C adapter doesn't match the provided device tree node, also try
> > > matching the parent's device tree node. This allows finding an adapter
> > > based on the device node of the parent device that was used to register
> > > it.
> > >
> > > This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
> > > eDP controller registers an I2C adapter that is used to read to EDID.
> > > After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
> > > suffix") this stopped working because the I2C adapter could no longer
> > > be found. The approach in this patch fixes the regression without
> > > introducing the issues that the above commit solved.
> > >
> > > Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware device node")
> > > Signed-off-by: Thierry Reding
> > > ---
> > > Changes in v2:
> > > - check for both device and parent device tree nodes for each device
> > > instead of looping through the list of devices twice
> > >
> > > drivers/i2c/i2c-core-of.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
> > > index 6cb7ad608bcd..0f01cdba9d2c 100644
> > > --- a/drivers/i2c/i2c-core-of.c
> > > +++ b/drivers/i2c/i2c-core-of.c
> > > @@ -121,6 +121,17 @@ static int of_dev_node_match(struct device *dev, void *data)
> > > return dev->of_node == data;
> > > }
> > > +static int of_dev_or_parent_node_match(struct device *dev, void *data)
> > > +{
> > > + if (dev->of_node == data)
> > > + return 1;
> > > +
> > > + if (dev->parent)
> > > + return dev->parent->of_node == data;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /* must call put_device() when done with returned i2c_client device */
> > > struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
> > > {
> > > @@ -145,7 +156,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
> > > struct device *dev;
> > > struct i2c_adapter *adapter;
> > > - dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match);
> > > + dev = bus_find_device(&i2c_bus_type, NULL, node,
> > > + of_dev_or_parent_node_match);
> > > if (!dev)
> > > return NULL;
> >
> > I've tested this and can confirm that this fixes the issue on the nyan-big
> > chromebook.
>
> Excellent, thanks for testing! Typically if you've tested a patch and
> verified that it fixes the problem that you were seeing, it's good to
> send this on a line by itself along with your reply:
>
> Tested-by: Tristan Bastian
Oh my... that was stupid. I think patchwork might now pick this up...
This also made me realize that I should've credited both Tristan and
Vlado as reporters in the commit message. I'll resend this.
Tristan, is it okay if I include your Tested-by: tag in the v2?
Thierry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: gsc: Variable "gscblk_cfg" in function gsc_set_gscblk_fimd_wb() could be uninitialized
In function gsc_set_gscblk_fimd_wb(), local variable "gscblk_cfg"
could be uninitialized of function regmap_read returns -EINVAL.
However, this value will be write to the register after "or"
operation. This is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b17ac1..b1d0f974fe80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -441,11 +441,16 @@ static int gsc_sw_reset(struct gsc_context *ctx)
static void gsc_set_gscblk_fimd_wb(struct gsc_context *ctx, bool enable)
{
unsigned int gscblk_cfg;
+ int ret;
if (!ctx->sysreg)
return;
- regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, &gscblk_cfg);
+ ret = regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, &gscblk_cfg);
+ if (ret) {
+ DRM_ERROR("gsc: Fail to read system register\n");
+ return;
+ }
if (enable)
gscblk_cfg |= GSC_BLK_DISP1WB_DEST(ctx->id) |
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
On poniedziałek, 28 stycznia 2019 14:47:41 CET Andrzej Hajda wrote:
> Hi Paweł,
>
> Nice work.
>
> I agree with most Sam's comments (maybe expect DRM_DEV_* logging - I am
> not sure if we need concurrent logging facility).
>
> I'd like to add few more comments:
>
>
>
> On 25.01.2019 17:46, Paweł Chmiel wrote:
> > This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
> > spi. It's based on already removed, non dt s6e63m0 driver and
> > panel-samsung-ld9040. There is possibility to choose one from 3
> > different gamma tables.
> > It can be found for example in some of Samsung Aries based phones.
> >
> > Signed-off-by: Paweł Chmiel
> > ---
> > drivers/gpu/drm/panel/Kconfig | 7 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 712 ++
> > 3 files changed, 720 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 3f3537719beb..4a4b64f74e70 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -82,6 +82,13 @@ config DRM_PANEL_SAMSUNG_LD9040
> > depends on OF && SPI
> > select VIDEOMODE_HELPERS
> >
> > +config DRM_PANEL_SAMSUNG_S6E63M0
> > + tristate "Samsung S6E63M0 RGB/SPI panel"
> > + depends on OF
> > + depends on SPI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + select VIDEOMODE_HELPERS
> > +
> > config DRM_PANEL_LG_LG4573
> > tristate "LG4573 RGB/SPI panel"
> > depends on OF && SPI
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 4396658a7996..3e5d53fdee47 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> > panel-raspberrypi-touchscreen
> > obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
> > obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> > obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
> > +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
> > obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> > obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> > obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> > b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> > new file mode 100644
> > index ..cb5c090621ad
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> > @@ -0,0 +1,712 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * S6E63M0 AMOLED LCD drm_panel driver.
> > + *
> > + * Copyright (C) 2019 Paweł Chmiel
> > + * Derived from drivers/gpu/drm/panel-samsung-ld9040.c
> > + *
> > + * Andrzej Hajda
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
>
>
> You do not need license 'body' if SPDX is in use.
>
>
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +/* Manufacturer Command Set */
> > +#define MCS_STAND_BY_OFF0x11
>
> MIPI_DCS_EXIT_SLEEP_MODE
>
> > +#define MCS_DISPLAY_ON 0x29
> MIPI_DCS_SET_DISPLAY_ON
> > +#define MCS_ELVSS_ON0xb1
> > +#define MCS_ACL_CTRL0xc0
> > +#define MCS_DISPLAY_CONDITION 0xf2
> > +#define MCS_ETC_CONDITION 0xf6
> > +#define MCS_PANEL_CONDITION 0xF8
> > +#define MCS_GAMMA_CTRL 0xfa
> > +
> > +#define MAX_GAMMA_LEVEL 11
>
>
> GAMMA_LEVEL_COUNT or NUM_GAMMA_LEVELS ?
Ok, NUM_GAMMA_LEVELS looks better.
>
>
> > +#define GAMMA_TABLE_COUNT 23
> > +
> > +#define MAX_BRIGHTNESS (MAX_GAMMA_LEVEL - 1)
> > +#define GAMMA_MODE_22 0
> > +#define GAMMA_MODE_19 1
> > +#define GAMMA_MODE_17 2
> > +
> > +/* array of gamma tables for gamma value 2.2 */
> > +static u8 const s6e63m0_gamma_22[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
> > + { MCS_GAMMA_CTRL, 0x00,
> > + 0x18, 0x08, 0x24, 0x78, 0xEC, 0x3D, 0xC8,
> > + 0xC2, 0xB6, 0xC4, 0xC7, 0xB6, 0xD5, 0xD7,
> > + 0xCC, 0x00, 0x39, 0x00, 0x36, 0x00, 0x51 },
> > + { MCS_GAMMA_CTRL, 0x00,
> > + 0x18, 0x08, 0x24, 0x73, 0x4A, 0x3D, 0xC0,
> > + 0xC2, 0xB1, 0xBB, 0xBE, 0xAC, 0xCE, 0xCF,
> > + 0xC5, 0x00, 0x5D, 0x00, 0x5E, 0x00, 0x82 },
> > + { MCS_GAMMA_CTRL, 0x00,
> > + 0x18, 0x08, 0x24, 0x70, 0x51, 0x3E, 0xBF,
> > + 0xC1, 0xAF, 0xB9, 0xBC, 0xAB, 0xCC, 0xCC,
> > + 0xC2, 0x00, 0x65, 0x00, 0x67, 0x00, 0x8D },
> > + { MCS_GAMMA_CTRL, 0x00,
> > + 0x18, 0x0
Re: [PATCH] dma-buf: Enhance dma-fence tracing
On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote: > Rather than every backend and GPU driver reinventing the same wheel for > user level debugging of HW execution, the common dma-fence framework > should include the tracing infrastructure required for most client API > level flow visualisation. > > With these common dma-fence level tracepoints, the userspace tools can > establish a detailed view of the client <-> HW flow across different > kernels. There is a strong ask to have this available, so that the > userspace developer can effectively assess if they're doing a good job > about feeding the beast of a GPU hardware. ... I've got a first pass of this visualizing with gpuvis. Screenshots: ; with dma_event tracepoints patch https://imgur.com/a/MwvoAYY ; with old i915 tracepoints https://imgur.com/a/tG2iyHS Couple questions... With your new dma_event traceponts patch, we're still getting these tracepoints: i915_request_in i915_request_out intel_engine_notify And the in/out tracepoints line up with dma_fence_executes (same ctx:seqno and time): -0 [006] 150.376273: dma_fence_execute_start: context=31, seqno=35670, hwid=0 -0 [006] 150.413215: dma_fence_execute_end: context=31, seqno=35670, hwid=0 -0 [006] 150.376272: i915_request_in: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35670, prio=0, global=41230, port=1 -0 [006] 150.413217: i915_request_out: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35670, global=41230, completed?=1 However I'm also seeing several i915_request_in --> intel_engine_notify tracepoints that don't have dma_fence_execute_* tracepoints: RenderThread-1279 [001] 150.341336: dma_fence_init: driver=i915 timeline=ShooterGame[1226]/2 context=31 seqno=35669 RenderThread-1279 [001] 150.341352: dma_fence_emit: context=31, seqno=35669 -0 [006] 150.376271: i915_request_in: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35669, prio=0, global=41229, port=1 -0 [006] 150.411525: intel_engine_notify: dev=0, engine=0:0, seqno=41229, waiters=1 RenderThread-1279 [001] 150.419779: dma_fence_signaled: context=31, seqno=35669 RenderThread-1279 [001] 150.419838: dma_fence_destroy:context=31, seqno=35669 I assume something is going on at a lower level that we can't get the information for via dma_fence? Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
On Mon, Jan 28, 2019 at 09:08:15AM +0100, Thierry Reding wrote:
> On Sat, Jan 26, 2019 at 01:37:34PM +0100, Tristan Bastian wrote:
> > Am 25.01.19 um 14:11 schrieb Thierry Reding:
> > > From: Thierry Reding
> > >
> > > If an I2C adapter doesn't match the provided device tree node, also try
> > > matching the parent's device tree node. This allows finding an adapter
> > > based on the device node of the parent device that was used to register
> > > it.
> > >
> > > This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
> > > eDP controller registers an I2C adapter that is used to read to EDID.
> > > After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
> > > suffix") this stopped working because the I2C adapter could no longer
> > > be found. The approach in this patch fixes the regression without
> > > introducing the issues that the above commit solved.
> > >
> > > Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware
> > > device node")
> > > Signed-off-by: Thierry Reding
> > > ---
> > > Changes in v2:
> > > - check for both device and parent device tree nodes for each device
> > > instead of looping through the list of devices twice
> > >
> > > drivers/i2c/i2c-core-of.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
> > > index 6cb7ad608bcd..0f01cdba9d2c 100644
> > > --- a/drivers/i2c/i2c-core-of.c
> > > +++ b/drivers/i2c/i2c-core-of.c
> > > @@ -121,6 +121,17 @@ static int of_dev_node_match(struct device *dev,
> > > void *data)
> > > return dev->of_node == data;
> > > }
> > > +static int of_dev_or_parent_node_match(struct device *dev, void *data)
> > > +{
> > > + if (dev->of_node == data)
> > > + return 1;
> > > +
> > > + if (dev->parent)
> > > + return dev->parent->of_node == data;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /* must call put_device() when done with returned i2c_client device */
> > > struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
> > > {
> > > @@ -145,7 +156,8 @@ struct i2c_adapter
> > > *of_find_i2c_adapter_by_node(struct device_node *node)
> > > struct device *dev;
> > > struct i2c_adapter *adapter;
> > > - dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match);
> > > + dev = bus_find_device(&i2c_bus_type, NULL, node,
> > > + of_dev_or_parent_node_match);
> > > if (!dev)
> > > return NULL;
> >
> > I've tested this and can confirm that this fixes the issue on the nyan-big
> > chromebook.
>
> Excellent, thanks for testing! Typically if you've tested a patch and
> verified that it fixes the problem that you were seeing, it's good to
> send this on a line by itself along with your reply:
>
> Tested-by: Tristan Bastian
Resending because first mail contained html and was blocked by the mailing
lists..
Didn't knew about that line, sorry..
Sure you can include that.
I'm hoping patchwork won't thing it got tested twice by me..
Tested-by: Tristan Bastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: fbmem: fix memory access if logo is bigger than the screen
From: Manfred Schlaegl
There is no clipping on the x or y axis for logos larger that the framebuffer
size. Therefore: a logo bigger than screen size leads to invalid memory access:
[1.254664] Backtrace:
[1.254728] [] (cfb_imageblit) from []
(fb_show_logo+0x620/0x684)
[1.254763] r10:0003 r9:00027fd8 r8:c6a4 r7:c6a36e50 r6:
r5:c06b81e4
[1.254774] r4:c6a3e800
[1.254810] [] (fb_show_logo) from []
(fbcon_switch+0x3fc/0x46c)
[1.254842] r10:c6a3e824 r9:c6a3e800 r8: r7:c6a0c000 r6:c070b014
r5:c6a3e800
[1.254852] r4:c6808c00
[1.254889] [] (fbcon_switch) from []
(redraw_screen+0xf0/0x1e8)
[1.254918] r10: r9: r8: r7: r6:c070d5a0
r5:0080
[1.254928] r4:c6808c00
[1.254961] [] (redraw_screen) from []
(do_bind_con_driver+0x194/0x2e4)
[1.254991] r9: r8: r7:0014 r6:c070d5a0 r5:c070d5a0
r4:c070d5a0
So prevent displaying a logo bigger than screen size and avoid invalid
memory access.
Signed-off-by: Manfred Schlaegl
Signed-off-by: Martin Kepplinger
---
drivers/video/fbdev/core/fbmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index cb43a2258c51..4721491e6c8c 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -431,6 +431,9 @@ static void fb_do_show_logo(struct fb_info *info, struct
fb_image *image,
{
unsigned int x;
+ if (image->width > info->var.xres || image->height > info->var.yres)
+ return;
+
if (rotate == FB_ROTATE_UR) {
for (x = 0;
x < num && image->dx + image->width <= info->var.xres;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
On 23.01.2019 14:03, Kees Cook wrote: > This adds a new plugin "stackinit" that attempts to perform unconditional > initialization of all stack variables Hello Kees! Hello everyone! I was curious about the performance impact of the initialization of all stack variables. So I did a very brief test with this plugin on top of 4.20.5. hackbench on Intel Core i7-4770 showed ~0.7% slowdown. hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown. This test involves the kernel scheduler and allocator. I can't say whether they use stack aggressively. Maybe performance tests of other subsystems (e.g. network subsystem) can show different numbers. Did you try? I've heard a hypothesis that the initialization of all stack variables would pollute CPU caches, which is critical for some types of computations. Maybe some micro-benchmarks can disprove/confirm that? Thanks! Best regards, Alexander ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Add a warning to drm_dev_is_unplugged
Den 29.01.2019 09.56, skrev Daniel Vetter:
> It's probably not what you want, definitely not after Noralf's work to
> add drm_dev_enter/exit.
>
> Cc: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
> include/drm/drm_drv.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 9a688cf12881..ca46a45a9cce 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -740,6 +740,10 @@ void drm_dev_unplug(struct drm_device *dev);
> * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> * unplugged, these two functions guarantee that any store before calling
> * drm_dev_unplug() is visible to callers of this function after it completes
> + *
> + * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> + * recommended that drivers instead use the underlying drm_dev_enter() and
> + * drm_dev_exit() function pairs.
> */
> static inline bool drm_dev_is_unplugged(struct drm_device *dev)
> {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: libdrm README rename
On 2019-01-29 2:16 a.m., Dave Airlie wrote: > So libdrm README renamed to README.rst, however that means it no > longer gets included in the dist tarball. > > I think autotools considers README special, so we might need to fix it, Adding the new README file to EXTRA_DIST seems enough, see e.g. https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/commit/a9da219e13bd0cdec65554382b5cd15abc3e3778 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Add a warning to drm_dev_is_unplugged
On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>
>
> Den 29.01.2019 09.56, skrev Daniel Vetter:
> > It's probably not what you want, definitely not after Noralf's work to
> > add drm_dev_enter/exit.
> >
> > Cc: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
> > ---
>
> Reviewed-by: Noralf Trønnes
Thanks for your review, applied. btw I noticed that we also have plenty of
drm_dev_is_unplugged in the core, not sure what to do about those.
-Daniel
>
> > include/drm/drm_drv.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index 9a688cf12881..ca46a45a9cce 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -740,6 +740,10 @@ void drm_dev_unplug(struct drm_device *dev);
> > * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> > * unplugged, these two functions guarantee that any store before calling
> > * drm_dev_unplug() is visible to callers of this function after it
> > completes
> > + *
> > + * WARNING: This function fundamentally races against drm_dev_unplug(). It
> > is
> > + * recommended that drivers instead use the underlying drm_dev_enter() and
> > + * drm_dev_exit() function pairs.
> > */
> > static inline bool drm_dev_is_unplugged(struct drm_device *dev)
> > {
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: libdrm README rename
On Tue, Jan 29, 2019 at 10:26:57AM +0100, Michel Dänzer wrote: > On 2019-01-29 2:16 a.m., Dave Airlie wrote: > > So libdrm README renamed to README.rst, however that means it no > > longer gets included in the dist tarball. > > > > I think autotools considers README special, so we might need to fix it, > > Adding the new README file to EXTRA_DIST seems enough, see e.g. > https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/commit/a9da219e13bd0cdec65554382b5cd15abc3e3778 meson build && ninja dist also gets this right. Should we update the relase scripts to prefer meson over automake? I guess it's too early to outright drop automake support in libdrm :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT
On Fri, Jan 25, 2019 at 03:02:46PM +, Emil Velikov wrote: > On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote: > > > > It's 0. > > > I'd add a bit more information here. Feel free to reuse as much/little > of the following: > > Both macros evaluate to 0. At the same time flag is already set to > zero since the struct is kzalloc'd in framebuffer_alloc(). > As called by drm_fb_helper_alloc_fbi() in the DRM drivers. Added&merged, thanks for your review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/etnaviv: add infrastructure to query perf counter
Hello Christian Gmeiner,
The patch 9e2c2e273012: "drm/etnaviv: add infrastructure to query
perf counter" from Sep 24, 2017, leads to the following static
checker warning:
drivers/gpu/drm/etnaviv/etnaviv_drv.c:410 etnaviv_ioctl_pm_query_dom()
warn: 'args->pipe' is out of bounds '3' vs '2'
drivers/gpu/drm/etnaviv/etnaviv_drv.c
396 static int etnaviv_ioctl_pm_query_dom(struct drm_device *dev, void
*data,
397 struct drm_file *file)
398 {
399 struct etnaviv_drm_private *priv = dev->dev_private;
400 struct drm_etnaviv_pm_domain *args = data;
401 struct etnaviv_gpu *gpu;
402
403 if (args->pipe >= ETNA_MAX_PIPES)
^^
ETNA_MAX_PIPES is 4.
404 return -EINVAL;
405
406 gpu = priv->gpu[args->pipe];
407 if (!gpu)
408 return -ENXIO;
409
--> 410 return etnaviv_pm_query_dom(gpu, args);
411 }
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
389 static const struct etnaviv_pm_domain_meta doms_meta[] = {
390 {
391 .nr_domains = ARRAY_SIZE(doms_3d),
392 .domains = &doms_3d[0]
393 },
394 {
395 .nr_domains = ARRAY_SIZE(doms_2d),
396 .domains = &doms_2d[0]
397 },
398 {
399 .nr_domains = ARRAY_SIZE(doms_vg),
400 .domains = &doms_vg[0]
401 }
This array only has 3 elements.
402 };
403
404 int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
405 struct drm_etnaviv_pm_domain *domain)
406 {
407 const struct etnaviv_pm_domain_meta *meta =
&doms_meta[domain->pipe];
^^^
Out of bounds.
408 const struct etnaviv_pm_domain *dom;
409
410 if (domain->iter >= meta->nr_domains)
411 return -EINVAL;
412
413 dom = meta->domains + domain->iter;
414
415 domain->id = domain->iter;
416 domain->nr_signals = dom->nr_signals;
417 strncpy(domain->name, dom->name, sizeof(domain->name));
418
419 domain->iter++;
420 if (domain->iter == meta->nr_domains)
421 domain->iter = 0xff;
422
423 return 0;
424 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
Quoting Michael Sartain (2019-01-29 01:52:12) > On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote: > > Rather than every backend and GPU driver reinventing the same wheel for > > user level debugging of HW execution, the common dma-fence framework > > should include the tracing infrastructure required for most client API > > level flow visualisation. > > > > With these common dma-fence level tracepoints, the userspace tools can > > establish a detailed view of the client <-> HW flow across different > > kernels. There is a strong ask to have this available, so that the > > userspace developer can effectively assess if they're doing a good job > > about feeding the beast of a GPU hardware. > ... > > I've got a first pass of this visualizing with gpuvis. Screenshots: > > ; with dma_event tracepoints patch > https://imgur.com/a/MwvoAYY > > ; with old i915 tracepoints > https://imgur.com/a/tG2iyHS > > Couple questions... > > With your new dma_event traceponts patch, we're still getting these > tracepoints: > > i915_request_in > i915_request_out These are debugging not really tracepoints and should be covered by trace_printk already. Left in this patch as they are a slightly different argument to remove (as in they are not directly replaced by dma-fence tracing). > intel_engine_notify To be removed upstream very shortly. > And the in/out tracepoints line up with dma_fence_executes > (same ctx:seqno and time): > > -0 [006] 150.376273: dma_fence_execute_start: context=31, > seqno=35670, hwid=0 > -0 [006] 150.413215: dma_fence_execute_end: context=31, > seqno=35670, hwid=0 > > -0 [006] 150.376272: i915_request_in: dev=0, engine=0:0, > hw_id=4, ctx=31, seqno=35670, prio=0, global=41230, port=1 > -0 [006] 150.413217: i915_request_out: dev=0, engine=0:0, > hw_id=4, ctx=31, seqno=35670, global=41230, completed?=1 > > However I'm also seeing several i915_request_in --> intel_engine_notify > tracepoints that don't have dma_fence_execute_* tracepoints: Yes. I was trying to wean the API off expecting having an exact match and just be happy with context in/out events, not request level details. > RenderThread-1279 [001] 150.341336: dma_fence_init: driver=i915 > timeline=ShooterGame[1226]/2 context=31 seqno=35669 > RenderThread-1279 [001] 150.341352: dma_fence_emit: context=31, > seqno=35669 > -0 [006] 150.376271: i915_request_in: dev=0, > engine=0:0, hw_id=4, ctx=31, seqno=35669, prio=0, global=41229, port=1 > -0 [006] 150.411525: intel_engine_notify: dev=0, > engine=0:0, seqno=41229, waiters=1 > RenderThread-1279 [001] 150.419779: dma_fence_signaled: context=31, > seqno=35669 > RenderThread-1279 [001] 150.419838: dma_fence_destroy:context=31, > seqno=35669 > > I assume something is going on at a lower level that we can't get the > information for via dma_fence? Deliberate obfuscation. It more or less lets us know what client was running on the GPU at any one time, but you have to work back to identify exactly what fence by inspecting the signaling timeline. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Add a warning to drm_dev_is_unplugged
Den 29.01.2019 10.51, skrev Daniel Vetter:
> On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 29.01.2019 09.56, skrev Daniel Vetter:
>>> It's probably not what you want, definitely not after Noralf's work to
>>> add drm_dev_enter/exit.
>>>
>>> Cc: Noralf Trønnes
>>> Signed-off-by: Daniel Vetter
>>> ---
>>
>> Reviewed-by: Noralf Trønnes
>
> Thanks for your review, applied. btw I noticed that we also have plenty of
> drm_dev_is_unplugged in the core, not sure what to do about those.
I think they're fine. They're kind of a shortcut for some code paths,
but in order to be safe I believe that it's the driver that needs to
have the responsibility to protect its resources. This way we don't run
into any suprises, since DRM and it's codepaths are quite complex.
Noralf.
> -Daniel
>
>>
>>> include/drm/drm_drv.h | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>>> index 9a688cf12881..ca46a45a9cce 100644
>>> --- a/include/drm/drm_drv.h
>>> +++ b/include/drm/drm_drv.h
>>> @@ -740,6 +740,10 @@ void drm_dev_unplug(struct drm_device *dev);
>>> * Unplugging itself is singalled through drm_dev_unplug(). If a device is
>>> * unplugged, these two functions guarantee that any store before calling
>>> * drm_dev_unplug() is visible to callers of this function after it
>>> completes
>>> + *
>>> + * WARNING: This function fundamentally races against drm_dev_unplug(). It
>>> is
>>> + * recommended that drivers instead use the underlying drm_dev_enter() and
>>> + * drm_dev_exit() function pairs.
>>> */
>>> static inline bool drm_dev_is_unplugged(struct drm_device *dev)
>>> {
>>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: generic: Fix drm_fbdev_client_restore()
Den 28.01.2019 12.49, skrev Gerd Hoffmann:
> On Mon, Jan 28, 2019 at 11:25:28AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 28.01.2019 07.48, skrev Gerd Hoffmann:
Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
>>>
static int drm_fbdev_client_restore(struct drm_client_dev *client)
{
- struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
-
- drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+ drm_fb_helper_lastclose(client->dev);
return 0;
}
>>>
>>> Hmm, at least the drm_fb_helper_lastclose() version I'm looking at
>>> (branch drm-misc-next) just calls
>>> drm_fb_helper_restore_fbdev_mode_unlocked without any check ...
>>>
>>
>> drm_fb_helper_lastclose() uses drm_device->fb_helper which is NULL if
>> fbdev is not in use,
>
> Ah, ok. In contrast drm_fb_helper_from_client() never returns NULL.
> Missed that detail.
>
> Reviewed-by: Gerd Hoffmann
>
Applied, thanks for your review.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Add a warning to drm_dev_is_unplugged
Den 29.01.2019 11.20, skrev Noralf Trønnes:
>
>
> Den 29.01.2019 10.51, skrev Daniel Vetter:
>> On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 29.01.2019 09.56, skrev Daniel Vetter:
It's probably not what you want, definitely not after Noralf's work to
add drm_dev_enter/exit.
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
>>>
>>> Reviewed-by: Noralf Trønnes
>>
>> Thanks for your review, applied. btw I noticed that we also have plenty of
>> drm_dev_is_unplugged in the core, not sure what to do about those.
>
> I think they're fine. They're kind of a shortcut for some code paths,
> but in order to be safe I believe that it's the driver that needs to
> have the responsibility to protect its resources. This way we don't run
> into any suprises, since DRM and it's codepaths are quite complex.
>
To be a bit more precise, it also reports back to userspace for some
code paths that might not reach the driver that the device is gone.
> Noralf.
>
>> -Daniel
>>
>>>
include/drm/drm_drv.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 9a688cf12881..ca46a45a9cce 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -740,6 +740,10 @@ void drm_dev_unplug(struct drm_device *dev);
* Unplugging itself is singalled through drm_dev_unplug(). If a device is
* unplugged, these two functions guarantee that any store before calling
* drm_dev_unplug() is visible to callers of this function after it
completes
+ *
+ * WARNING: This function fundamentally races against drm_dev_unplug().
It is
+ * recommended that drivers instead use the underlying drm_dev_enter() and
+ * drm_dev_exit() function pairs.
*/
static inline bool drm_dev_is_unplugged(struct drm_device *dev)
{
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Switch DRIVER_ flags to an enum
And move the documenation we alreay have into kerneldoc, plus a bit of
polish while at it.
v2:
- Ditch FIXME from commit message, I've resolved that already before
sending out the first version.
- Put the legacy DRIVER_ flags at the end (Sam).
Cc: Sam Ravnborg
Reviewed-by: Emil Velikov
Reviewed-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst | 62
include/drm/drm_drv.h | 141
2 files changed, 124 insertions(+), 79 deletions(-)
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index 2caf21effd28..3ae23a5454ac 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -39,68 +39,6 @@ sections.
Driver Information
--
-Driver Features
-~~~
-
-Drivers inform the DRM core about their requirements and supported
-features by setting appropriate flags in the driver_features field.
-Since those flags influence the DRM core behaviour since registration
-time, most of them must be set to registering the :c:type:`struct
-drm_driver ` instance.
-
-u32 driver_features;
-
-DRIVER_USE_AGP
-Driver uses AGP interface, the DRM core will manage AGP resources.
-
-DRIVER_LEGACY
-Denote a legacy driver using shadow attach. Don't use.
-
-DRIVER_KMS_LEGACY_CONTEXT
-Used only by nouveau for backwards compatibility with existing userspace.
-Don't use.
-
-DRIVER_PCI_DMA
-Driver is capable of PCI DMA, mapping of PCI DMA buffers to
-userspace will be enabled. Deprecated.
-
-DRIVER_SG
-Driver can perform scatter/gather DMA, allocation and mapping of
-scatter/gather buffers will be enabled. Deprecated.
-
-DRIVER_HAVE_DMA
-Driver supports DMA, the userspace DMA API will be supported.
-Deprecated.
-
-DRIVER_HAVE_IRQ; DRIVER_IRQ_SHARED
-DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
-managed by the DRM Core. The core will support simple IRQ handler
-installation when the flag is set. The installation process is
-described in ?.
-
-DRIVER_IRQ_SHARED indicates whether the device & handler support
-shared IRQs (note that this is required of PCI drivers).
-
-DRIVER_GEM
-Driver use the GEM memory manager.
-
-DRIVER_MODESET
-Driver supports mode setting interfaces (KMS).
-
-DRIVER_PRIME
-Driver implements DRM PRIME buffer sharing.
-
-DRIVER_RENDER
-Driver supports dedicated render nodes.
-
-DRIVER_ATOMIC
-Driver supports atomic properties. In this case the driver must
-implement appropriate obj->atomic_get_property() vfuncs for any
-modeset objects with driver specific properties.
-
-DRIVER_SYNCOBJ
-Driver support drm sync objects.
-
Major, Minor and Patchlevel
~~~
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index e32c12877bc5..0760a1d7b6c2 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -41,21 +41,123 @@ struct drm_display_mode;
struct drm_mode_create_dumb;
struct drm_printer;
-/* driver capabilities and requirements mask */
-#define DRIVER_USE_AGP 0x1
-#define DRIVER_LEGACY 0x2
-#define DRIVER_PCI_DMA 0x8
-#define DRIVER_SG 0x10
-#define DRIVER_HAVE_DMA0x20
-#define DRIVER_HAVE_IRQ0x40
-#define DRIVER_IRQ_SHARED 0x80
-#define DRIVER_GEM 0x1000
-#define DRIVER_MODESET 0x2000
-#define DRIVER_PRIME 0x4000
-#define DRIVER_RENDER 0x8000
-#define DRIVER_ATOMIC 0x1
-#define DRIVER_KMS_LEGACY_CONTEXT 0x2
-#define DRIVER_SYNCOBJ 0x4
+/**
+ * enum drm_driver_feature - feature flags
+ *
+ * See &drm_driver.driver_features, drm_device.driver_features and
+ * drm_core_check_feature().
+ */
+enum drm_driver_feature {
+ /**
+* @DRIVER_GEM:
+*
+* Driver use the GEM memory manager. This should be set for all modern
+* drivers.
+*/
+ DRIVER_GEM = BIT(0),
+ /**
+* @DRIVER_MODESET:
+*
+* Driver supports mode setting interfaces (KMS).
+*/
+ DRIVER_MODESET = BIT(1),
+ /**
+* @DRIVER_PRIME:
+*
+* Driver implements DRM PRIME buffer sharing.
+*/
+ DRIVER_PRIME= BIT(2),
+ /**
+* @DRIVER_RENDER:
+*
+* Driver supports dedicated render nodes. See also the :ref:`section on
+* render nodes ` for details.
+*/
+ DRIVER_RENDER = BIT(3),
+ /**
+* @DRIVER_ATOMIC:
+*
+* Driver supports the full atomic modesetting userspace API. Drivers
+* which only use atomic internally, but do not the support the full
+* userspace API (e.g. not all properties c
[PATCH 3/3] drm/irq: Ditch DRIVER_IRQ_SHARED
This is only used by drm_irq_install(), which is an optional helper.
For legacy pci devices this is required (due to interrupt sharing without
msi/msi-x), and just making this the default exactly matches the behaviour
of all existing drivers using the drm_irq_install() helpers. In case that
ever becomes wrong drivers can roll their own irq handling, as many
drivers already do (for other reasons like needing a threaded interrupt
handler, or having an entire pile of different interrupt sources).
v2: Rebase
v3: Improve commit message (Emil)
Cc: Sam Ravnborg
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/gma500/psb_drv.c| 3 +--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/mga/mga_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/r128/r128_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 4 +---
drivers/gpu/drm/via/via_drv.c | 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/staging/vboxvideo/vbox_drv.c| 3 +--
include/drm/drm_drv.h | 22 ++
12 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 22502417c18c..a1bb3773087b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1189,7 +1189,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev,
unsigned int pipe,
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_ATOMIC |
- DRIVER_IRQ_SHARED | DRIVER_GEM |
+ DRIVER_GEM |
DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
.load = amdgpu_driver_load_kms,
.open = amdgpu_driver_open_kms,
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c5babb3e4752..9bd8908d5fd8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -120,8 +120,8 @@ int drm_irq_install(struct drm_device *dev, int irq)
if (dev->driver->irq_preinstall)
dev->driver->irq_preinstall(dev);
- /* Install handler */
- if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
+ /* PCI devices require shared interrupts. */
+ if (dev->pdev)
sh_flags = IRQF_SHARED;
ret = request_irq(irq, dev->driver->irq_handler,
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 7cf14aeb1c28..eefaf4daff2b 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -468,8 +468,7 @@ static const struct file_operations psb_gem_fops = {
};
static struct drm_driver driver = {
- .driver_features = DRIVER_IRQ_SHARED | \
- DRIVER_MODESET | DRIVER_GEM,
+ .driver_features = DRIVER_MODESET | DRIVER_GEM,
.load = psb_driver_load,
.unload = psb_driver_unload,
.lastclose = drm_fb_helper_lastclose,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 550cfb945942..a7aaa1ac4c99 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3010,7 +3010,7 @@ static struct drm_driver driver = {
* deal with them for Intel hardware.
*/
.driver_features =
- DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
+ DRIVER_GEM | DRIVER_PRIME |
DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
.release = i915_driver_release,
.open = i915_driver_open,
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
index 1aad27813c23..6e1d1054ad06 100644
--- a/drivers/gpu/drm/mga/mga_drv.c
+++ b/drivers/gpu/drm/mga/mga_drv.c
@@ -57,7 +57,7 @@ static const struct file_operations mga_driver_fops = {
static struct drm_driver driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_LEGACY |
- DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
+ DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ,
.dev_priv_size = sizeof(drm_mga_buf_priv_t),
.load = mga_driver_load,
.unload = mga_driver_unload,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1669d4b79253..bb81e310eb6d 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -245,7 +245,6 @@ static struct pci_driver qxl_pci_driver = {
static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_IRQ_SHARED |
DRIVER_ATOMIC,
.dumb_create = qxl_mode_dumb_create,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 0d2b7e42b3a7..4b1a505ab353 100644
--- a/drive
[PATCH 1/3] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers,
which control IRQ enabling/disabling through the DRM_IOCTL_CONTROL
legacy IOCTL.
Also remove all the flag usage from non-legacy drivers.
v2: Review from Emil:
- improve commit message
- I forgot hibmc, fix that
Cc: linux-arm-ker...@lists.infradead.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Emil Velikov
Reviewed-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 2 +-
drivers/gpu/drm/drm_irq.c | 6 --
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.c| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/meson/meson_drv.c | 2 +-
drivers/gpu/drm/msm/msm_drv.c | 3 +--
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c| 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/staging/vboxvideo/vbox_drv.c| 2 +-
18 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0c22bae0c736..22502417c18c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1189,7 +1189,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev,
unsigned int pipe,
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_ATOMIC |
- DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
+ DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
.load = amdgpu_driver_load_kms,
.open = amdgpu_driver_open_kms,
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e68935b80917..8fc0b884c428 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -229,7 +229,7 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver hdlcd_driver = {
- .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
+ .driver_features = DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
.irq_handler = hdlcd_irq,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 034a91112098..0be13eceedba 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -720,7 +720,7 @@ static void atmel_hlcdc_dc_irq_uninstall(struct drm_device
*dev)
DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver atmel_hlcdc_dc_driver = {
- .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
+ .driver_features = DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
.irq_handler = atmel_hlcdc_dc_irq_handler,
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 45a07652fa00..c5babb3e4752 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -103,9 +103,6 @@ int drm_irq_install(struct drm_device *dev, int irq)
int ret;
unsigned long sh_flags = 0;
- if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
- return -EOPNOTSUPP;
-
if (irq == 0)
return -EINVAL;
@@ -174,9 +171,6 @@ int drm_irq_uninstall(struct drm_device *dev)
bool irq_enabled;
int i;
- if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
- return -EOPNOTSUPP;
-
irq_enabled = dev->irq_enabled;
dev->irq_enabled = false;
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 54ace3436605..dfc73aade325 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -137,7 +137,7 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
DEFINE_DRM_GEM_CMA_FOPS(fsl_dcu_drm_fops);
static struct drm_driver fsl_dcu_drm_driver = {
- .driver_features= DRIVER_HAVE_IRQ | DRIVER_
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Block fbdev HPD processing during suspend
Quoting Lyude Paul (2019-01-28 20:56:01)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> However, sending a hotplug event involves calling
> drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
> connector reprobe in the caller's thread - something we can't do at the
> point in which i915 calls drm_dp_mst_topology_mgr_resume() since
> hotplugging hasn't been fully initialized yet.
>
> This currently causes some rather subtle but fatal issues. For example,
> on my T480s the laptop dock connected to it usually disappears during a
> suspend cycle, and comes back up a short while after the system has been
> resumed. This guarantees pretty much every suspend and resume cycle,
> drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
> a connector hotplug will occur. Now it's Rute Goldberg time: when the
> connector hotplug occurs, i915 reprobes /all/ of the connectors,
> including eDP. However, eDP probing requires that we power on the panel
> VDD which in turn, grabs a wakeref to the appropriate power domain on
> the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
> things start breaking, since this all happens before
> intel_power_domains_enable() is called we end up leaking the wakeref
> that was acquired and never releasing it later. Come next suspend/resume
> cycle, this causes us to fail to shut down the GPU properly, which
> causes it not to resume properly and die a horrible complicated death.
>
> (as a note: this only happens when there's both an eDP panel and MST
> topology connected which is removed mid-suspend. One or the other seems
> to always be OK).
>
> We could try to fix the VDD wakeref leak, but this doesn't seem like
> it's worth it at all since we aren't able to handle hotplug detection
> while resuming anyway. So, let's go with a more robust solution inspired
> by nouveau: block fbdev from handling hotplug events until we resume
> fbdev. This allows us to still send sysfs hotplug events to be handled
> later by user space while we're resuming, while also preventing us from
> actually processing any hotplug events we receive until it's safe.
>
> This fixes the wakeref leak observed on the T480s and as such, also
> fixes suspend/resume with MST topologies connected on this machine.
>
> Signed-off-by: Lyude Paul
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: Todd Previte
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Imre Deak
> Cc: intel-...@lists.freedesktop.org
> Cc: # v3.17+
> ---
> drivers/gpu/drm/i915/intel_drv.h | 10 ++
> drivers/gpu/drm/i915/intel_fbdev.c | 30 +-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 85b913ea6e80..c8549588b2ce 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -213,6 +213,16 @@ struct intel_fbdev {
> unsigned long vma_flags;
> async_cookie_t cookie;
> int preferred_bpp;
> +
> + /* Whether or not fbdev hpd processing is temporarily suspended */
> + bool hpd_suspended : 1;
> + /* Set when a hotplug was received while HPD processing was
> +* suspended
> +*/
> + bool hpd_waiting : 1;
> +
> + /* Protects hpd_suspended */
> + struct mutex hpd_lock;
> };
>
> struct intel_encoder {
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 8cf3efe88f02..3a6c0bebaaf9 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -681,6 +681,7 @@ int intel_fbdev_init(struct drm_device *dev)
> if (ifbdev == NULL)
> return -ENOMEM;
>
> + mutex_init(&ifbdev->hpd_lock);
> drm_fb_helper_prepare(dev, &ifbdev->helper, &intel_fb_helper_funcs);
>
> if (!intel_fbdev_init_bios(dev, ifbdev))
> @@ -754,6 +755,23 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
> intel_fbdev_destroy(ifbdev);
> }
>
> +/* Suspends/resumes fbdev processing of incoming HPD events. When resuming
> HPD
> + * processing, fbdev will perform a full connector reprobe if a hotplug event
> + * was received while HPD was suspended.
> + */
> +static void intel_fbdev_hpd_set_suspend(struct intel_fbdev *ifbdev, int
> state)
> +{
> + mutex_lock(&ifbdev->hpd_lock);
> + ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
> + if (ifbdev->hpd_waiting) {
> + ifbdev->hpd_waiting = false;
> +
> + DRM_DEBUG_KMS("Handling delayed fbcon HPD event\n");
> + drm_fb_helper_hotplug_event(&ifbdev->helper);
Even when set_suspend(true)
[Bug 109493] [CI][DRMTIP] igt@gem_cpu_reloc@forked - fail - igt_skip: Assertion `!test_child' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109493 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Component|DRM/Intel |IGT --- Comment #2 from Chris Wilson --- igt mishandling a igt_skip from inside an igt_fork; usually procedure is to move the skip check before the fork. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> Create a new connector property to program colorspace to sink devices.
> Modern sink devices support more than 1 type of colorspace like 601,
> 709, BT2020 etc. This helps to switch based on content type which is
> to be displayed. The decision lies with compositors as to in which
> scenarios, a particular colorspace will be picked.
>
> This will be helpful mostly to switch to higher gamut colorspaces
> like BT2020 when the media content is encoded as BT2020. Thereby
> giving a good visual experience to users.
>
> The expectation from userspace is that it should parse the EDID
> and get supported colorspaces. Use this property and switch to the
> one supported. Driver will expose the platform supported colorspaces,
> however sink supported colorspaces should be retrieved by userspace
> from EDID.
>
> Basically the expectation from userspace is:
> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>colorspace
> - Set this new property to let the sink know what it
>converted the CRTC output to.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
>
> v3: Removed Adobe references from enum definitions as per
> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> Default to an unset state where driver will assign the colorspace
> is not chosen by user, suggested by Ville and Maarten. Addressed
> other misc review comments from Maarten. Split the changes to
> have separate colorspace property for DP and HDMI.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
>
> v5: Made the property creation helper accept enum list based on
> platform capabilties as suggested by Shashank. Consolidated HDMI
> and DP property creation in the common helper.
>
> v6: Addressed Shashank's review comments.
>
> v7: Added defines instead of enum in uapi as per Brian Starkey's
> suggestion in order to go with string matching at userspace. Updated
> the commit message to add more details as well kernel docs.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 95
> +++
> include/drm/drm_connector.h | 17 +++
> include/uapi/drm/drm_mode.h | 32 +
> 4 files changed, 148 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41a..9b5d44f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == connector->colorspace_property) {
> + state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> *val = state->picture_aspect_ratio;
> } else if (property == config->content_type_property) {
> *val = state->content_type;
> + } else if (property == connector->colorspace_property) {
> + *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8475396..eafa643 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> };
> DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
>
> +/* List of HDMI Colorspaces supported */
> +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { COLORIMETRY_ITU_601, "ITU_601" },
> + { COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { COLORIMETRY_S_YCC_601, "S_YCC_601
Re: [Intel-gfx] [v7 2/2] drm/i915: Attach colorspace property and enable modeset
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace. This can be used to send an
> infoframe packet with proper colorspace value set which
> will help to enable wider color gamut like BT2020 on sink.
>
> This patch attaches and enables HDMI colorspace, DP will be
> taken care separately.
>
> v2: Merged the changes of creating infoframe as well to this
> patch as per Maarten's suggestion.
>
> v3: Addressed review comments from Shashank. Separated HDMI
> and DP colorspaces as suggested by Ville and Maarten.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard. Handle the default case properly.
>
> v5: Added Platform specific colorspace enums and called the
> property creation helper using the same.
>
> v6: Addressed Shashank's review comments.
>
> v7: Rebase
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> drivers/gpu/drm/i915/intel_connector.c | 63
> ++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 19 ++
> 4 files changed, 84 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 16263ad..76b7114 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
>*/
> if (new_conn_state->force_audio != old_conn_state->force_audio ||
> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
> + new_state->colorspace != old_state->colorspace ||
> new_conn_state->base.picture_aspect_ratio !=
> old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type !=
> old_conn_state->base.content_type ||
> new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode)
> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758..114fcf2 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -30,6 +30,48 @@
> #include "intel_drv.h"
> #include "i915_drv.h"
>
> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { COLORIMETRY_ITU_601, "ITU_601" },
> + { COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { COLORIMETRY_S_YCC_601, "S_YCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { COLORIMETRY_OPRGB, "opRGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> +};
> +
> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { COLORIMETRY_ITU_601, "ITU_601" },
> + { COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { COLORIMETRY_S_YCC_601, "S_YCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { COLORIMETRY_OPRGB, "opRGB" },
> +};
> +
> int intel_connector_init(struct intel_connector *connector)
> {
> struct intel_digital_connector_state *conn_state;
> @@ -265,3 +307,24 @@ int intel_ddc_get_modes(struct drm_connector *connector,
> connector->dev->mode_config.aspect_ratio_property,
> DRM_MODE_PICTURE_A
[PATCH 1/2] drm/vmwgfx: Fix an uninitialized fence handle value
if vmw_execbuf_fence_commands() fails, The handle value will be
uninitialized and a bogus fence handle might be copied to user-space.
Cc:
Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for the
modesetting code v2")
Reported-by: Dan Carpenter
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b351fb5214d3..3330bc89f1b9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2554,7 +2554,7 @@ void vmw_kms_helper_validation_finish(struct vmw_private
*dev_priv,
user_fence_rep)
{
struct vmw_fence_obj *fence = NULL;
- uint32_t handle;
+ uint32_t handle = 0;
int ret;
if (file_priv || user_fence_rep || vmw_validation_has_bos(ctx) ||
@@ -2562,7 +2562,7 @@ void vmw_kms_helper_validation_finish(struct vmw_private
*dev_priv,
ret = vmw_execbuf_fence_commands(file_priv, dev_priv, &fence,
file_priv ? &handle : NULL);
vmw_validation_done(ctx, fence);
- if (file_priv)
+ if (file_priv && !ret)
vmw_execbuf_copy_fence_user(dev_priv, vmw_fpriv(file_priv),
ret, user_fence_rep, fence,
handle, -1, NULL);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Also check for crtc status while checking for DU active
From: Deepak Rawat
During modeset check it is possible to have all crtc_state's in atomic
state. Check for crtc enable status while checking for display unit
active status. Only error if enabling a crtc while display unit is not
active.
Cc:
Fixes: 9da6e26c0aae: ("drm/vmwgfx: Fix a layout race condition")
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3330bc89f1b9..9c8cdae5a4fa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1646,7 +1646,7 @@ static int vmw_kms_check_topology(struct drm_device *dev,
struct drm_connector_state *conn_state;
struct vmw_connector_state *vmw_conn_state;
- if (!du->pref_active) {
+ if (!du->pref_active && new_crtc_state->enable) {
ret = -EINVAL;
goto clean;
}
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/doc: Task to rename CMA helpers
I'm kinda fed up explaining why the have a confusing name :-) Cc: Noralf Trønnes Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede1221..17f1cde6adab 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,16 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Rename CMA helpers to DMA helpers +- + +CMA (standing for contiguous memory allocator) is really a bit an accident of +what these were used for first, a much better name would be DMA helpers. In the +text these should even be called coherent DMA memory helpers (so maybd CDM, but +no one knows what that means) since underneath they just use dma_alloc_coherent. + +Contact: Laurent Pinchart, Daniel Vetter + Core refactorings = -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:54 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>
>Op 28-01-2019 om 09:44 schreef Uma Shankar:
>> Create a new connector property to program colorspace to sink devices.
>> Modern sink devices support more than 1 type of colorspace like 601,
>> 709, BT2020 etc. This helps to switch based on content type which is
>> to be displayed. The decision lies with compositors as to in which
>> scenarios, a particular colorspace will be picked.
>>
>> This will be helpful mostly to switch to higher gamut colorspaces like
>> BT2020 when the media content is encoded as BT2020. Thereby giving a
>> good visual experience to users.
>>
>> The expectation from userspace is that it should parse the EDID and
>> get supported colorspaces. Use this property and switch to the one
>> supported. Driver will expose the platform supported colorspaces,
>> however sink supported colorspaces should be retrieved by userspace
>> from EDID.
>>
>> Basically the expectation from userspace is:
>> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>>colorspace
>> - Set this new property to let the sink know what it
>>converted the CRTC output to.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> Also, added a default option for colorspace.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
>> state where driver will assign the colorspace is not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Made the property creation helper accept enum list based on
>> platform capabilties as suggested by Shashank. Consolidated HDMI and
>> DP property creation in the common helper.
>>
>> v6: Addressed Shashank's review comments.
>>
>> v7: Added defines instead of enum in uapi as per Brian Starkey's
>> suggestion in order to go with string matching at userspace. Updated
>> the commit message to add more details as well kernel docs.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> drivers/gpu/drm/drm_connector.c | 95
>+++
>> include/drm/drm_connector.h | 17 +++
>> include/uapi/drm/drm_mode.h | 32 +
>> 4 files changed, 148 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 9a1f41a..9b5d44f 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> return -EINVAL;
>> }
>> state->content_protection = val;
>> +} else if (property == connector->colorspace_property) {
>> +state->colorspace = val;
>> } else if (property == config->writeback_fb_id_property) {
>> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb); @@
>> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->picture_aspect_ratio;
>> } else if (property == config->content_type_property) {
>> *val = state->content_type;
>> +} else if (property == connector->colorspace_property) {
>> +*val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> } else if (property == connector->content_protection_property) {
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 8475396..eafa643 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
>> drm_display_info *info, };
>> DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
>>
>> +/* List of HDMI Colorspaces supported */ static const struct
>> +drm_prop_enum_list hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_I
[PATCH 1/2] drm/vmwgfx: Fix setting of dma masks
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 3e2bcff34032..ae9df4432bfc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -600,13 +600,16 @@ static int vmw_dma_select_mode(struct vmw_private
*dev_priv)
static int vmw_dma_masks(struct vmw_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
+ int ret = 0;
- if (intel_iommu_enabled &&
+ ret = dma_set_mask_and_coherent(dev->dev, DMA_BIT_MASK(64));
+ if (dev_priv->map_mode != vmw_dma_phys &&
(sizeof(unsigned long) == 4 || vmw_restrict_dma_mask)) {
DRM_INFO("Restricting DMA addresses to 44 bits.\n");
- return dma_set_mask(dev->dev, DMA_BIT_MASK(44));
+ return dma_set_mask_and_coherent(dev->dev, DMA_BIT_MASK(44));
}
- return 0;
+
+ return ret;
}
static int vmw_driver_load(struct drm_device *dev, unsigned long chipset)
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/vmwgfx: Improve on IOMMU detection
instead of relying on intel_iommu_enabled, use the fact that the
dma_map_ops::map_page != dma_direct_map_page.
Signed-off-by: Thomas Hellstrom
---
v2: Merge fixes and typo fix in commit message. Also check for ops being
non-NULL before dereferencing it.
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index ae9df4432bfc..7ef5dcb06104 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -26,6 +26,7 @@
**/
#include
#include
+#include
#include
#include "vmwgfx_drv.h"
@@ -34,7 +35,6 @@
#include
#include
#include
-#include
#define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
#define VMWGFX_CHIP_SVGAII 0
@@ -545,6 +545,21 @@ static void vmw_get_initial_size(struct vmw_private
*dev_priv)
dev_priv->initial_height = height;
}
+/**
+ * vmw_assume_iommu - Figure out whether coherent dma-remapping might be
+ * taking place.
+ * @dev: Pointer to the struct drm_device.
+ *
+ * Return: true if iommu present, false otherwise.
+ */
+static bool vmw_assume_iommu(struct drm_device *dev)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev->dev);
+
+ return !dma_is_direct(ops) && ops &&
+ ops->map_page != dma_direct_map_page;
+}
+
/**
* vmw_dma_select_mode - Determine how DMA mappings should be set up for this
* system.
@@ -568,7 +583,7 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv)
if (vmw_force_coherent)
dev_priv->map_mode = vmw_dma_alloc_coherent;
- else if (intel_iommu_enabled)
+ else if (vmw_assume_iommu(dev_priv->dev))
dev_priv->map_mode = vmw_dma_map_populate;
else if (!vmw_force_iommu)
dev_priv->map_mode = vmw_dma_phys;
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: add binding for Innolux ee101ia-01d panel
Hi Thierry, Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner: > From: Heiko Stuebner > > This is a panel handled through the generic lvds-panel binding, > so only needs its additional compatible specified. > > Signed-off-by: Heiko Stuebner just pulling this pending patch out of the woodworks again too :-) Thanks in advance for considering it. Heiko > --- > .../bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > new file mode 100644 > index ..e5ca4ccd55ed > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > @@ -0,0 +1,7 @@ > +Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel > + > +Required properties: > +- compatible: should be "innolux,ee101ia-01d" > + > +This binding is compatible with the lvds-panel binding, which is specified > +in panel-lvds.txt in this directory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #6 from Chris --- Still having the same bug in kernel 5.0-rc4 and my raven_dmcu.bin also matches to the previously attached bin file(sha256 a45972418d1c078afbd7884ffd58784954220759bc0d5464ce60165ffe1775bd). However, in one of my tests I got it to work! So the time it worked I got lucky I somehow misplaced raven_dmcu.bin so when I rebooted the kernel 5.0rc4 and checked /lib/firmware/amdgpu/raven_dmcu.bin it wasn't there. As soon as I put raven_dmcu.bin back in the folder /lib/firmware/amdgpu/ I got this bug again. So the workaround is to delete raven_dmcu.bin from /lib/firmware/amdgpu for now until they fix it. Laptop seems to work just fine. I don't know what that firmware is for but it doesn't look like it's a required file for my HP x360 AMD Ryzen 2500U laptop -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/2] Do not output logo on quiet boots
On text-based systems the 'quiet' boot option will show printk levels higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo during boot can cause some consoles to lose display data and as a result confuse the end user. Do not display the Tux logo on systems that are in 'quiet' boot. v2: It helps to commit all my changes before sending them. Remove extra bracket. v3: buildbot error fix: fbcon can be built as part of a module so export console_printk v4: move console_printk change to separate patch, and drop logo cleanup v5: Only set FBCON_LOGO_DONTSHOW for console loglevel Signed-off-by: Prarit Bhargava Cc: Hans de Goede Cc: Marko Myllynen Cc: Steven Rostedt (VMware) Cc: Bartlomiej Zolnierkiewicz Cc: Kees Cook Cc: Daniel Vetter Cc: Thierry Reding Cc: Yisheng Xie Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: dri-devel@lists.freedesktop.org Prarit Bhargava (2): printk: Export console_printk fbcon: Silence fbcon logo on 'quiet' boots drivers/video/fbdev/core/fbcon.c | 8 +++- kernel/printk/printk.c | 1 + 2 files changed, 8 insertions(+), 1 deletion(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] fbcon: Silence fbcon logo on 'quiet' boots
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
v2: It helps to commit all my changes before sending them. Remove extra
bracket.
v3: buildbot error fix: fbcon can be built as part of a module so export
console_printk
v4: move console_printk change to separate patch, and drop logo cleanup
v5: Only set FBCON_LOGO_DONTSHOW for console loglevel
Signed-off-by: Prarit Bhargava
Cc: Hans de Goede
Cc: Marko Myllynen
Cc: Steven Rostedt (VMware)
Cc: Bartlomiej Zolnierkiewicz
Cc: Kees Cook
Cc: Daniel Vetter
Cc: Thierry Reding
Cc: Yisheng Xie
Cc: dri-devel@lists.freedesktop.org
---
drivers/video/fbdev/core/fbcon.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bfa1360ec750..59b626356983 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -656,11 +656,14 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
fb_info *info,
kfree(save);
}
+ if (logo_shown == FBCON_LOGO_DONTSHOW)
+ return;
+
if (logo_lines > vc->vc_bottom) {
logo_shown = FBCON_LOGO_CANSHOW;
printk(KERN_INFO
"fbcon_init: disable boot-logo (boot-logo bigger than
screen).\n");
- } else if (logo_shown != FBCON_LOGO_DONTSHOW) {
+ } else {
logo_shown = FBCON_LOGO_DRAW;
vc->vc_top = logo_lines;
}
@@ -1066,6 +1069,9 @@ static void fbcon_init(struct vc_data *vc, int init)
cap = info->flags;
+ if (console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW ||
(info->fix.type == FB_TYPE_TEXT))
logo = 0;
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm: drop drm_bus from todo
Hi Daniel. > > Sam, want drm-misc commit rights to start merging your own stuff? Assuming > you plan to stick around ofc ... I'll also ask the drm-misc maintainers > whether that's ok. The plan is to re-submit the Atmel LCDC DRM driver when I find enough time to finish it. All coding is done and it builds, I 'only' need to make it work. When I submit the driver the plan is to share the maintainer role for both Atmel based DRM drivers (hlcdc + lcdc). So it would make sense to gain drm-misc commit rights at least then. Last time I looked at it I was stucked in the keys required and the tools I needed to learn. This was not really where I had energy to spend the effort. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only
Quoting Jerome Glisse (2019-01-24 17:30:32)
> On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote:
> > Hi Jerome,
> >
> > This patch seems to have plenty of Cc:s, but none of the right ones :)
>
> So sorry, i am bad with git commands.
>
> > For further iterations, I guess you could use git option --cc to make
> > sure everyone gets the whole series, and still keep the Cc:s in the
> > patches themselves relevant to subsystems.
>
> Will do.
>
> > This doesn't seem to be on top of drm-tip, but on top of your previous
> > patches(?) that I had some comments about. Could you take a moment to
> > first address the couple of question I had, before proceeding to discuss
> > what is built on top of that base.
>
> It is on top of Linus tree so roughly ~ rc3 it does not depend on any
> of the previous patch i posted.
You actually managed to race a point in time just when Chris rewrote much
of the userptr code in drm-tip, which I didn't remember of. My bad.
Still interested to hearing replies to my questions in the previous
thread, if the series is still relevant. Trying to get my head around
how the different aspects of HMM pan out for devices without fault handling.
> I still intended to propose to remove
> GUP from i915 once i get around to implement the equivalent of GUP_fast
> for HMM and other bonus cookies with it.
>
> The plan is once i have all mm bits properly upstream then i can propose
> patches to individual driver against the proper driver tree ie following
> rules of each individual device driver sub-system and Cc only people
> there to avoid spamming the mm folks :)
Makes sense, as we're having tons of changes in this field in i915, the
churn to rebase on top of them will be substantial.
Regards, Joonas
PS. Are you by any chance attending FOSDEM? Would be nice to chat about
this.
>
>
> >
> > My reply's Message-ID is:
> > 154289518994.19402.3481838548028068...@jlahtine-desk.ger.corp.intel.com
> >
> > Regards, Joonas
> >
> > PS. Please keep me Cc:d in the following patches, I'm keen on
> > understanding the motive and benefits.
> >
> > Quoting jgli...@redhat.com (2019-01-24 00:23:14)
> > > From: Jérôme Glisse
> > >
> > > When range of virtual address is updated read only and corresponding
> > > user ptr object are already read only it is pointless to do anything.
> > > Optimize this case out.
> > >
> > > Signed-off-by: Jérôme Glisse
> > > Cc: Christian König
> > > Cc: Jan Kara
> > > Cc: Felix Kuehling
> > > Cc: Jason Gunthorpe
> > > Cc: Andrew Morton
> > > Cc: Matthew Wilcox
> > > Cc: Ross Zwisler
> > > Cc: Dan Williams
> > > Cc: Paolo Bonzini
> > > Cc: Radim Krčmář
> > > Cc: Michal Hocko
> > > Cc: Ralph Campbell
> > > Cc: John Hubbard
> > > Cc: k...@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: Arnd Bergmann
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_userptr.c | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > index 9558582c105e..23330ac3d7ea 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > @@ -59,6 +59,7 @@ struct i915_mmu_object {
> > > struct interval_tree_node it;
> > > struct list_head link;
> > > struct work_struct work;
> > > + bool read_only;
> > > bool attached;
> > > };
> > >
> > > @@ -119,6 +120,7 @@ static int
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > struct i915_mmu_object *mo;
> > > struct interval_tree_node *it;
> > > + bool update_to_read_only;
> > > LIST_HEAD(cancelled);
> > > unsigned long end;
> > >
> > > @@ -128,6 +130,8 @@ static int
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > /* interval ranges are inclusive, but invalidate range is
> > > exclusive */
> > > end = range->end - 1;
> > >
> > > + update_to_read_only =
> > > mmu_notifier_range_update_to_read_only(range);
> > > +
> > > spin_lock(&mn->lock);
> > > it = interval_tree_iter_first(&mn->objects, range->start, end);
> > > while (it) {
> > > @@ -145,6 +149,17 @@ static int
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > * object if it is not in the process of being destroyed.
> > > */
> > > mo = container_of(it, struct i915_mmu_object, it);
> > > +
> > > + /*
> > > +* If it is already read only and we are updating to
> > > +* read only then we do not need to change anything.
> > > +* So save time and skip this one.
> > > +*/
> > > + if
[PATCH] drm/i915: Enable fastboot by default on VLV and CHV
We really want to have fastboot enabled by default to avoid an ugly modeset during boot. Currently we are enabling fastboot by default on gen9+ (Skylake and newer). The intention is to enable it on older generations after it has seen more testing on gen9+. VLV and CHV devices are still being sold in stores today, as such it is desirable to also enable fastboot by default on these now. I've extensively tested fastboot=1 support on over 50 different Bay- and Cherry-Trail devices. Testing DSI and eDP panels as well as HDMI output (and even DP over Type-C on one device). All 50 devices work fine with fastboot=1. On 2 devices their DSI panel turns black as soon as the i915 driver loads when fastboot=0, so having fastboot enabled is required for these 2 to work properly (for lack of a better fix). Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d756d7358292..0ff42a38023c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11672,7 +11672,15 @@ static bool fastboot_enabled(struct drm_i915_private *dev_priv) return i915_modparams.fastboot; /* Enable fastboot by default on Skylake and newer */ - return INTEL_GEN(dev_priv) >= 9; + if (INTEL_GEN(dev_priv) >= 9) + return true; + + /* Enable fastboot by default on VLV and CHV */ + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) + return true; + + /* Disabled by default on all others */ + return false; } static bool -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [v7 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:56 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 2/2] drm/i915: Attach colorspace property and
>enable
>modeset
>
>Op 28-01-2019 om 09:44 schreef Uma Shankar:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Added Platform specific colorspace enums and called the property
>> creation helper using the same.
>>
>> v6: Addressed Shashank's review comments.
>>
>> v7: Rebase
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> drivers/gpu/drm/i915/intel_connector.c | 63
>++
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 19 ++
>> 4 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..76b7114 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>> */
>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> +new_state->colorspace != old_state->colorspace ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..114fcf2 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -30,6 +30,48 @@
>> #include "intel_drv.h"
>> #include "i915_drv.h"
>>
>> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/*
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
Den 24.01.2019 18.57, skrev Daniel Vetter:
> On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
>>
>> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
>>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
Den 22.01.2019 20.30, skrev Daniel Vetter:
> On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes wrote:
>>
>>
>>
>> Den 22.01.2019 10.32, skrev Daniel Vetter:
>>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
Den 21.01.2019 10.55, skrev Daniel Vetter:
> On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
>> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
>>> This adds resource managed (devres) versions of drm_dev_init() and
>>> drm_dev_register().
>>>
>>> Also added is devm_drm_dev_register_with_fbdev() which sets up
>>> generic
>>> fbdev emulation as well.
>>>
>>> devm_drm_dev_register() isn't exported since there are no users.
>>>
>>> Signed-off-by: Noralf Trønnes
>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 381581b01d48..12129772be45 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -36,6 +36,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include "drm_crtc_internal.h"
>>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device
>>> *dev)
>>> }
>>> EXPORT_SYMBOL(drm_dev_unregister);
>>>
>>> +static void devm_drm_dev_init_release(void *data)
>>> +{
>>> + drm_dev_put(data);
>
> We need drm_dev_unplug() here, or this isn't safe.
This function is only used to cover the error path if probe fails
before
devm_drm_dev_register() is called. devm_drm_dev_register_release() is
the one that calls unplug. There are comments about this in the
functions.
>>>
>>> I think I get a prize for being ignorant and blind :-/
>>>
>
>>> +}
>>> +
>>> +/**
>>> + * devm_drm_dev_init - Resource managed drm_dev_init()
>>> + * @parent: Parent device object
>>> + * @dev: DRM device
>>> + * @driver: DRM driver
>>> + *
>>> + * Managed drm_dev_init(). The DRM device initialized with this
>>> function is
>>> + * automatically released on driver detach. You must supply a
>
> I think a bit more clarity here would be good:
>
> "... automatically released on driver unbind by callind
> drm_dev_unplug()."
>
>>> + * &drm_driver.release callback to control the finalization
>>> explicitly.
>
> I think a loud warning for these is in order:
>
> "WARNING:
>
> "In generally it is unsafe to use devm functions for drm structures
> because the lifetimes of &drm_device and the underlying &device do not
> match. This here works because it doesn't immediately free anything,
> but
> only calls drm_dev_unplug(), which internally decrements the
> &drm_device
> refcount through drm_dev_put().
>
> "All other drm structures must still be explicitly released in the
> &drm_driver.release callback."
>
> While thinking about this I just realized that with this design we
> have no
> good place to call drm_atomic_helper_shutdown(). Which we need to, or
> all
> kinds of things will leak badly (connectors, fb, ...), but there's no
> place to call it:
> - unbind is too early, since we haven't yet called drm_dev_unplug,
> and the
> drm_dev_unregister in there must be called _before_ we start to shut
> down anything.
> - drm_driver.release is way too late.
>
> Ofc for a real hotunplug there's no point in shutting down the hw
> (it's
> already gone), but for a driver unload/unbind it would be nice if this
> happens automatically and in the right order.
>
> So not sure what to do here really.
How about this change: (it breaks the rule of pulling helpers into the
core, so maybe we should put the devm_ functions into the simple KMS
helper instead?)
>>>
>>> Yeah smells a bit much like midlayer ... What would work is having a
>>> pile
>>> more devm_ helper functions, so that we onion-unwrap everything
>>> correctly,
>>> and in the right order. So:
>>>
>>> - devm_drm_dev_init (always does a drm_dev_put())
>>>
>>> - devm_drm_poll_enable (shuts
Re: [PATCH] drm/doc: Task to rename CMA helpers
Den 29.01.2019 14.21, skrev Daniel Vetter: > I'm kinda fed up explaining why the have a confusing name :-) > > Cc: Noralf Trønnes > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > --- I agree that it's confusing, Acked-by: Noralf Trønnes I would also make sense to fold drm_fb_cma_helper into the cma gem helper since there's only 2 functions left after my refactorings. Noralf. > Documentation/gpu/todo.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede1221..17f1cde6adab 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,16 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Rename CMA helpers to DMA helpers > +- > + > +CMA (standing for contiguous memory allocator) is really a bit an accident of > +what these were used for first, a much better name would be DMA helpers. In > the > +text these should even be called coherent DMA memory helpers (so maybd CDM, > but > +no one knows what that means) since underneath they just use > dma_alloc_coherent. > + > +Contact: Laurent Pinchart, Daniel Vetter > + > Core refactorings > = > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/irq: Ditch DRIVER_IRQ_SHARED
On Tue, Jan 29, 2019 at 11:42:48AM +0100, Daniel Vetter wrote:
> This is only used by drm_irq_install(), which is an optional helper.
> For legacy pci devices this is required (due to interrupt sharing without
> msi/msi-x), and just making this the default exactly matches the behaviour
> of all existing drivers using the drm_irq_install() helpers. In case that
> ever becomes wrong drivers can roll their own irq handling, as many
> drivers already do (for other reasons like needing a threaded interrupt
> handler, or having an entire pile of different interrupt sources).
>
> v2: Rebase
>
> v3: Improve commit message (Emil)
>
> Cc: Sam Ravnborg
> Reviewed-by: Emil Velikov
> Signed-off-by: Daniel Vetter
Intel CI is approving now to, so all three patches merged to
drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 4 ++--
> drivers/gpu/drm/gma500/psb_drv.c| 3 +--
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/mga/mga_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.c | 1 -
> drivers/gpu/drm/r128/r128_drv.c | 2 +-
> drivers/gpu/drm/radeon/radeon_drv.c | 4 +---
> drivers/gpu/drm/via/via_drv.c | 3 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> drivers/staging/vboxvideo/vbox_drv.c| 3 +--
> include/drm/drm_drv.h | 22 ++
> 12 files changed, 17 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 22502417c18c..a1bb3773087b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1189,7 +1189,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> *dev, unsigned int pipe,
> static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_ATOMIC |
> - DRIVER_IRQ_SHARED | DRIVER_GEM |
> + DRIVER_GEM |
> DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> .load = amdgpu_driver_load_kms,
> .open = amdgpu_driver_open_kms,
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c5babb3e4752..9bd8908d5fd8 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -120,8 +120,8 @@ int drm_irq_install(struct drm_device *dev, int irq)
> if (dev->driver->irq_preinstall)
> dev->driver->irq_preinstall(dev);
>
> - /* Install handler */
> - if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
> + /* PCI devices require shared interrupts. */
> + if (dev->pdev)
> sh_flags = IRQF_SHARED;
>
> ret = request_irq(irq, dev->driver->irq_handler,
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 7cf14aeb1c28..eefaf4daff2b 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -468,8 +468,7 @@ static const struct file_operations psb_gem_fops = {
> };
>
> static struct drm_driver driver = {
> - .driver_features = DRIVER_IRQ_SHARED | \
> -DRIVER_MODESET | DRIVER_GEM,
> + .driver_features = DRIVER_MODESET | DRIVER_GEM,
> .load = psb_driver_load,
> .unload = psb_driver_unload,
> .lastclose = drm_fb_helper_lastclose,
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 550cfb945942..a7aaa1ac4c99 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3010,7 +3010,7 @@ static struct drm_driver driver = {
>* deal with them for Intel hardware.
>*/
> .driver_features =
> - DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
> + DRIVER_GEM | DRIVER_PRIME |
> DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
> .release = i915_driver_release,
> .open = i915_driver_open,
> diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
> index 1aad27813c23..6e1d1054ad06 100644
> --- a/drivers/gpu/drm/mga/mga_drv.c
> +++ b/drivers/gpu/drm/mga/mga_drv.c
> @@ -57,7 +57,7 @@ static const struct file_operations mga_driver_fops = {
> static struct drm_driver driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_LEGACY |
> - DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
> + DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ,
> .dev_priv_size = sizeof(drm_mga_buf_priv_t),
> .load = mga_driver_load,
> .unload = mga_driver_unload,
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 1669d4b79253..bb81e310eb6d 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -245,7 +245,6 @@ static struct pci_driver qxl_pci_driver = {
>
> static struct drm_driver qxl_driver = {
> .driver_features = DRIVER_GEM | DRIV
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your dmesg output and xorg log (if using X). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Make igts for cross-driver stuff strongly suggested
Hi Daniel, On Mon, Jan 28, 2019 at 06:22:58PM +0100, Daniel Vetter wrote: > Compared to the RFC[1] no changes to the patch itself, but igt moved > forward a lot: > > - gitlab CI builds with: reduced configs/libraries, arm cross build > and a sysroot build (should address all the build/cross platform > concerns raised in the RFC discussions). > > - tests reorganized into subdirectories so that the i915-gem tests > don't clog the main/shared tests directory anymore > > - quite a few more non-intel people contributing/reviewing/committing > igt tests patches. > > I think this addresses all the concerns raised in the RFC discussions, > and assuming there's enough Acks and no new issues that pop up, we can > go ahead with this. > > v2: > - Use "should" (in the usual RFC sense) to make it clear that in the > end this is all up to reviewer's discretion, as usual (Jani). > - Also in the title s/mandatory/strongly suggested/ (me) > - Make it clear we're not going to block features if a testcase is not > feasible, given hw and state of igt, both having some good gaps in > what can be tested (Harry, Eric, Sean, ...). > > 1: https://patchwork.kernel.org/patch/10648851/ > Cc: Petri Latvala > Cc: Arkadiusz Hiler > Cc: Liviu Dudau > Cc: Sean Paul > Cc: Eric Anholt > Cc: Alex Deucher > Cc: Dave Airlie > Cc: Daniel Stone > Cc: "Wentland, Harry" > Cc: Brian Starkey > Reviewed-by: Eric Anholt (v1) > Acked-by: Petri Latvala > Acked-by: Arkadiusz Hiler > Acked-by: Sean Paul > Acked-by: "Wentland, Harry" > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-uapi.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index a752aa561ea4..c9fd23efd957 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly > unintuitive meaning of > Testing and validation > == > > +Testing Requirements for userspace API > +-- > + > +New cross-driver userspace interface extensions, like new IOCTL, new KMS > +properties, new files in sysfs or anything else that constitutes an API > change > +should have driver-agnostic testcases in IGT for that feature, if such a test > +can be reasonably made using IGT for the target hardware. > + Thank you for the revision and clarification. Acked-by: Brian Starkey > Validating changes with IGT > --- > > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Xen-devel][PATCH] drm/xen-front: Fix mmap attributes for display buffers
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Oleksandr Andrushchenko
Suggested-by: Julien Grall
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index d303a2e17f5e..9d5c03d7668d 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -235,8 +235,7 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
vma->vm_flags &= ~VM_PFNMAP;
vma->vm_flags |= VM_MIXEDMAP;
vma->vm_pgoff = 0;
- vma->vm_page_prot =
- pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
/*
* vm_operations_struct.fault handler will be called if CPU access
@@ -283,7 +282,7 @@ void *xen_drm_front_gem_prime_vmap(struct drm_gem_object
*gem_obj)
return NULL;
return vmap(xen_obj->pages, xen_obj->num_pages,
- VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+ VM_MAP, PAGE_KERNEL);
}
void xen_drm_front_gem_prime_vunmap(struct drm_gem_object *gem_obj,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Hi Sam,
On Mon, Jan 28, 2019 at 12:41 AM Jagan Teki wrote:
>
> On Sat, Jan 26, 2019 at 1:22 AM Sam Ravnborg wrote:
> >
> > Hi Jagan.
> >
> > Looks good, only very few nits left.
> >
> > On Sat, Jan 26, 2019 at 12:52:33AM +0530, Jagan Teki wrote:
> > > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> > >
> > > Add panel driver for it.
> > >
> > > Tested-by: Bhushan Shah
> > > Signed-off-by: Jagan Teki
> >
> > If you consider my inputs (I know you will) then you can add my:
> > Reviewed-by: Sam Ravnborg
> >
> >
> > > + msleep(20);
> > > +
> > > + gpiod_set_value(ctx->reset, 0);
> > > + /* T5 + T6 (avdd rise + video & logic signal rise)
> > > + * T5 >= 10ms, 0 < T6 <= 10ms
> > > + */
> > > + msleep(20);
> >
> > Please use kernel coding style comment, and maybe an empty
> > line between gpiod...() and the comment:
> >
> > gpiod_set_value(ctx->reset, 0);
> > /*
> > * T5 + T6 (avdd rise + video & logic signal rise)
> > * T5 >= 10ms, 0 < T6 <= 10ms
> > */
> > msleep(20);
> >
> >
> > > +static int feiyang_get_modes(struct drm_panel *panel)
> > > +{
> > > + struct drm_connector *connector = panel->connector;
> > > + struct feiyang *ctx = panel_to_feiyang(panel);
> > > + struct drm_display_mode *mode;
> > > +
> > > + mode = drm_mode_duplicate(panel->drm, &feiyang_default_mode);
> > > + if (!mode) {
> > > + DRM_DEV_ERROR(&ctx->dsi->dev, "failed to add mode
> > > %ux%ux@%u\n",
> > > + feiyang_default_mode.hdisplay,
> > > + feiyang_default_mode.vdisplay,
> > > + feiyang_default_mode.vrefresh);
> > Please consider to use DRM_MODE_FMT and DRM_MODE_ARG for printing.
>
> I see DRM_MODE_ARG as mode argument, that print all mode timings but
> here we need only 3 timings out of it. do we really need? if yes
> please suggest an example.
fyi: sent v6 for this except this change. Let me know if you have any
comments on this.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v6 14/22] dt-bindings: sun6i-dsi: Add A64 DSI compatible (w/ A31 fallback)
On Sat, Jan 26, 2019 at 09:39:00PM +0530, Jagan Teki wrote: > On 25/01/19 9:22 PM, Maxime Ripard wrote: > > On Fri, Jan 25, 2019 at 01:28:52AM +0530, Jagan Teki wrote: > > > The MIPI DSI controller in Allwinner A64 is similar to A33. > > > > > > But unlike A33, A64 doesn't have DSI_SCLK gating which eventually > > > set the mod clock rate for the controller. > > > > > > So, use the DSI_DPHY gating for the similar purpose of mod clock > > > so-that the controller can operate properly. > > > > > > Signed-off-by: Jagan Teki > > > Reviewed-by: Rob Herring > > > --- > > > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > > index 69e233e8fad1..dbda2e567760 100644 > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > > > @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the > > > TCON's. > > > Required properties: > > > - compatible: value must be one of: > > > * allwinner,sun6i-a31-mipi-dsi > > > +* "allwinner,sun50i-a64-mipi-dsi", "allwinner,sun6i-a31-mipi-dsi" > > > > The other line doesn't have quotes, we should be consistent > > You mean to say, remove quotes like this > > allwinner,sun50i-a64-mipi-dsi, allwinner,sun6i-a31-mipi-dsi Yep > This make confusion with comma with allwinner vs next compatible string > isn't it? (In fact I did follow the similar like TCON in sun4i-drm.txt) There's no really clear consensus here, andd i don't really have a strong opinion on the matter either. Since the YAML schemas are going to have it without double quotes, I guess we should use that convention as well, but we want to remain consistent at least. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] New: vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 Bug ID: 202449 Summary: vrr_capable not showing up in xrandr with eDP display. Product: Drivers Version: 2.5 Kernel Version: 4.20 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: haxk...@gmail.com Regression: No Created attachment 280847 --> https://bugzilla.kernel.org/attachment.cgi?id=280847&action=edit xrandr --props xrandr doesnt show vrr_capable option for eDP display but the option is there with HDMI. While its true that my internal display on laptop doesnt report that it supports FreeSync but i know that it works with Freesync because when i edit EDID in windows freesync works. But im sure the issue isnt that my display doesnt report Freesync since when i connect a monitor that i know isnt freesync capable to HDMI the option is still there. I attach output of "xranr --props" of my laptop. Laptop has Ryzen 5 2500U with VEGA8 (Raven Ridge) and dedicated RX560X. VEGA 8 is connected directly to internal display (eDP) and RX560X is connected to HDMI port. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 18.57, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
> >>
> >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
>
>
> Den 22.01.2019 20.30, skrev Daniel Vetter:
> > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > wrote:
> >>
> >>
> >>
> >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 21.01.2019 10.55, skrev Daniel Vetter:
> > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
> >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> >>> This adds resource managed (devres) versions of drm_dev_init() and
> >>> drm_dev_register().
> >>>
> >>> Also added is devm_drm_dev_register_with_fbdev() which sets up
> >>> generic
> >>> fbdev emulation as well.
> >>>
> >>> devm_drm_dev_register() isn't exported since there are no users.
> >>>
> >>> Signed-off-by: Noralf Trønnes
> >>
>
>
>
> >>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >>> index 381581b01d48..12129772be45 100644
> >>> --- a/drivers/gpu/drm/drm_drv.c
> >>> +++ b/drivers/gpu/drm/drm_drv.c
> >>> @@ -36,6 +36,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>>
> >>> #include "drm_crtc_internal.h"
> >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device
> >>> *dev)
> >>> }
> >>> EXPORT_SYMBOL(drm_dev_unregister);
> >>>
> >>> +static void devm_drm_dev_init_release(void *data)
> >>> +{
> >>> + drm_dev_put(data);
> >
> > We need drm_dev_unplug() here, or this isn't safe.
>
> This function is only used to cover the error path if probe fails
> before
> devm_drm_dev_register() is called. devm_drm_dev_register_release() is
> the one that calls unplug. There are comments about this in the
> functions.
> >>>
> >>> I think I get a prize for being ignorant and blind :-/
> >>>
>
> >
> >>> +}
> >>> +
> >>> +/**
> >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> >>> + * @parent: Parent device object
> >>> + * @dev: DRM device
> >>> + * @driver: DRM driver
> >>> + *
> >>> + * Managed drm_dev_init(). The DRM device initialized with this
> >>> function is
> >>> + * automatically released on driver detach. You must supply a
> >
> > I think a bit more clarity here would be good:
> >
> > "... automatically released on driver unbind by callind
> > drm_dev_unplug()."
> >
> >>> + * &drm_driver.release callback to control the finalization
> >>> explicitly.
> >
> > I think a loud warning for these is in order:
> >
> > "WARNING:
> >
> > "In generally it is unsafe to use devm functions for drm structures
> > because the lifetimes of &drm_device and the underlying &device do
> > not
> > match. This here works because it doesn't immediately free
> > anything, but
> > only calls drm_dev_unplug(), which internally decrements the
> > &drm_device
> > refcount through drm_dev_put().
> >
> > "All other drm structures must still be explicitly released in the
> > &drm_driver.release callback."
> >
> > While thinking about this I just realized that with this design we
> > have no
> > good place to call drm_atomic_helper_shutdown(). Which we need to,
> > or all
> > kinds of things will leak badly (connectors, fb, ...), but there's
> > no
> > place to call it:
> > - unbind is too early, since we haven't yet called drm_dev_unplug,
> > and the
> > drm_dev_unregister in there must be called _before_ we start to
> > shut
> > down anything.
> > - drm_driver.release is way too late.
> >
> > Ofc for a real hotunplug there's no point in shutting down the hw
> > (it's
> > already gone), but for a driver unload/unbind it would be nice if
> > this
> > happens automatically and in the right order.
> >
> > So not sure what to do here really.
>
> How about this change: (it breaks the rule of pulling helpers into
> the
> core, so maybe we should put the devm_ functions
Re: [PATCH v5 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Hi Jagan. > > > > I see DRM_MODE_ARG as mode argument, that print all mode timings but > > here we need only 3 timings out of it. do we really need? if yes > > please suggest an example. > > fyi: sent v6 for this except this change. Let me know if you have any > comments on this. Drivers looks fine, the above was just a quick suggestion to use some exising plumbing. You have done a nice job following up on all the feedback. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Hi Uma,
On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 5:54 PM
> >To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> >dri-devel@lists.freedesktop.org
> >Cc: Syrjala, Ville ; Lankhorst, Maarten
> >
> >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
> >
> >Op 28-01-2019 om 09:44 schreef Uma Shankar:
> >> Create a new connector property to program colorspace to sink devices.
> >> Modern sink devices support more than 1 type of colorspace like 601,
> >> 709, BT2020 etc. This helps to switch based on content type which is
> >> to be displayed. The decision lies with compositors as to in which
> >> scenarios, a particular colorspace will be picked.
> >>
> >> This will be helpful mostly to switch to higher gamut colorspaces like
> >> BT2020 when the media content is encoded as BT2020. Thereby giving a
> >> good visual experience to users.
> >>
> >> The expectation from userspace is that it should parse the EDID and
> >> get supported colorspaces. Use this property and switch to the one
> >> supported. Driver will expose the platform supported colorspaces,
> >> however sink supported colorspaces should be retrieved by userspace
> >> from EDID.
> >>
> >> Basically the expectation from userspace is:
> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >>colorspace
> >> - Set this new property to let the sink know what it
> >>converted the CRTC output to.
> >>
> >> v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> colorspace enum to incorporate both HDMI and DP supported colorspaces.
> >> Also, added a default option for colorspace.
> >>
> >> v3: Removed Adobe references from enum definitions as per Ville, Hans
> >> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
> >> state where driver will assign the colorspace is not chosen by user,
> >> suggested by Ville and Maarten. Addressed other misc review comments
> >> from Maarten. Split the changes to have separate colorspace property
> >> for DP and HDMI.
> >>
> >> v4: Addressed Chris and Ville's review comments, and created a common
> >> colorspace property for DP and HDMI, filtered the list based on the
> >> colorspaces supported by the respective protocol standard.
> >>
> >> v5: Made the property creation helper accept enum list based on
> >> platform capabilties as suggested by Shashank. Consolidated HDMI and
> >> DP property creation in the common helper.
> >>
> >> v6: Addressed Shashank's review comments.
> >>
> >> v7: Added defines instead of enum in uapi as per Brian Starkey's
> >> suggestion in order to go with string matching at userspace. Updated
> >> the commit message to add more details as well kernel docs.
> >>
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_connector.c | 95
> >+++
> >> include/drm/drm_connector.h | 17 +++
> >> include/uapi/drm/drm_mode.h | 32 +
> >> 4 files changed, 148 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 9a1f41a..9b5d44f 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >>return -EINVAL;
> >>}
> >>state->content_protection = val;
> >> + } else if (property == connector->colorspace_property) {
> >> + state->colorspace = val;
> >>} else if (property == config->writeback_fb_id_property) {
> >>struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
> >NULL, val);
> >>int ret = drm_atomic_set_writeback_fb_for_connector(state,
> >fb); @@
> >> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >>*val = state->picture_aspect_ratio;
> >>} else if (property == config->content_type_property) {
> >>*val = state->content_type;
> >> + } else if (property == connector->colorspace_property) {
> >> + *val = state->colorspace;
> >>} else if (property == connector->scaling_mode_property) {
> >>*val = state->scaling_mode;
> >>} else if (property == connector->content_protection_property) {
> >> diff --git a/drivers/gpu/drm/drm_connector.c
> >> b/drivers/gpu/drm/drm_connector.c index 8475396..eafa643 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
> >> drm_display_info *info, };
> >> DRM_ENUM_NAME_FN(drm_get_content_protection_name,
> >drm_cp_enum_list)
> >>
> >> +/* List of HDMI Colorspaces supported */ static c
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote: > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard > wrote: > > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote: > > > Minimum PLL used for MIPI is 500MHz, as per manual, but > > > lowering the min rate by 300MHz can result proper working > > > nkms divider with the help of desired dclock rate from > > > panel driver. > > > > > > Signed-off-by: Jagan Teki > > > Acked-by: Stephen Boyd > > > > Going 200MHz below the minimum doesn't seem really reasonable. What > > is the issue that you are trying to fix here? > > > > It looks like it's picking bad dividers, but if that's the case, this > > isn't the proper fix. > > As I stated in earlier patches, the whole idea is pick the desired > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate > is unable to get the proper dclk divider at the end, so it eventually > picking up wrong divider value and fired vblank timeout. > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to > get the desired clock something like below. > [2.415773] [drm] No driver support for vblank timestamp query. > [2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > 5500 > [2.424172] ideal = 22000, rounded = 0 > [2.424176] ideal = 27500, rounded = 0 > [2.424194] ccu_nkm_round_rate: rate = 33000 > [2.424197] ideal = 33000, rounded = 33000 > [2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500 > [2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > 5500 > [2.424209] ideal = 22000, rounded = 0 > [2.424213] ideal = 27500, rounded = 0 > [2.424230] ccu_nkm_round_rate: rate = 33000 > [2.424233] ideal = 33000, rounded = 33000 > [2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500 > [2.424253] ccu_nkm_round_rate: rate = 33000 > [2.424270] ccu_nkm_round_rate: rate = 33000 > [2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > [2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > [2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = 29700 > [2.424309] ccu_nkm_set_rate: _nkm.n = 5 > [2.424311] ccu_nkm_set_rate: _nkm.k = 2 > [2.424313] ccu_nkm_set_rate: _nkm.m = 9 > [2.424661] sun4i_dclk_set_rate div 6 > [2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500 > > But look like this wouldn't valid for all other dclock rates, say BPI > panel has 30MHz clock that would failed with this logic. > > On the other side Allwinner BSP calculating dclk divider based on the > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is > calculated based on the bpp/lanes. It looks like the A64 has the same divider of 4: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 I think you're confusing it with the ratio between the pixel clock and the dotclock, called dsi_div: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198 Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109487] drm-next-5.1-wip broken as of 672c6238
https://bugs.freedesktop.org/show_bug.cgi?id=109487 --- Comment #4 from Alex Deucher --- Reverting this patch should fix it: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 1/2] drm: Add colorspace connector property
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like 601,
709, BT2020 etc. This helps to switch based on content type which is
to be displayed. The decision lies with compositors as to in which
scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Driver will expose the platform supported colorspaces,
however sink supported colorspaces should be retrieved by userspace
from EDID.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 95 +++
include/drm/drm_connector.h | 17 +++
include/uapi/drm/drm_mode.h | 32 +
4 files changed, 148 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..e8575d1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+/* List of HDMI Colorspaces supported */
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_
[v8 0/2] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Driver will expose the platform supported colorspaces, however sink supported colorspaces should be retrieved by userspace from EDID. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. Uma Shankar (2): drm: Add colorspace connector property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 95 ++ drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 63 ++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 24 + include/drm/drm_connector.h| 17 ++ include/uapi/drm/drm_mode.h| 32 8 files changed, 237 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 2/2] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Added Platform specific colorspace enums and called the
property creation helper using the same.
v6: Addressed Shashank's review comments.
v7: Rebase
v8: Addressed Maarten's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 63 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 24 +
4 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..76b7114 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..9a12d5e 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -30,6 +30,48 @@
#include "intel_drv.h"
#include "i915_drv.h"
+static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+};
+
int intel_connector_init(struct intel_connector *connector)
{
struct intel_digital_connector_state *conn_state;
@@ -265,3 +307,24 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_propert
Re: [PATCH v1 1/1] drm: drop drm_bus from todo
On Tue, Jan 29, 2019 at 3:54 AM Daniel Vetter wrote:
>
> On Sun, Jan 27, 2019 at 12:00:37PM +0100, David Herrmann wrote:
> > Hey
> >
> > On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> > > David Herrmann removed the last bits of drm_bus in:
> > > c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
> > >
> > > Remove the todo item.
> > >
> > > Signed-off-by: Sam Ravnborg
> > > Cc: David Herrmann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Sean Paul
> > > ---
> > > Documentation/gpu/todo.rst | 19 ---
> > > 1 file changed, 19 deletions(-)
> >
> > I miss drm_bus!
> >
> > Reviewed-by: David Herrmann
>
> Sam, want drm-misc commit rights to start merging your own stuff? Assuming
> you plan to stick around ofc ... I'll also ask the drm-misc maintainers
> whether that's ok.
>
Acked-by: Sean Paul
> Thanks, Daniel
>
> >
> > Thanks
> > David
> >
> > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > index 38360ede1221..d9515b17d36f 100644
> > > --- a/Documentation/gpu/todo.rst
> > > +++ b/Documentation/gpu/todo.rst
> > > @@ -10,25 +10,6 @@ graphics subsystem useful as newbie projects. Or for
> > > slow rainy days.
> > > Subsystem-wide refactorings
> > > ===
> > >
> > > -De-midlayer drivers
> > >
> > > -
> > > -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer
> > > required
> > > -to have a ``drm_bus`` structure set up. Drivers can directly set up the
> > > -``drm_device`` structure instead of relying on bus methods in
> > > ``drm_usb.c``
> > > -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
> > > -``->unload`` callbacks and open-code the load/unload sequence properly,
> > > using
> > > -the new two-stage ``drm_device`` setup/teardown.
> > > -
> > > -Once all existing drivers are converted we can also remove those bus
> > > support
> > > -files for USB and platform devices.
> > > -
> > > -All you need is a GPU for a non-converted driver (currently almost all of
> > > -them, but also all the virtual ones used by KVM, so everyone qualifies).
> > > -
> > > -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers
> > > -
> > > -
> > > Remove custom dumb_map_offset implementations
> > > -
> > >
> > > --
> > > 2.12.0
> > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry wrote: > > On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: > > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The > > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn > > on SSE2 to support emitting double precision floating point instructions > > rather than calls to non-existent (usually available from gcc_s or > > compiler_rt) floating point helper routines. > > > > Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html > > Link: https://github.com/ClangBuiltLinux/linux/issues/327 > > Cc: sta...@vger.kernel.org # 4.19 > > Reported-by: S, Shirish > > Reported-by: Matthias Kaehlcke > > Suggested-by: James Y Knight > > Suggested-by: Nathan Chancellor > > Signed-off-by: Nick Desaulniers > > Tested-by: Guenter Roeck > > Reviewed-by: Harry Wentland > > and applied. > This patch causes a segfault: https://bugs.freedesktop.org/show_bug.cgi?id=109487 Any ideas? Alex > Harry > > > --- > > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > index 95f332ee3e7e..dc85a3c088af 100644 > > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > > cc_stack_align := -mstack-alignment=16 > > endif > > > > -calcs_ccflags := -mhard-float -msse $(cc_stack_align) > > +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > index d97ca6528f9d..33c7d7588712 100644 > > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > > cc_stack_align := -mstack-alignment=16 > > endif > > > > -dml_ccflags := -mhard-float -msse $(cc_stack_align) > > +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #1 from Haxk20 (haxk...@gmail.com) --- Sorry after further reading im not sure that dGPU is connected to HDMI directly. Is there a way to see in linux ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your dmesg output and xorg log. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109487] drm-next-5.1-wip broken as of 672c6238
https://bugs.freedesktop.org/show_bug.cgi?id=109487 --- Comment #5 from Tom St Denis --- Reverting just the -msse2 commit on top of drm-next works fine for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/panel: Add Rondo RB070D30 panel
Hi Sam,
Thanks for the review, I'll address the points left out.
On Sat, Jan 26, 2019 at 04:39:46PM +0100, Sam Ravnborg wrote:
> > + return ret;
> > + }
> > +
> > + /* Reset */
> > + msleep(20);
> > + gpiod_set_value(ctx->gpios.power, 1);
> > + msleep(20);
> > + gpiod_set_value(ctx->gpios.reset, 1);
> > + msleep(20);
> > + return 0;
> > +}
> To verify the above pointer to a datasheet would be nice.
Unfortunately, it's not publicly available :/
> > +
> > +static int rb070d30_panel_unprepare(struct drm_panel *panel)
> > +{
> > + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> > +
> > + gpiod_set_value(ctx->gpios.power, 0);
> > + gpiod_set_value(ctx->gpios.reset, 0);
> > + regulator_disable(ctx->supply);
> > +
> > + return 0;
> > +}
>
> There is sometimes timing constrains after deassert reset..
> The order is not strictly reverse of prepare - is that on purpose?
You're right about the order. I couldn't find any delay after a reset
though in the datasheet.
> > +/* Default timings */
> > +static const struct drm_display_mode default_mode = {
> > + .clock = 51206,
> > + .hdisplay = 1024,
> > + .hsync_start= 1024 + 160,
> > + .hsync_end = 1024 + 160 + 80,
> > + .htotal = 1024 + 160 + 80 + 80,
> > + .vdisplay = 600,
> > + .vsync_start= 600 + 12,
> > + .vsync_end = 600 + 12 + 10,
> > + .vtotal = 600 + 12 + 10 + 13,
> > + .vrefresh = 60,
> > +};
> height and width missing here. Seems better to add them here than hiding in
> code below.
> Is it on purpose that no flags are specified?
>
> > +
> > +static int rb070d30_panel_get_modes(struct drm_panel *panel)
> > +{
> > + struct drm_connector *connector = panel->connector;
> > + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> > + struct drm_display_mode *mode;
> > + static const u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > +
> > + mode = drm_mode_duplicate(panel->drm, &default_mode);
> > + if (!mode) {
> > + dev_err(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
> > + default_mode.hdisplay, default_mode.vdisplay,
> > + default_mode.vrefresh);
> Use"
> DRM_DEV_ERROR(&ctx->dsi->dev,
> "failed to add mode" DRM_MODE_FMT,
> DRM_MODE_ARG(mode));
> > + return -EINVAL;
> > + }
> > +
> > + drm_mode_set_name(mode);
> > +
> > + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > + drm_mode_probed_add(connector, mode);
> > +
> > + panel->connector->display_info.bpc = 8;
> > + panel->connector->display_info.width_mm = 154;
> > + panel->connector->display_info.height_mm = 85;
> See comment on height above.
> Same goes for bpc
Sorry, I'm not sure to follow you here. bpc and height are both set?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace. This can be used to send an
> infoframe packet with proper colorspace value set which
> will help to enable wider color gamut like BT2020 on sink.
>
> This patch attaches and enables HDMI colorspace, DP will be
> taken care separately.
>
> v2: Merged the changes of creating infoframe as well to this
> patch as per Maarten's suggestion.
>
> v3: Addressed review comments from Shashank. Separated HDMI
> and DP colorspaces as suggested by Ville and Maarten.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard. Handle the default case properly.
>
> v5: Added Platform specific colorspace enums and called the
> property creation helper using the same.
>
> v6: Addressed Shashank's review comments.
>
> v7: Rebase
>
> v8: Addressed Maarten's review comments.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> drivers/gpu/drm/i915/intel_connector.c | 63
> ++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
> 4 files changed, 89 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 16263ad..76b7114 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
>*/
> if (new_conn_state->force_audio != old_conn_state->force_audio ||
> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
> + new_state->colorspace != old_state->colorspace ||
> new_conn_state->base.picture_aspect_ratio !=
> old_conn_state->base.picture_aspect_ratio ||
> new_conn_state->base.content_type !=
> old_conn_state->base.content_type ||
> new_conn_state->base.scaling_mode !=
> old_conn_state->base.scaling_mode)
> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758..9a12d5e 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -30,6 +30,48 @@
> #include "intel_drv.h"
> #include "i915_drv.h"
>
> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> +};
> +
> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Standard Definition Colorimetry based on CEA 861 */
> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> +};
Why are we duplicating these in the driver code? And why do we have
different s
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #4 from Haxk20 (haxk...@gmail.com) --- Created attachment 280851 --> https://bugzilla.kernel.org/attachment.cgi?id=280851&action=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202449] vrr_capable not showing up in xrandr with eDP display.
https://bugzilla.kernel.org/show_bug.cgi?id=202449 --- Comment #3 from Haxk20 (haxk...@gmail.com) --- Created attachment 280849 --> https://bugzilla.kernel.org/attachment.cgi?id=280849&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #2 from Clément Guérin (li...@protonmail.com) --- Created attachment 280853 --> https://bugzilla.kernel.org/attachment.cgi?id=280853&action=edit dmesg output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #3 from Clément Guérin (li...@protonmail.com) --- Created attachment 280855 --> https://bugzilla.kernel.org/attachment.cgi?id=280855&action=edit Xorg.1.log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/panel: Add Rondo RB070D30 panel
Hi Maxime. > > > + } > > > + > > > + drm_mode_set_name(mode); > > > + > > > + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED; > > > + drm_mode_probed_add(connector, mode); > > > + > > > + panel->connector->display_info.bpc = 8; > > > + panel->connector->display_info.width_mm = 154; > > > + panel->connector->display_info.height_mm = 85; > > See comment on height above. > > Same goes for bpc > > Sorry, I'm not sure to follow you here. bpc and height are both set? I assumed that if we had specified height and width in display_mode then we did not have to do it here. But I may be wrong. And for bpc I was plain wrong. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/sun4i: dsi: Restrict DSI tcon clock divider
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current code allows the TCON clock divider to have a range between 4
> and 127 when feeding the DSI controller.
>
> The only display supported so far had a display clock rate that ended up
> using a divider of 4, but testing with other displays show that only 4
> seems to be functional.
>
> This also aligns with what Allwinner is doing in their BSP, so let's just
> hardcode that we want a divider of 4 when using the DSI output.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 0420f5c978b9..bee73ead732a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -341,8 +341,8 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon
> *tcon,
> u32 block_space, start_delay;
> u32 tcon_div;
>
> - tcon->dclk_min_div = 4;
> - tcon->dclk_max_div = 127;
> + tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> + tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
>
> sun4i_tcon0_mode_set_common(tcon, mode);
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index dbbc5b3ecbda..6d4a3c0fd9b5 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#define SUN6I_DSI_TCON_DIV 4
> +
> struct sun6i_dphy {
> struct clk *bus_clk;
> struct clk *mod_clk;
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh
On Tue, Jan 29, 2019 at 09:59:40AM +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Use the drm_mode_vrefresh helper where we need refresh rate in case
> > vrefresh is empty.
> >
> > Signed-off-by: Sean Paul
>
> I think adding a todo to remove these fields and switch everone over to
> the helpers would be useful. Recomputing is not going to hurt us I think
> in modeset code (the one case where we do care is vblank constants, and
> those are somewhere else), and would avoid all these bugs ...
Yeah, and to boot if vrefresh is populated, the function just returns it, so
it's quite safe (unless someone is relying on vrefresh == 0 as valid data, which
would be nice to weed out anyways).
I'll spin up a TODO patch, good suggestion.
Sean
> -Daniel
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 2 +-
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
> > 4 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 941ac25d2a023..dd71cb6ba4f5c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -522,8 +522,8 @@ static void _dpu_encoder_adjust_mode(struct
> > drm_connector *connector,
> >
> > list_for_each_entry(cur_mode, &connector->modes, head) {
> > if (cur_mode->vdisplay == adj_mode->vdisplay &&
> > - cur_mode->hdisplay == adj_mode->hdisplay &&
> > - cur_mode->vrefresh == adj_mode->vrefresh) {
> > + cur_mode->hdisplay == adj_mode->hdisplay &&
> > + drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
> > {
> > adj_mode->private = cur_mode->private;
> > adj_mode->private_flags |= cur_mode->private_flags;
> > }
> > @@ -1805,7 +1805,7 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> > bool async)
> >
> > atomic_set(&dpu_enc->frame_done_timeout,
> > DPU_FRAME_DONE_TIMEOUT * 1000 /
> > - drm_enc->crtc->state->adjusted_mode.vrefresh);
> > +
> > drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
> > mod_timer(&dpu_enc->frame_done_timer, jiffies +
> > ((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > index 99ab5ca9bed3b..f21163313d635 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > @@ -404,7 +404,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> > return;
> > }
> >
> > - tc_cfg.vsync_count = vsync_hz / (mode->vtotal * mode->vrefresh);
> > + tc_cfg.vsync_count = vsync_hz /
> > + (mode->vtotal * drm_mode_vrefresh(mode));
> >
> > /* enable external TE after kickoff to avoid premature autorefresh */
> > tc_cfg.hw_vsync_mode = 0;
> > @@ -424,7 +425,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> > DPU_DEBUG_CMDENC(cmd_enc,
> > "tc %d vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
> > phys_enc->hw_pp->idx - PINGPONG_0, vsync_hz,
> > - mode->vtotal, mode->vrefresh);
> > + mode->vtotal, drm_mode_vrefresh(mode));
> > DPU_DEBUG_CMDENC(cmd_enc,
> > "tc %d enable %u start_pos %u rd_ptr_irq %u\n",
> > phys_enc->hw_pp->idx - PINGPONG_0, tc_enable, tc_cfg.start_pos,
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index b01183b309b9e..da1f727d74957 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -387,7 +387,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane
> > *plane,
> > ot_params.width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
> > ot_params.height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
> > ot_params.is_wfd = !pdpu->is_rt_pipe;
> > - ot_params.frame_rate = crtc->mode.vrefresh;
> > + ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
> > ot_params.vbif_idx = VBIF_RT;
> > ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
> > ot_params.rd = true;
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > index c1962f29ec7d6..6341ac010f7de 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > @@ -59,10 +59,10 @@ static int pingpong_tearcheck_setup(struct drm_encoder
> > *
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Hi, On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: > On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: > > >> +#define DP_COLORIMETRY_SCRGB 15 > > >> +#define DP_COLORIMETRY_DCI_P3 16 > > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 > > Sorry, I somehow missed your reply earlier in the month - but this > wasn't what I meant. > > The expectation with enum properties is that the numeric values are > determined at runtime - userspace shouldn't depend on them being known > at compile-time. So, in include/uapi there shouldn't be these numeric > values. > > The strings themselves effectively form the UABI, so I was wondering > if they should be defined in include/uapi, but you would be the first > to do that. > > Daniel Vetter and/or Daniel Stone might have opinions on this. That's correct. The DPMS definitions are a historical aberration, and we should not be adding any more numeric definitions of enum properties to uABI. They can be fixed in the kernel, but userspace must only rely on the strings. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: add definitions for DP Audio/Video compliance tests
On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote: > This change adds definitions needed for DP audio compliance testing. > It also adds missing definition for DP video compliance. > > Changes in V2: > -- Delete cover letter for this patch. > -- Move the description from cover letter into patch commit message. > -- Remove DPU from subject prefix > > Signed-off-by: Chandan Uddaraju Reviewed-by: Sean Paul If no one has any objections, it'd be nice to apply this through msm tree along with the dpu code that makes use of it. Sean > --- > include/drm/drm_dp_helper.h | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 5736c94..e688e05 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -556,6 +556,8 @@ > # define DP_TEST_LINK_EDID_READ (1 << 2) > # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */ > # define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */ > +# define DP_TEST_LINK_AUDIO_PATTERN (1 << 5) /* DPCD >= 1.2 */ > +# define DP_TEST_LINK_AUDIO_DISABLED_VIDEO (1 << 6) /* DPCD >= 1.2 */ > > #define DP_TEST_LINK_RATE0x219 > # define DP_LINK_RATE_162(0x6) > @@ -604,6 +606,7 @@ > # define DP_COLOR_FORMAT_RGB(0 << 1) > # define DP_COLOR_FORMAT_YCbCr422 (1 << 1) > # define DP_COLOR_FORMAT_YCbCr444 (2 << 1) > +# define DP_TEST_DYNAMIC_RANGE_VESA (0 << 3) > # define DP_TEST_DYNAMIC_RANGE_CEA (1 << 3) > # define DP_TEST_YCBCR_COEFFICIENTS (1 << 4) > # define DP_YCBCR_COEFFICIENTS_ITU601 (0 << 4) > @@ -653,6 +656,16 @@ > > #define DP_TEST_SINK 0x270 > # define DP_TEST_SINK_START (1 << 0) > +#define DP_TEST_AUDIO_MODE 0x271 > +#define DP_TEST_AUDIO_PATTERN_TYPE 0x272 > +#define DP_TEST_AUDIO_PERIOD_CH1 0x273 > +#define DP_TEST_AUDIO_PERIOD_CH2 0x274 > +#define DP_TEST_AUDIO_PERIOD_CH3 0x275 > +#define DP_TEST_AUDIO_PERIOD_CH4 0x276 > +#define DP_TEST_AUDIO_PERIOD_CH5 0x277 > +#define DP_TEST_AUDIO_PERIOD_CH6 0x278 > +#define DP_TEST_AUDIO_PERIOD_CH7 0x279 > +#define DP_TEST_AUDIO_PERIOD_CH8 0x27A > > #define DP_FEC_STATUS0x280/* 1.4 */ > # define DP_FEC_DECODE_EN_DETECTED (1 << 0) > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 9:14 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>
>On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Added Platform specific colorspace enums and called the property
>> creation helper using the same.
>>
>> v6: Addressed Shashank's review comments.
>>
>> v7: Rebase
>>
>> v8: Addressed Maarten's review comments.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> drivers/gpu/drm/i915/intel_connector.c | 63
>++
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
>> 4 files changed, 89 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..76b7114 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>> */
>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> +new_state->colorspace != old_state->colorspace ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..9a12d5e 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -30,6 +30,48 @@
>> #include "intel_drv.h"
>> #include "i915_drv.h"
>>
>> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_X
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plus the
> back porch and the sync length. This doesn't make any difference on the
> only panel it has been tested with so far, since in that particular case
> the front porch is equal to the sum of the back porch and sync length.
>
> This is not the case for all panels, obviously, so we need to fix it. Since
> the Allwinner code has a bunch of extra code to deal with out of bounds
> values, so let's add them as well.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 380fc527a707..e3e4ba90c059 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
> + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
> +
> + if (!delay)
> + delay = 1;
For increased clarity, you might want to change this last block to:
delay = max(delay, 1);
Cheers,
Paul
> + return delay;
> }
>
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>-Original Message- >From: Daniel Stone [mailto:dan...@fooishbar.org] >Sent: Tuesday, January 29, 2019 9:24 PM >To: Brian Starkey >Cc: Shankar, Uma ; Syrjala, Ville >; intel-...@lists.freedesktop.org; dri- >de...@lists.freedesktop.org; nd ; Lankhorst, Maarten > >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property > >Hi, > >On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: >> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: >> > >> +#define DP_COLORIMETRY_SCRGB 15 >> > >> +#define DP_COLORIMETRY_DCI_P3 16 >> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 >> >> Sorry, I somehow missed your reply earlier in the month - but this >> wasn't what I meant. >> >> The expectation with enum properties is that the numeric values are >> determined at runtime - userspace shouldn't depend on them being known >> at compile-time. So, in include/uapi there shouldn't be these numeric >> values. >> >> The strings themselves effectively form the UABI, so I was wondering >> if they should be defined in include/uapi, but you would be the first >> to do that. >> >> Daniel Vetter and/or Daniel Stone might have opinions on this. > >That's correct. The DPMS definitions are a historical aberration, and we should >not be adding any more numeric definitions of enum properties to uABI. > >They can be fixed in the kernel, but userspace must only rely on the strings. Ok so if I understand correctly, we should drop the changes in uapi header for macro definitions and let the userspace match string which are supported in enum as part of property creation. So this info is redundant and not to be relied upon. Regards, Uma Shankar >Cheers, >Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, January 29, 2019 9:14 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
> >; Lankhorst, Maarten ;
> >dri-devel@lists.freedesktop.org
> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
> >
> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> >> This patch attaches the colorspace connector property to the hdmi
> >> connector. Based on colorspace change, modeset will be triggered to
> >> switch to new colorspace.
> >>
> >> Based on colorspace property value create an infoframe with
> >> appropriate colorspace. This can be used to send an infoframe packet
> >> with proper colorspace value set which will help to enable wider color
> >> gamut like BT2020 on sink.
> >>
> >> This patch attaches and enables HDMI colorspace, DP will be taken care
> >> separately.
> >>
> >> v2: Merged the changes of creating infoframe as well to this patch as
> >> per Maarten's suggestion.
> >>
> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
> >> colorspaces as suggested by Ville and Maarten.
> >>
> >> v4: Addressed Chris and Ville's review comments, and created a common
> >> colorspace property for DP and HDMI, filtered the list based on the
> >> colorspaces supported by the respective protocol standard. Handle the
> >> default case properly.
> >>
> >> v5: Added Platform specific colorspace enums and called the property
> >> creation helper using the same.
> >>
> >> v6: Addressed Shashank's review comments.
> >>
> >> v7: Rebase
> >>
> >> v8: Addressed Maarten's review comments.
> >>
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> >> drivers/gpu/drm/i915/intel_connector.c | 63
> >++
> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
> >> 4 files changed, 89 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 16263ad..76b7114 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> >drm_connector *conn,
> >> */
> >>if (new_conn_state->force_audio != old_conn_state->force_audio ||
> >>new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
> >> ||
> >> + new_state->colorspace != old_state->colorspace ||
> >>new_conn_state->base.picture_aspect_ratio != old_conn_state-
> >>base.picture_aspect_ratio ||
> >>new_conn_state->base.content_type != old_conn_state-
> >>base.content_type ||
> >>new_conn_state->base.scaling_mode !=
> >> old_conn_state->base.scaling_mode)
> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> >> b/drivers/gpu/drm/i915/intel_connector.c
> >> index ee16758..9a12d5e 100644
> >> --- a/drivers/gpu/drm/i915/intel_connector.c
> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
> >> @@ -30,6 +30,48 @@
> >> #include "intel_drv.h"
> >> #include "i915_drv.h"
> >>
> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> >> + /* For Default case, driver will set the colorspace */
> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
> >> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> >> + /* Colorimetry based on IEC 61966-2-5 */
> >> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
> >> +
> >> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
> >> + /* For Default case, driver will set the colorspace */
> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> +
[PATCH] drm/TODO: Add vrefresh replacement to the todo
From: Sean Paul Suggested-by: Daniel Vetter Signed-off-by: Sean Paul --- Documentation/gpu/todo.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede12215..7fc30380eaf6c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() + + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Contact: Sean Paul + Core refactorings = -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108889] [CI][SHARDS] igt@sw_sync@sync_busy_fork_unixsocket - incomplete - __igt_fork_helper: Assertion `!proc->running' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_186/fi-hsw-peppy/igt@sw_sync@sync_busy_fork_unixsocket.html
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only
On Tue, Jan 29, 2019 at 04:20:00PM +0200, Joonas Lahtinen wrote: > Quoting Jerome Glisse (2019-01-24 17:30:32) > > On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote: > > > Hi Jerome, > > > > > > This patch seems to have plenty of Cc:s, but none of the right ones :) > > > > So sorry, i am bad with git commands. > > > > > For further iterations, I guess you could use git option --cc to make > > > sure everyone gets the whole series, and still keep the Cc:s in the > > > patches themselves relevant to subsystems. > > > > Will do. > > > > > This doesn't seem to be on top of drm-tip, but on top of your previous > > > patches(?) that I had some comments about. Could you take a moment to > > > first address the couple of question I had, before proceeding to discuss > > > what is built on top of that base. > > > > It is on top of Linus tree so roughly ~ rc3 it does not depend on any > > of the previous patch i posted. > > You actually managed to race a point in time just when Chris rewrote much > of the userptr code in drm-tip, which I didn't remember of. My bad. > > Still interested to hearing replies to my questions in the previous > thread, if the series is still relevant. Trying to get my head around > how the different aspects of HMM pan out for devices without fault handling. HMM mirror does not need page fault handling for everything and in fact for user ptr you can use HMM mirror without page fault support in hardware. Page fault requirement is more like a __very__ nice to have feature. So sorry i missed that mail i must had it in a middle of bugzilla spam and deleted it. So here is a paste of it and answer. This was for a patch to convert i915 to use HMM mirror instead of having i915 does it own thing with GUP (get_user_page). > Bit late reply, but here goes :) > > We're working quite hard to avoid pinning any pages unless they're in > the GPU page tables. And when they are in the GPU page tables, they must > be pinned for whole of that duration, for the reason that our GPUs can > not take a fault. And to avoid thrashing GPU page tables, we do leave > objects in page tables with the expectation that smart userspace > recycles buffers. You do not need to pin the page because you obey to mmu notifier ie it is perfectly fine for you to keep the page map into the GPU until you get an mmu notifier call back for the range of virtual address. The pin from GUP in fact does not protect you from anything. GUP is really misleading, by the time GUP return the page you get might not correspond to the memory backing the virtual address. In i915 code this is not an issue because you synchronize against mmu notifier call back. So my intention in converting GPU driver from GUP to HMM mirror is just to avoid the useless page pin. As long as you obey the mmu notifier call back (or HMM sync page table call back) then you are fine. > So what I understand of your proposal, it wouldn't really make a > difference for us in the amount of pinned pages (which I agree, > we'd love to see going down). When we're unable to take a fault, > the first use effectively forces us to pin any pages and keep them > pinned to avoid thrashing GPU page tables. With HMM there is no pin, we never pin the page ie we never increment the refcount on the page as it is useless to do so if you abide by mmu notifier. Again the pin GUP take is misleading it does not block mm event. However Without pin and still abiding to mmu notifier you will not see any difference in thrashing ie number of time you will get a mmu notifier call back. As really those call back happens for good reasons. For instance running out of memory and kernel trying to reclaim or because userspace did a syscall that affect the range of virtual address. This should not happen in regular workload and when they happen the pin from GUP will not inhibit those either. In the end you will get the exact same amount of trashing but you will inhibit thing like memory compaction or migration while HMM does not block those (ie HMM is a good citizen ;) while GUP user are not). Also we are in the process of changing GUP and GUP will now have more profound impact to filesystem and mm (inhibiting and breaking some of the filesystem behavior). Converting GPU driver to HMM will avoid those adverse impact and it is one of the motivation behind my crusade to convert all GUP user that abide by mmu notifier to use HMM instead. > So from i915 perspective, it just seems to be mostly an exchange of > an API to an another for getting the pages. You already mentioned > the fast path is being worked on, which is an obvious difference. > But is there some other improvement one would be expecting, beyond > the page pinning? So for HMM i have a bunch of further optimization and new feature. Using HMM would make it easier for i915 to leverage those. > Also, is the requirement for a single non-file-backed VMA in the > plans of being eliminated or is that inherent restriction of th
RE: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 9:34 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>
>On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> >Behalf Of Ville Syrjälä
>> >Sent: Tuesday, January 29, 2019 9:14 PM
>> >To: Shankar, Uma
>> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
>> >Syrjala, Ville ; Lankhorst, Maarten
>> >; dri-devel@lists.freedesktop.org
>> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable
>> >modeset
>> >
>> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
>> >> This patch attaches the colorspace connector property to the hdmi
>> >> connector. Based on colorspace change, modeset will be triggered to
>> >> switch to new colorspace.
>> >>
>> >> Based on colorspace property value create an infoframe with
>> >> appropriate colorspace. This can be used to send an infoframe
>> >> packet with proper colorspace value set which will help to enable
>> >> wider color gamut like BT2020 on sink.
>> >>
>> >> This patch attaches and enables HDMI colorspace, DP will be taken
>> >> care separately.
>> >>
>> >> v2: Merged the changes of creating infoframe as well to this patch
>> >> as per Maarten's suggestion.
>> >>
>> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> >> colorspaces as suggested by Ville and Maarten.
>> >>
>> >> v4: Addressed Chris and Ville's review comments, and created a
>> >> common colorspace property for DP and HDMI, filtered the list based
>> >> on the colorspaces supported by the respective protocol standard.
>> >> Handle the default case properly.
>> >>
>> >> v5: Added Platform specific colorspace enums and called the
>> >> property creation helper using the same.
>> >>
>> >> v6: Addressed Shashank's review comments.
>> >>
>> >> v7: Rebase
>> >>
>> >> v8: Addressed Maarten's review comments.
>> >>
>> >> Signed-off-by: Uma Shankar
>> >> Reviewed-by: Shashank Sharma
>> >> ---
>> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> >> drivers/gpu/drm/i915/intel_connector.c | 63
>> >++
>> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
>> >> 4 files changed, 89 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> >> b/drivers/gpu/drm/i915/intel_atomic.c
>> >> index 16263ad..76b7114 100644
>> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>> >drm_connector *conn,
>> >>*/
>> >> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> >> new_conn_state->broadcast_rgb !=
>> >> old_conn_state->broadcast_rgb
>> >> ||
>> >> + new_state->colorspace != old_state->colorspace ||
>> >> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>> >>base.picture_aspect_ratio ||
>> >> new_conn_state->base.content_type != old_conn_state-
>> >>base.content_type ||
>> >> new_conn_state->base.scaling_mode !=
>> >> old_conn_state->base.scaling_mode)
>> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> >> b/drivers/gpu/drm/i915/intel_connector.c
>> >> index ee16758..9a12d5e 100644
>> >> --- a/drivers/gpu/drm/i915/intel_connector.c
>> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> >> @@ -30,6 +30,48 @@
>> >> #include "intel_drv.h"
>> >> #include "i915_drv.h"
>> >>
>> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> >> + /* For Default case, driver will set the colorspace */
>> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> >> + /* Standard Definition Colorimetry based on CEA 861 */
>> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
>> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
>> >> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>> >> + /* Colorimetry based on IEC 61966-2-5 */
>> >> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> >> + /* Colorimetry based on ITU-R BT.2020 */
>> >> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> >> + /* Colorimetry based on ITU-R BT.2020 */
>> >> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> >> + /* Colorimetry based on ITU
Re: [PATCH] drm/TODO: Add vrefresh replacement to the todo
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote: > From: Sean Paul > > Suggested-by: Daniel Vetter > Signed-off-by: Sean Paul Reviewed-by: Sam Ravnborg > --- > Documentation/gpu/todo.rst | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede12215..7fc30380eaf6c 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() > + > + > +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it > +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core > +has helper which will use mode.vrefresh if it's !0 and will calculate it from > +the timings when it's 0. > + > +Use simple search/replace, or (more fun) cocci to replace instances of direct > +vrefresh access with a call to the helper. Check out > +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for > +inspiration. Bonus points for the link! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109487] drm-next-5.1-wip broken as of 672c6238
https://bugs.freedesktop.org/show_bug.cgi?id=109487 --- Comment #6 from asavah --- Yes, indeed reverting https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a seems to fix the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/TODO: Add vrefresh replacement to the todo
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote: > From: Sean Paul > > Suggested-by: Daniel Vetter > Signed-off-by: Sean Paul > --- > Documentation/gpu/todo.rst | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede12215..7fc30380eaf6c 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() > + > + > +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it > +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core > +has helper which will use mode.vrefresh if it's !0 and will calculate it from > +the timings when it's 0. > + > +Use simple search/replace, or (more fun) cocci to replace instances of direct > +vrefresh access with a call to the helper. Check out > +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for > +inspiration. I would suggest just nuking mode.vrefresh entirely because we don't want to risk drm_mode_vrefresh() returning some stale value. > + > +Contact: Sean Paul > + > Core refactorings > = > > -- > Sean Paul, Software Engineer, Google / Chromium OS > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 9:34 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
> >; Lankhorst, Maarten ;
> >dri-devel@lists.freedesktop.org
> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
> >
> >On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> >Behalf Of Ville Syrjälä
> >> >Sent: Tuesday, January 29, 2019 9:14 PM
> >> >To: Shankar, Uma
> >> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
> >> >Syrjala, Ville ; Lankhorst, Maarten
> >> >; dri-devel@lists.freedesktop.org
> >> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable
> >> >modeset
> >> >
> >> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> >> >> This patch attaches the colorspace connector property to the hdmi
> >> >> connector. Based on colorspace change, modeset will be triggered to
> >> >> switch to new colorspace.
> >> >>
> >> >> Based on colorspace property value create an infoframe with
> >> >> appropriate colorspace. This can be used to send an infoframe
> >> >> packet with proper colorspace value set which will help to enable
> >> >> wider color gamut like BT2020 on sink.
> >> >>
> >> >> This patch attaches and enables HDMI colorspace, DP will be taken
> >> >> care separately.
> >> >>
> >> >> v2: Merged the changes of creating infoframe as well to this patch
> >> >> as per Maarten's suggestion.
> >> >>
> >> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
> >> >> colorspaces as suggested by Ville and Maarten.
> >> >>
> >> >> v4: Addressed Chris and Ville's review comments, and created a
> >> >> common colorspace property for DP and HDMI, filtered the list based
> >> >> on the colorspaces supported by the respective protocol standard.
> >> >> Handle the default case properly.
> >> >>
> >> >> v5: Added Platform specific colorspace enums and called the
> >> >> property creation helper using the same.
> >> >>
> >> >> v6: Addressed Shashank's review comments.
> >> >>
> >> >> v7: Rebase
> >> >>
> >> >> v8: Addressed Maarten's review comments.
> >> >>
> >> >> Signed-off-by: Uma Shankar
> >> >> Reviewed-by: Shashank Sharma
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> >> >> drivers/gpu/drm/i915/intel_connector.c | 63
> >> >++
> >> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
> >> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
> >> >> 4 files changed, 89 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> >> index 16263ad..76b7114 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> >> >drm_connector *conn,
> >> >> */
> >> >> if (new_conn_state->force_audio != old_conn_state->force_audio
> >> >> ||
> >> >> new_conn_state->broadcast_rgb !=
> >> >> old_conn_state->broadcast_rgb
> >> >> ||
> >> >> + new_state->colorspace != old_state->colorspace ||
> >> >> new_conn_state->base.picture_aspect_ratio != old_conn_state-
> >> >>base.picture_aspect_ratio ||
> >> >> new_conn_state->base.content_type != old_conn_state-
> >> >>base.content_type ||
> >> >> new_conn_state->base.scaling_mode !=
> >> >> old_conn_state->base.scaling_mode)
> >> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> >> >> b/drivers/gpu/drm/i915/intel_connector.c
> >> >> index ee16758..9a12d5e 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_connector.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
> >> >> @@ -30,6 +30,48 @@
> >> >> #include "intel_drv.h"
> >> >> #include "i915_drv.h"
> >> >>
> >> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> >> >> + /* For Default case, driver will set the colorspace */
> >> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> >> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> >> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> >> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> >> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> >> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> >> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
> >
Re: [PATCH v2] drm: add definitions for DP Audio/Video compliance tests
On Tue, Jan 29, 2019 at 10:55:47AM -0500, Sean Paul wrote: > On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote: > > This change adds definitions needed for DP audio compliance testing. > > It also adds missing definition for DP video compliance. > > > > Changes in V2: > > -- Delete cover letter for this patch. > > -- Move the description from cover letter into patch commit message. > > -- Remove DPU from subject prefix > > > > Signed-off-by: Chandan Uddaraju > > Reviewed-by: Sean Paul > > If no one has any objections, it'd be nice to apply this through msm tree > along > with the dpu code that makes use of it. Acked-by: Daniel Vetter for merging through -msm. -Daniel > > Sean > > > > --- > > include/drm/drm_dp_helper.h | 13 + > > 1 file changed, 13 insertions(+) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index 5736c94..e688e05 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -556,6 +556,8 @@ > > # define DP_TEST_LINK_EDID_READ(1 << 2) > > # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */ > > # define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */ > > +# define DP_TEST_LINK_AUDIO_PATTERN (1 << 5) /* DPCD >= 1.2 */ > > +# define DP_TEST_LINK_AUDIO_DISABLED_VIDEO (1 << 6) /* DPCD >= 1.2 */ > > > > #define DP_TEST_LINK_RATE 0x219 > > # define DP_LINK_RATE_162 (0x6) > > @@ -604,6 +606,7 @@ > > # define DP_COLOR_FORMAT_RGB(0 << 1) > > # define DP_COLOR_FORMAT_YCbCr422 (1 << 1) > > # define DP_COLOR_FORMAT_YCbCr444 (2 << 1) > > +# define DP_TEST_DYNAMIC_RANGE_VESA (0 << 3) > > # define DP_TEST_DYNAMIC_RANGE_CEA (1 << 3) > > # define DP_TEST_YCBCR_COEFFICIENTS (1 << 4) > > # define DP_YCBCR_COEFFICIENTS_ITU601 (0 << 4) > > @@ -653,6 +656,16 @@ > > > > #define DP_TEST_SINK 0x270 > > # define DP_TEST_SINK_START(1 << 0) > > +#define DP_TEST_AUDIO_MODE 0x271 > > +#define DP_TEST_AUDIO_PATTERN_TYPE 0x272 > > +#define DP_TEST_AUDIO_PERIOD_CH1 0x273 > > +#define DP_TEST_AUDIO_PERIOD_CH2 0x274 > > +#define DP_TEST_AUDIO_PERIOD_CH3 0x275 > > +#define DP_TEST_AUDIO_PERIOD_CH4 0x276 > > +#define DP_TEST_AUDIO_PERIOD_CH5 0x277 > > +#define DP_TEST_AUDIO_PERIOD_CH6 0x278 > > +#define DP_TEST_AUDIO_PERIOD_CH7 0x279 > > +#define DP_TEST_AUDIO_PERIOD_CH8 0x27A > > > > #define DP_FEC_STATUS 0x280/* 1.4 */ > > # define DP_FEC_DECODE_EN_DETECTED (1 << 0) > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > > a Linux Foundation Collaborative Project > > > > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/TODO: Add vrefresh replacement to the todo
From: Sean Paul Changes in v2: - Add drm_display_mode.vrefresh removal (Ville) - Add Sam's R-b and bonus points Cc: Ville Syrjälä Suggested-by: Daniel Vetter Reviewed-by: Sam Ravnborg Bonus-points-awarded-by: Sam Ravnborg Signed-off-by: Sean Paul --- Documentation/gpu/todo.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede12215..1bbfc5e1b2a46 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,24 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() + + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Once all instances of vrefresh have been converted, consider removing vrefresh +from drm_display_mode to avoid future use. + +Contact: Sean Paul + Core refactorings = -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: add binding for Innolux ee101ia-01d panel
On Tue, Jan 29, 2019 at 02:37:23PM +0100, Heiko Stübner wrote: > Hi Thierry, > > Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner: > > From: Heiko Stuebner > > > > This is a panel handled through the generic lvds-panel binding, > > so only needs its additional compatible specified. > > > > Signed-off-by: Heiko Stuebner > > just pulling this pending patch out of the woodworks again too :-) > > Thanks in advance for considering it. It's a panel patch, you have the review from Rob, you have commit rights to drm-misc and panel is maintained in drm-misc. There's nothing blocking you from pushing it, just do it :-) Cheers, Daniel > Heiko > > > --- > > .../bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++ > > 1 file changed, 7 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > new file mode 100644 > > index ..e5ca4ccd55ed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > @@ -0,0 +1,7 @@ > > +Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel > > + > > +Required properties: > > +- compatible: should be "innolux,ee101ia-01d" > > + > > +This binding is compatible with the lvds-panel binding, which is specified > > +in panel-lvds.txt in this directory. > > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
