Re: [PATCH] gpu/drm/hisilicon: Convert drm_atomic_helper_suspend/resume()
On Mon, Aug 6, 2018 at 8:16 PM Souptick Joarder wrote:
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> Fixed one sparse warning by making hibmc_drm_interrupt
> static.
>
> Signed-off-by: Ajit Negi
> Signed-off-by: Souptick Joarder
> Reviewed-by: Xinliang Liu
Can we get this patch in queue for 4.20 ??
> ---
> v2: remove ret variable from both suspend and resume.
> remove suspend_state from hibmc_drm_private struct.
>
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 20 +++-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
> 2 files changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index d4f6f1f..ee24480 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -37,7 +37,7 @@
> .llseek = no_llseek,
> };
>
> -irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
> +static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
> {
> struct drm_device *dev = (struct drm_device *)arg;
> struct hibmc_drm_private *priv =
> @@ -74,30 +74,16 @@ static int __maybe_unused hibmc_pm_suspend(struct device
> *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - struct hibmc_drm_private *priv = drm_dev->dev_private;
> -
> - drm_kms_helper_poll_disable(drm_dev);
> - priv->suspend_state = drm_atomic_helper_suspend(drm_dev);
> - if (IS_ERR(priv->suspend_state)) {
> - DRM_ERROR("drm_atomic_helper_suspend failed: %ld\n",
> - PTR_ERR(priv->suspend_state));
> - drm_kms_helper_poll_enable(drm_dev);
> - return PTR_ERR(priv->suspend_state);
> - }
>
> - return 0;
> + return drm_mode_config_helper_suspend(drm_dev);
> }
>
> static int __maybe_unused hibmc_pm_resume(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - struct hibmc_drm_private *priv = drm_dev->dev_private;
>
> - drm_atomic_helper_resume(drm_dev, priv->suspend_state);
> - drm_kms_helper_poll_enable(drm_dev);
> -
> - return 0;
> + return drm_mode_config_helper_resume(drm_dev);
> }
>
> static const struct dev_pm_ops hibmc_pm_ops = {
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index e195521..45c25a4 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -47,7 +47,6 @@ struct hibmc_drm_private {
> /* drm */
> struct drm_device *dev;
> bool mode_config_initialized;
> - struct drm_atomic_state *suspend_state;
>
> /* ttm */
> struct drm_global_reference mem_global_ref;
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 regression fix 1/2] staging: vboxvideo: Fix IRQs no longer working
On Tue, Sep 11, 2018 at 08:53:35AM +0200, Hans de Goede wrote:
> Hi,
>
> On 11-09-18 08:48, Nicholas Mc Guire wrote:
> >On Mon, Sep 10, 2018 at 08:30:38PM +0200, Hans de Goede wrote:
> >>Commit 1daddbc8dec5 ("staging: vboxvideo: Update driver to use
> >>drm_dev_register.") replaced the obsolere drm_get_pci_dev() with
> >>normal pci probe and remove functions.
> >>
> >>But the new vbox_pci_probe() is missing a pci_enable_device() call,
> >>causing interrupts to not be delivered. This causes resizes of the
> >>vm window to not get seen by the drm/kms code.
> >>
> >>This commit adds the missing pci_enable_device() call, fixing this.
> >
> >pci_enable_device is the wrapper to pci_enable_device_flags() the later
> >return < 0 on error - so while the check for if(ret) will do the right
> >think here I think it would be prefereable to explicidly use if (ret < 0)
> >as all error values pci_enable_device_flags() returns are negative.
>
> The use of "if (ret)" checks for functions which return 0 on success
> negative value on error is a standard pattern in the kernel, so I would
> prefer to keep this as is.
>
Well as noted it does the right thing - just checking the use of
pci_enable_device() in the existing drivers it seems that it is roughly
balanced between checking < 0 and !0. The rational for < 0 would be that
the negative return values mandate a signed type, whilc !0 does not and
if someone then uses and unsigned type the error case would return as
success while the < 0 would be detected at compile time (or other static
code checkers).
thx!
hofrat
> >>Fixes: 1daddbc8dec5 ("staging: vboxvideo: Update driver to use ...")
> >>Cc: Fabio Rafael da Rosa
> >>Cc: Nicholas Mc Guire
> >>Signed-off-by: Hans de Goede
> >Reviewed-by: Nicholas Mc Guire
>
> Thanks.
>
> Regards,
>
> Hans
>
>
> >
> >>---
> >> drivers/staging/vboxvideo/vbox_drv.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >>diff --git a/drivers/staging/vboxvideo/vbox_drv.c
> >>b/drivers/staging/vboxvideo/vbox_drv.c
> >>index da92c493f157..69cc508af1bc 100644
> >>--- a/drivers/staging/vboxvideo/vbox_drv.c
> >>+++ b/drivers/staging/vboxvideo/vbox_drv.c
> >>@@ -59,6 +59,11 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> >>struct pci_device_id *ent)
> >>ret = PTR_ERR(dev);
> >>goto err_drv_alloc;
> >>}
> >>+
> >>+ ret = pci_enable_device(pdev);
> >>+ if (ret)
> >>+ goto err_pci_enable;
> >>+
> >>dev->pdev = pdev;
> >>pci_set_drvdata(pdev, dev);
> >>@@ -75,6 +80,8 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> >>struct pci_device_id *ent)
> >> err_drv_dev_register:
> >>vbox_driver_unload(dev);
> >> err_vbox_driver_load:
> >>+ pci_disable_device(pdev);
> >>+ err_pci_enable:
> >>drm_dev_put(dev);
> >> err_drv_alloc:
> >>return ret;
> >>--
> >>2.19.0.rc0
> >>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/fb-helper: Remove set but not used variable 'connector_funcs'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/drm_fb_helper.c: In function 'drm_pick_crtcs':
drivers/gpu/drm/drm_fb_helper.c:2373:43: warning:
variable 'connector_funcs' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/gpu/drm/drm_fb_helper.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 73cf10a..16e3a59 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2370,7 +2370,6 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
{
int c, o;
struct drm_connector *connector;
- const struct drm_connector_helper_funcs *connector_funcs;
int my_score, best_score, score;
struct drm_fb_helper_crtc **crtcs, *crtc;
struct drm_fb_helper_connector *fb_helper_conn;
@@ -2399,8 +2398,6 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (drm_has_preferred_mode(fb_helper_conn, width, height))
my_score++;
- connector_funcs = connector->helper_private;
-
/*
* select a crtc for this connector and then attempt to configure
* remaining connectors
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/omap: remove set but not used variable 'frame_height'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/dss/dispc.c: In function 'dispc_ovl_setup_common':
drivers/gpu/drm/omapdrm/dss/dispc.c:2627:19: warning:
variable 'frame_height' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index e61a959..7c23f23 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2624,7 +2624,7 @@ static int dispc_ovl_setup_common(struct dispc_device
*dispc,
unsigned int offset0, offset1;
s32 row_inc;
s32 pix_inc;
- u16 frame_width, frame_height;
+ u16 frame_width;
unsigned int field_offset = 0;
u16 in_height = height;
u16 in_width = width;
@@ -2714,13 +2714,10 @@ static int dispc_ovl_setup_common(struct dispc_device
*dispc,
row_inc = 0;
pix_inc = 0;
- if (plane == OMAP_DSS_WB) {
+ if (plane == OMAP_DSS_WB)
frame_width = out_width;
- frame_height = out_height;
- } else {
+ else
frame_width = in_width;
- frame_height = height;
- }
calc_offset(screen_width, frame_width,
fourcc, fieldmode, field_offset,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qxl: refactor to use drm_fb_helper_fbdev_setup
On Mon, Sep 10, 2018 at 03:21:56PM +0200, Peter Wu wrote: > Lots of code can be removed by relying on fb-helper: > - "struct drm_framebuffer" moves to fb_helper.fb. > - "struct drm_gem_object" moves to fb_helper.obj[0]. > - "struct qxl_device" can be inferred as drm_fb_helper is embedded. > - qxl_user_framebuffer_create -> drm_gem_fb_create. > - qxl_user_framebuffer_destroy -> drm_gem_fb_destroy. > - qxl_fbdev_destroy -> drm_fb_helper_fbdev_teardown + vfree(shadow). > > Remove unused code: > - qxl_fbdev_qobj_is_fb, qxl_fbdev_set_suspend. > - Unused fields of qxl_fbdev: delayed_ops, delayed_ops_lock, size. > > Misc notes: > - The dirty callback is preserved as it is necessary to trigger update > commands in the hw (the screen stays black otherwise). > - No idea when .create_handle in drm_framebuffer_funcs is used, but use > the same drm_gem_fb_create_handle to match drm_gem_fb_funcs. > - I don't know why qxl_fb_find_or_create_single used to check for an > existing framebuffer and removed that check to match other drivers. > - Use of drm_fb_helper_fbdev_teardown also requires "info->fbdefio" to > be dynamically allocated. Replace the existing defio config by > drm_fb_helper_defio_init to accomodate this. > > Testing results: startx with fbdev, modesetting and qxl all seems to > work. Tested also with CONFIG_DRM_FBDEV_EMULATION=n, fbdev obviously > fails but others are fine. QEMU -spice and QEMU -spice with vdagent and > multiple (resized) displays (via remote-viewer) also works. > unbind vtconsole and rmmod has *not* regressed (i.e. it still trips on a > use-after-free in qxl_check_idle via qxl_ttm_fini). > > Ideally setup/teardown is replaced by drm_fbdev_generic_setup as that > would result in further code reduction, improve error handling (like not > leaking shadow memory), but unfortunately QXL has no implementation for > qxl_gem_prime_vmap. Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
i915, HDMI/DP audio with multiple monitors
Hi, I have a system with multiple monitors and would like to send notification sounds to the monitor on which corresponding window is visible. For a workstation and a tiny computer things look different: - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04) Here alsa show me two cards: - HDA Intel PCH (Realtek ALC671) - HDA Intel HDMI (Intel Generic) List of PLAYBACK Hardware Devices card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) Here alsa shows a single card: - HDA Intel PCH (Realtek ALC671) List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 How can I determine/set to which monitor the sound should go, and preferably send different sounds to both monitors at same time? Cheers, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: Use ERR_CAST directly instead of RR_PTR(PTR_ERR())
We prefer to use ERR_CAST to do so.
The issue is detected with the help of Coccinelle.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/drm/omapdrm/dss/dss.c
index cb80dda..1fc46b2 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -956,7 +956,7 @@ struct dss_debugfs_entry *
&dss_debug_fops);
if (IS_ERR(d)) {
kfree(entry);
- return ERR_PTR(PTR_ERR(d));
+ return ERR_CAST(d);
}
entry->dentry = d;
--
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] i915 HDMI connector status is connected after disconnection
On Fri, Aug 24, 2018 at 11:04 PM, Jani Nikula wrote: > On Wed, 22 Aug 2018, Chris Chiu wrote: >> On Fri, Jul 6, 2018 at 2:44 PM, Chris Chiu wrote: >>> On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä >>> wrote: On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote: > Hi, > We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel > i5-8250U), X530UN (intel i7-8550U) share the same problem, which is > the HDMI connector status stays connected even the HDMI cable has been > unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for > checking the status while plug/unplug the HDMI, it shows > "disconnected" before plug in HDMI cable, then switch to "connected" > after plugin, and still stay "connected" after unplug. This would > cause the audio output path cannot correctly switch from HDMI to > internal speaker after unplugging the HDMI. > > I then try to verify with the latest kernel 4.18.0-rc3+, the bug still > present. The full "dmesg" log is here. > https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 > > The HDMI cable is plugged in at ~26th second. > "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic > audio support" > then unplug the HDMI at ~73th second. > "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic > audio support" > > Please advise what I can do to fix this. Thanks Pull the cable out faster? I presume this is the same old case of hpd disconnecting slightly before ddc and we still manage to read the EDID when processing the hpd irq. We kinda tried to fix that with the live status check but that thing failed spectacularly. -- Ville Syrjälä Intel >> >> There's a patch https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8. >> And I verified on the X705FD/X560UD which were easy to reproduce, the patch >> works as expected. Can anyone kindly give comments about this patch? >> We can do anything to help fix this issue upstream. Thanks > > Seems like a hack. Should look into hw based debouncing or a slight > delay in the hotplug work processing I think. > > BR, > Jani. > So you're suggesting to add a slight delay directly in i915_hotplug_work_func()? And any suggestion about the 'hw based' debouncing? Maybe some examples that I can refer to? Thanks >> >> Chris >> >>> Thanks for the suggestion. I tried pulling the cable out faster, the status >>> shows correctly. I also tried branch drm-tip of >>> https://cgit.freedesktop.org/drm/drm-tip >>> but the symptom persists. >>> >>> Anything I can help here? Or any old commit/patch I can try to do some >>> experiments? >>> >>> Chris > > -- > Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/13] udmabuf: add documentation
On 9/11/18 6:42 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/linux/udmabuf.h | 50
> +---
> Documentation/driver-api/dma-buf.rst | 8 ++
> 2 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> index 46b6532ed8..f30b37cb5c 100644
> --- a/include/uapi/linux/udmabuf.h
> +++ b/include/uapi/linux/udmabuf.h
> @@ -5,8 +5,38 @@
> #include
> #include
>
> +/**
> + * DOC: udmabuf
> + *
> + * udmabuf is a device driver which allows userspace create dmabufs.
to create
> + * The memory used for these dmabufs must be backed by memfd. The
> + * memfd must have F_SEAL_SHRINK and it must not have F_SEAL_WRITE.
> + *
> + * The driver has two ioctls, one to create a dmabuf from a single
> + * memory block and one to create a dmabuf from a list of memory
> + * blocks.
> + *
> + * UDMABUF_CREATE - _IOW('u', 0x42, udmabuf_create)
> + *
> + * UDMABUF_CREATE_LIST - _IOW('u', 0x43, udmabuf_create_list)
> + */
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
> +
> #define UDMABUF_FLAGS_CLOEXEC0x01
>
> +/**
> + * struct udmabuf_create - create a dmabuf from a single memory block.
> + *
> + * @memfd: The file handle.
> + * @offset: Start of the buffer (from memfd start).
> + * Must be page aligned.
> + * @size: Size of the buffer. Must be rounded to page size.
@flags: ???
> + *
> + * flags:
> + * UDMABUF_FLAGS_CLOEXEC: set CLOEXEC flag for the dmabuf.
> + */
> struct udmabuf_create {
> __u32 memfd;
> __u32 flags;
> @@ -14,6 +44,14 @@ struct udmabuf_create {
> __u64 size;
> };
>
> +/**
> + * struct udmabuf_create_item - one memory block list item.
> + *
> + * @memfd: The file handle.
> + * @offset: Start of the buffer (from memfd start).
> + * Must be page aligned.
> + * @size: Size of the buffer. Must be rounded to page size.
> + */
> struct udmabuf_create_item {
> __u32 memfd;
> __u32 __pad;
> @@ -21,13 +59,19 @@ struct udmabuf_create_item {
> __u64 size;
> };
>
> +/**
> + * struct udmabuf_create_list - create a dmabuf from a memory block list.
> + *
> + * @count: The number of list elements.
> + * @list: The memory block list
> + *
> + * flags:
@flags:
> + * UDMABUF_FLAGS_CLOEXEC: set CLOEXEC flag for the dmabuf.
> + */
> struct udmabuf_create_list {
> __u32 flags;
> __u32 count;
> struct udmabuf_create_item list[];
> };
thanks.
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
Hi,
Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit :
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> Acked-by: Daniel Vetter
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287
> ++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
>
> diff --git a/include/uapi/linux/udmabuf.h
> b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct
> udmabuf_create_list)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> +static long udmabuf_create(struct udmabuf_create_list *head,
> +struct udmabuf_create_item *list)
> +{
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct file *memfd = NULL;
> + struct udmabuf *ubuf;
> + struct dma_buf *buf;
> + pgoff_t pgoff, pgcnt, pgidx, pgbuf;
> + struct page *page;
> + int seals, ret = -EINVAL;
> + u32 i, flags;
> +
> + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
> + if (!ubuf)
> + return -ENOMEM;
> +
> + for (i = 0; i < head->count; i++) {
You need to check .__pad for unsupported value:
if (list[i].__pad) {
ret = -EINVAL;
goto err_free_ubuf;
}
> + if (!IS_ALIGNED(list[i].offset, PAGE_SIZE))
> + goto err_free_ubuf;
> + if (!IS_ALIGNED(list[i].size, PAGE_SIZE))
> + goto err_free_ubuf;
> + ubuf->pagecount += list[i].size >> PAGE_SHIFT;
> + }
> + ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(struct page
> *),
> + GFP_KERNEL);
> + if (!ubuf->pages) {
> + ret = -ENOMEM;
> + goto err_free_ubuf;
> + }
> +
> + pgbuf = 0;
> + for (i = 0; i < head->count; i++) {
> + memfd = fget(list[i].memfd);
> + if (!memfd)
> + goto err_put_pages;
> + if (!shmem_mapping(file_inode(memfd)->i_mapping))
> + goto err_put_pages;
> + seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
> + if (seals == -EINVAL ||
> + (seals & SEALS_WANTED) != SEALS_WANTED ||
> + (seals & SEALS_DENIED) != 0)
> + goto err_put_pages;
> + pgoff = list[i].offset >> PAGE_SHIFT;
> + pgcnt = list[i].size >> PAGE_SHIFT;
> + for (pgidx = 0; pgidx < pgcnt; pgidx++) {
> + page = shmem_read_mapping_page(
> + file_inode(memfd)->i_mapping, pgoff +
> pgidx);
> + if (IS_ERR(page)) {
> + ret = PTR_ERR(page);
> + goto err_put_pages;
> + }
> + ubuf->pages[pgbuf++] = page;
> + }
> +
Re: [PATCH 2/3] drm/exynos: scaler: Add support for tiled formats
Hi Inki,
W dniu 12.09.2018 o 01:54, Inki Dae pisze:
> Hi Marek and Andrzej,
>
> 2018년 08월 10일 22:29에 Marek Szyprowski 이(가) 쓴 글:
>> From: Andrzej Pietrasiewicz
>>
>> Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
>>
>>
>> -static u32 scaler_get_format(u32 drm_fmt)
>> +struct scaler_format {
>> +u32 drm_fmt;
>> +u32 internal_fmt;
>> +u32 chroma_tile_w;
>> +u32 chroma_tile_h;
>> +};
>> +
>> +static const struct scaler_format scaler_formats[] = {
>> +{ DRM_FORMAT_NV12, SCALER_YUV420_2P_UV, 8, 8 },
>> +{ DRM_FORMAT_NV21, SCALER_YUV420_2P_VU, 8, 8 },
>> +{ DRM_FORMAT_YUV420, SCALER_YUV420_3P, 8, 8 },
>> +{ DRM_FORMAT_YUYV, SCALER_YUV422_1P_YUYV, 16, 16 },
>> +{ DRM_FORMAT_UYVY, SCALER_YUV422_1P_UYVY, 16, 16 },
>> +{ DRM_FORMAT_YVYU, SCALER_YUV422_1P_YVYU, 16, 16 },
>> +{ DRM_FORMAT_NV16, SCALER_YUV422_2P_UV, 8, 16 },
>> +{ DRM_FORMAT_NV61, SCALER_YUV422_2P_VU, 8, 16 },
>> +{ DRM_FORMAT_YUV422, SCALER_YUV422_3P, 8, 16 },
>> +{ DRM_FORMAT_NV24, SCALER_YUV444_2P_UV, 16, 16 },
>> +{ DRM_FORMAT_NV42, SCALER_YUV444_2P_VU, 16, 16 },
>> +{ DRM_FORMAT_YUV444, SCALER_YUV444_3P, 16, 16 },
>> +{ DRM_FORMAT_RGB565, SCALER_RGB_565, 0, 0 },
>> +{ DRM_FORMAT_XRGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_ARGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_RGBX, SCALER_RGBA, 0, 0 },
>> +{ DRM_FORMAT_RGBA, SCALER_RGBA, 0, 0 },
>
> Seems the tile size of each format you declared above is wrong.
> According to data sheet for Exynos5420/5422/5433, each plane has different
> tile size.
> I.e., SACLE_YUV420_2P_UV/VU has two planes, and Y plane has 16 x 16 tile size
> but U and V plane have 8 x 8 tile size each other.
>
> However, above declaration has only one tile size
true, but the members of struct scaler_format are called
_chroma_tile_w/h
> and it means that each plane has always same tile size.
this conclusion is not justified
> And also RGB formats have 16 x 16 tile size in tile mode but you declared it
> as 0.
The data sheet says, that all formats have the same Y/RGB tile size
and it is always 16x16. That is why only chroma tile size is remembered,
because only chroma tile size can be different between formats.
RGB formats don't have any chroma component, hence zero chroma_tile_w/h.
Regards,
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 regression fix 1/2] staging: vboxvideo: Fix IRQs no longer working
On Tue, Sep 11, 2018 at 10:20:41AM +0300, Dan Carpenter wrote:
> On Tue, Sep 11, 2018 at 06:48:27AM +, Nicholas Mc Guire wrote:
> > On Mon, Sep 10, 2018 at 08:30:38PM +0200, Hans de Goede wrote:
> > > Commit 1daddbc8dec5 ("staging: vboxvideo: Update driver to use
> > > drm_dev_register.") replaced the obsolere drm_get_pci_dev() with
> > > normal pci probe and remove functions.
> > >
> > > But the new vbox_pci_probe() is missing a pci_enable_device() call,
> > > causing interrupts to not be delivered. This causes resizes of the
> > > vm window to not get seen by the drm/kms code.
> > >
> > > This commit adds the missing pci_enable_device() call, fixing this.
> >
> > pci_enable_device is the wrapper to pci_enable_device_flags() the later
> > return < 0 on error - so while the check for if(ret) will do the right
> > think here I think it would be prefereable to explicidly use if (ret < 0)
> > as all error values pci_enable_device_flags() returns are negative.
> >
>
> It could go either way, I think. "if (ret) " is sort of as explicit as
> "if (ret < 0) " when you consider the false side. When I see "if (ret)"
> then I know the code returns negative error codes and zero, but when I
> see "if (ret < 0)" then I think maybe this returns positive non-zero
> values as well.
>
> As a static analysis person, the "if (ret)" style is easier for me.
> Sometimes Smatch doesn't know what a function returns. Maybe the error
> code comes from a different thread and Smatch doesn't understand
> threads. So then when people use "if (ret)" Smatch knows that non-zero
> means *param1 is not initialized. Then the caller does "if (ret < 0)"
> that means that positive non-zero values are not handled so let's print
> an uninitialized variable warning. Just to spell it out a little more,
> the error code won't be printed for "if (ret)" because negatives are a
> subset of non-zero.
>
> Of course, if you do it consistently there won't be a warning message.
> I never see the consistent subsystems, so I don't know if they exist.
>
Probably true - there is quite a bit of incorrect type issues in the
kernel and there are a cases of comparing to e.g. <= 0 for signed
types is used, so I personally prefere if the check allows type
inference - if I see a "ret < 0" it can be infered that the type must
be signed and an unsigned is an error while for !0 case does not allow
such inference.
Anyway - as noted the patch seems correct with respect to the intent and
if the general preference is for "if (ret)" then no objections.
thanks for the clarification !
hofrat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Add kerneldoc entry
On Tue, Sep 11, 2018 at 08:06:31PM +0200, Daniel Vetter wrote: > On Fri, Sep 07, 2018 at 08:41:36PM +0300, Haneen Mohammed wrote: > > Add an initial kerneldoc entry for vkms with a todo list. > > > > Signed-off-by: Haneen Mohammed > > --- > > Documentation/gpu/drivers.rst | 1 + > > Documentation/gpu/todo.rst | 12 > > Documentation/gpu/vkms.rst | 21 + > > drivers/gpu/drm/vkms/vkms_drv.c | 9 + > > 4 files changed, 31 insertions(+), 12 deletions(-) > > create mode 100644 Documentation/gpu/vkms.rst > > > > diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst > > index 65be325bf282..7d2d3875ff1a 100644 > > --- a/Documentation/gpu/drivers.rst > > +++ b/Documentation/gpu/drivers.rst > > @@ -13,6 +13,7 @@ GPU Driver Documentation > > tve200 > > v3d > > vc4 > > + vkms > > bridge/dw-hdmi > > xen-front > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index a7c150d6b63f..f8dfa603e89f 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -398,18 +398,6 @@ the non-i915 specific modeset tests. > > > > Contact: Daniel Vetter > > > > -Create a virtual KMS driver for testing (vkms) > > --- > > - > > -With all the latest helpers it should be fairly simple to create a virtual > > KMS > > -driver useful for testing, or for running X or similar on headless machines > > -(to be able to still use the GPU). This would be similar to vgem, but > > aimed at > > -the modeset side. > > - > > -Once the basics are there there's tons of possibilities to extend it. > > - > > -Contact: Daniel Vetter > > I've changed this to instead point at the vkms todo list, so we still have > an entry for this here. And then applied your patch. > > Cursor patches also applied now, thanks. > > Aside: Do you have any plans to continue working on this, i.e. in need of > commit rights? > > Cheers, Daniel Thanks! I still have two patches I didn't submit (suspend/resume, and another that checks if work_struct is queued before calling flush_work()). I can volunteer to review future patches to vkms, but unfortunately I don't think I'd be at capacity to add new features to vkms anymore. Thank you so much for all your help! Haneen > > - > > Driver Specific > > === > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > new file mode 100644 > > index ..58bce5f4ec0a > > --- /dev/null > > +++ b/Documentation/gpu/vkms.rst > > @@ -0,0 +1,21 @@ > > +== > > + drm/vkms Virtual Kernel Modesetting > > +== > > + > > +.. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c > > + :doc: vkms (Virtual Kernel Modesetting) > > + > > +TODO > > + > > + > > +CRC API > > +--- > > + > > +- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` > > + > > +- Use the alpha value to blend vaddr_src with vaddr_dst instead of > > + overwriting it in ``blend()``. > > + > > +- Add igt test to check cleared alpha value for XRGB plane format. > > + > > +- Add igt test to check extreme alpha values i.e. fully opaque and fully > > transparent (intermediate values are affected by hw-specific rounding > > modes). > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > b/drivers/gpu/drm/vkms/vkms_drv.c > > index 7ce9a76fb940..73cd11845973 100644 > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > @@ -5,6 +5,15 @@ > > * (at your option) any later version. > > */ > > > > +/** > > + * DOC: vkms (Virtual Kernel Modesetting) > > + * > > + * vkms is a software-only model of a kms driver that is useful for > > testing, > > + * or for running X (or similar) on headless machines and be able to still > > + * use the GPU. vkms aims to enable a virtual display without the need for > > + * a hardware display capability. > > + */ > > + > > #include > > #include > > #include > > -- > > 2.17.1 > > > > -- > 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 v4] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()
On Thu, Aug 2, 2018 at 9:12 PM Souptick Joarder wrote:
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> exynos_drm_fbdev_suspend/resume can be removed
> as drm_mode_config_helper_suspend/resume has
> implement the same in generic way.
>
> Remove suspend_state from exynos_drm_private
> struct as it is no more useful.
>
> Signed-off-by: Ajit Negi
> Signed-off-by: Souptick Joarder
> Tested-by: Marek Szyprowski
Can we get this patch in queue for 4.20 ? Not yet available in linux-next.
> ---
> v2: Address Inki Dae's comment. Remove ret variable
> from both suspend/resume function.
>
> v3: Tested by Marek. Updated the change log.
>
> v4: removing the return as exynos_drm_resume()
> now returns void.
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 17 -
> drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 --
> 4 files changed, 2 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index b599f74..6f76baf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -149,37 +149,15 @@ static void exynos_drm_postclose(struct drm_device
> *dev, struct drm_file *file)
> static int exynos_drm_suspend(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> - struct exynos_drm_private *private;
> -
> - if (!drm_dev)
> - return 0;
> -
> - private = drm_dev->dev_private;
> -
> - drm_kms_helper_poll_disable(drm_dev);
> - exynos_drm_fbdev_suspend(drm_dev);
> - private->suspend_state = drm_atomic_helper_suspend(drm_dev);
> - if (IS_ERR(private->suspend_state)) {
> - exynos_drm_fbdev_resume(drm_dev);
> - drm_kms_helper_poll_enable(drm_dev);
> - return PTR_ERR(private->suspend_state);
> - }
>
> - return 0;
> + return drm_mode_config_helper_suspend(drm_dev);
> }
>
> static void exynos_drm_resume(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> - struct exynos_drm_private *private;
> -
> - if (!drm_dev)
> - return;
>
> - private = drm_dev->dev_private;
> - drm_atomic_helper_resume(drm_dev, private->suspend_state);
> - exynos_drm_fbdev_resume(drm_dev);
> - drm_kms_helper_poll_enable(drm_dev);
> + drm_mode_config_helper_resume(drm_dev);
> }
>
> static const struct dev_pm_ops exynos_drm_pm_ops = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index c737c4b..7349e7c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -195,7 +195,6 @@ struct drm_exynos_file_private {
> */
> struct exynos_drm_private {
> struct drm_fb_helper *fb_helper;
> - struct drm_atomic_state *suspend_state;
>
> struct device *g2d_dev;
> struct device *dma_dev;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 132dd52..918dd2c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -270,20 +270,3 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
> private->fb_helper = NULL;
> }
>
> -void exynos_drm_fbdev_suspend(struct drm_device *dev)
> -{
> - struct exynos_drm_private *private = dev->dev_private;
> -
> - console_lock();
> - drm_fb_helper_set_suspend(private->fb_helper, 1);
> - console_unlock();
> -}
> -
> -void exynos_drm_fbdev_resume(struct drm_device *dev)
> -{
> - struct exynos_drm_private *private = dev->dev_private;
> -
> - console_lock();
> - drm_fb_helper_set_suspend(private->fb_helper, 0);
> - console_unlock();
> -}
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> index b338472..6840b6a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> @@ -19,8 +19,6 @@
>
> int exynos_drm_fbdev_init(struct drm_device *dev);
> void exynos_drm_fbdev_fini(struct drm_device *dev);
> -void exynos_drm_fbdev_suspend(struct drm_device *drm);
> -void exynos_drm_fbdev_resume(struct drm_device *drm);
>
> #else
>
> @@ -39,14 +37,6 @@ static inline void exynos_drm_fbdev_restore_mode(struct
> drm_device *dev)
>
> #define exynos_drm_output_poll_changed (NULL)
>
> -static inline void exynos_drm_fbdev_suspend(struct drm_device *drm)
> -{
> -}
> -
> -static inline void exynos_drm_fbdev_resume(struct drm_device *drm)
> -{
> -}
> -
> #endif
>
> #endif
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
[PATCH] drm/amdgpu: Add braces to initialize task_info subojects
Clang warns if there are missing braces around a subobject
initializer.
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1447:41: warning: suggest braces
around initialization of subobject [-Wmissing-braces]
struct amdgpu_task_info task_info = { 0 };
^
{}
1 warning generated.
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:262:41: warning: suggest braces
around initialization of subobject [-Wmissing-braces]
struct amdgpu_task_info task_info = { 0 };
^
{}
1 warning generated.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 9333109b210d..968cc1b8cdff 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1444,7 +1444,7 @@ static int gmc_v8_0_process_interrupt(struct
amdgpu_device *adev,
gmc_v8_0_set_fault_enable_default(adev, false);
if (printk_ratelimit()) {
- struct amdgpu_task_info task_info = { 0 };
+ struct amdgpu_task_info task_info = { { 0 } };
amdgpu_vm_get_task_info(adev, entry->pasid, &task_info);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 72f8018fa2a8..a781a5027212 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -259,7 +259,7 @@ static int gmc_v9_0_process_interrupt(struct amdgpu_device
*adev,
}
if (printk_ratelimit()) {
- struct amdgpu_task_info task_info = { 0 };
+ struct amdgpu_task_info task_info = { { 0 } };
amdgpu_vm_get_task_info(adev, entry->pasid, &task_info);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/amdgpu: add freesync ioctl
Am 11.09.2018 um 21:17 schrieb Alex Deucher:
On Tue, Sep 11, 2018 at 1:59 PM Kazlauskas, Nicholas
wrote:
On 09/11/2018 01:51 PM, Christian König wrote:
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
These patches were already merged into amd-staging-drm-next so we felt
it was best to just base the existing ones off of this work to keep
things consistent.
The later patches in the series remove most of it but it looks like some
of ioctl stuff itself was missed in amdgpu. It could probably use
another patch on top of this to finish cleaning it up.
You might want to just revert the relevant commits in
amd-staging-drm-next as the starting point for this patch set so that
what we eventually upstream is clean. Better yet, base it on this
branch:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.20-wip
Which is basically amd-staging-drm-next without all the non-upstream stuff.
Yes, completely agree.
For review it is certainly better to have a clean history based on some
upstream branch, especially when you add common stuff like in this patchset.
Regards,
Christian.
Alex
Christian.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 4
include/uapi/drm/amdgpu_drm.h| 16
5 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 447c4c7a36d6..95af917007f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1193,6 +1193,9 @@ int amdgpu_cs_wait_fences_ioctl(struct
drm_device *dev, void *data,
int amdgpu_gem_metadata_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int amdgpu_display_freesync_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
/* VRAM scratch page for HDP bug, default vram page */
struct amdgpu_vram_scratch {
struct amdgpu_bo*robj;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 642b47c5f4b8..7d6a36bca9dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -894,3 +894,18 @@ int amdgpu_display_crtc_idx_to_irq_type(struct
amdgpu_device *adev, int crtc)
return AMDGPU_CRTC_IRQ_NONE;
}
}
+
+int amdgpu_display_freesync_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp)
+{
+int ret = -EPERM;
+struct amdgpu_device *adev = dev->dev_private;
+
+if (adev->mode_info.funcs->notify_freesync)
+ret = adev->mode_info.funcs->notify_freesync(dev,data,filp);
+else
+DRM_DEBUG("amdgpu no notify_freesync ioctl\n");
+
+return ret;
+}
+
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index bd98cc5fb97b..5b26e0447221 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1099,7 +1099,8 @@ const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA,
amdgpu_gem_metadata_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
-DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW)
+DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl,
DRM_MASTER)
};
const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8be3028850b6..56598ed53123 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1584,6 +1584,7 @@ static void dm_bandwidth_update(struct
amdgpu_device *adev)
static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
struct drm_file *filp)
{
+struct drm_amdgpu_freesync *args = data;
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
struct drm_crtc *crtc;
@@ -1593,6 +1594,9 @@ static int amdgpu_notify_freesync(struct
drm_device *dev, void *data,
uint8_t i;
bool enable = false;
+if (args->op == AMDGPU_FREESYNC_FULLSCREEN_ENTER)
+enable = true;
+
drm_modeset_acquire_init(&ctx, 0);
state =
Re: [PATCH 1/3] [RFC]drm: add syncobj timeline support v4
Ping? Have you seen my comments here?
Looks like you haven't addressed any of them in your last mail.
Christian.
Am 06.09.2018 um 09:25 schrieb Christian König:
Am 06.09.2018 um 08:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer
payload
identifying a point in a timeline. Such timeline semaphores support the
Drop the term semaphore here, better use syncobj.
following operations:
* CPU query - A host operation that allows querying the payload
of the
timeline semaphore.
* CPU wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is
signaled before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence,
when PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when
timeline is increasing, will compare
wait PTs value with new timeline value, if PT value is lower than
timeline value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait
on any point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal
PT, we need a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate
patch. (Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate
patch.
5. drop the submission_fence implementation and instead use
wait_event() for that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and
Christian)
a. normal syncobj signal op will create a signal PT to tail of
signal pt list.
b. normal syncobj wait op will create a wait pt with last signal
point, and this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
Tested by ./deqp-vk -n dEQP-VK*semaphore* for normal syncobj
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 516 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 78 ++--
include/uapi/drm/drm.h | 1 +
4 files changed, 448 insertions(+), 151 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..94b31de23858 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is
1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,18 @@ static const struct dma_fence_ops
drm_syncobj_stub_fence_ops = {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64 value;
+ struct list_head list;
+};
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_pt_fence;
+ struct dma_fence_cb wait_cb;
+ struct rb_node node;
+ u64 value;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -109,61 +124,238 @@ struct drm_syncobj *drm_syncobj_find(struct
drm_file *file_private,
}
EXPORT_SYMBOL(drm_syncobj_find);
-static void drm_syncobj_add_callback_locked(struct drm_syncobj
*syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func)
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj,
+ struct drm_syncobj_timeline *syncobj_timeline)
Since we merged timeline and singleton syncobj you can drop the extra
_timeline_ part in the function name I think.
{
- cb->func = func;
- list_add_tail(&cb->node, &syncobj->cb_list);
+ spin_lock(&syncobj->lock);
+ syncobj_timeline->timeline_context = dma_fence_context_alloc(1);
+ syncobj_timeline->timeline = 0;
+ syncobj_timeline->signal_point = 0;
+ init_waitqueue_head(&syncobj_timeline->wq);
+
+ syncobj_timeline->wait_pt_tree = RB_ROOT;
+
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
Hi, > I attempted to fix it in the ttm layer and here is the discussion > https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/ > > The ttm maintainer Christian is suggesting to map and set ttm->pages as > decrypted > right after ttm->pages are allocated. > > Just checking with you guys maybe there is a better way to handle this in > the virtio gpu layer instead of the common ttm layer. Could you guys shine > some > light on this? Thanks. I think the tty layer is the right place to fix this. virtio just calls down to ttm for mappings. I think virtio should just hint to ttm using a flag in some struct, probably ttm_buffer_object or ttm_mem_type_manager, that the objects need decrypted mappings. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] staging: vboxvideo: Fix modeset / page_flip error handling
Hi,
On 11-09-18 20:46, Greg Kroah-Hartman wrote:
On Tue, Sep 11, 2018 at 09:15:41AM +0200, Hans de Goede wrote:
The default settings for Linux vms created in VirtualBox allocate only
16M of videomem. When running fullscreen on a 1920x1080 (or bigger) monitor
this is not a lot.
When using GNOME3 on Wayland we have already been seeing out of video
memory errors for a while now. After commit 2408898e3b6c ("staging:
vboxvideo: Add page-flip support") this has become much worse as now
multiple buffers are used.
There is nothing we can do about there not being enough video-mem, but
we should handle running out of video-mem properly, currently there are
2 problems with this:
1) vbox_crtc_mode_set() does not check if vbox_crtc_mode_set_base() fails
at all and does not properly propagate the oom error.
2) vbox_crtc_do_set_base() unpins the old fb too soon:
2.1) It unpins it before pinning the new fb, so if the pinning of the new
fb fails (which it will when we run out of video-mem), then we also cannot
fall back to the old-fb as it has been already unpinned. We could try to
re-pin it but there is no guarantee that will succeed.
2.2) It unpins it before reprogramming the hardware to scan out from the
new-fb, which could lead to some ugliness where the hw is scanning out the
oldfb while it is being replaced with something else.
Fixing this requires to do things in this order:
1) Pin the new fb
2) Program the hw
3) Unpin the oldfb
This needs to be done for both a mode_set and for a page_flip so this
commit re-writes vbox_crtc_do_set_base() into vbox_crtc_set_base_and_mode()
which does this in the correct order, putting the hardware programming
which was duplicated between the mode_set and page_flip code inside the
new function.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 121 +-
1 file changed, 62 insertions(+), 59 deletions(-)
This doesn't apply to my tree. Does it need to go on top of the
previous patches you sent for 4.19-final?
Yes this goes on top of the fixes for 4.19-final.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #13 from Elmar Stellnberger (estel...@elstel.org) --- Unfortunately when I install rng-tools I get the following error message with 4.19.0-rc2+: Hardware RNG device inode not found. If I install rng-tools5 I get no error message but booting does not speed up with rng-tools5 (same long waiting). Concerning my wireless network card I have an iwlwifi card (Intel Corporation Ultimate N WiFi Link 5300). However there seems to be no kernel option in order to gather entropy with this card. -- 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 1/4] staging: vboxvideo: Fix modeset / page_flip error handling
On Wed, Sep 12, 2018 at 09:54:51AM +0200, Hans de Goede wrote:
> Hi,
>
> On 11-09-18 20:46, Greg Kroah-Hartman wrote:
> > On Tue, Sep 11, 2018 at 09:15:41AM +0200, Hans de Goede wrote:
> > > The default settings for Linux vms created in VirtualBox allocate only
> > > 16M of videomem. When running fullscreen on a 1920x1080 (or bigger)
> > > monitor
> > > this is not a lot.
> > >
> > > When using GNOME3 on Wayland we have already been seeing out of video
> > > memory errors for a while now. After commit 2408898e3b6c ("staging:
> > > vboxvideo: Add page-flip support") this has become much worse as now
> > > multiple buffers are used.
> > >
> > > There is nothing we can do about there not being enough video-mem, but
> > > we should handle running out of video-mem properly, currently there are
> > > 2 problems with this:
> > >
> > > 1) vbox_crtc_mode_set() does not check if vbox_crtc_mode_set_base() fails
> > > at all and does not properly propagate the oom error.
> > >
> > > 2) vbox_crtc_do_set_base() unpins the old fb too soon:
> > >
> > > 2.1) It unpins it before pinning the new fb, so if the pinning of the new
> > > fb fails (which it will when we run out of video-mem), then we also cannot
> > > fall back to the old-fb as it has been already unpinned. We could try to
> > > re-pin it but there is no guarantee that will succeed.
> > >
> > > 2.2) It unpins it before reprogramming the hardware to scan out from the
> > > new-fb, which could lead to some ugliness where the hw is scanning out the
> > > oldfb while it is being replaced with something else.
> > >
> > > Fixing this requires to do things in this order:
> > > 1) Pin the new fb
> > > 2) Program the hw
> > > 3) Unpin the oldfb
> > >
> > > This needs to be done for both a mode_set and for a page_flip so this
> > > commit re-writes vbox_crtc_do_set_base() into
> > > vbox_crtc_set_base_and_mode()
> > > which does this in the correct order, putting the hardware programming
> > > which was duplicated between the mode_set and page_flip code inside the
> > > new function.
> > >
> > > Signed-off-by: Hans de Goede
> > > ---
> > > drivers/staging/vboxvideo/vbox_mode.c | 121 +-
> > > 1 file changed, 62 insertions(+), 59 deletions(-)
> >
> > This doesn't apply to my tree. Does it need to go on top of the
> > previous patches you sent for 4.19-final?
>
> Yes this goes on top of the fixes for 4.19-final.
Ok, thanks for confirming.
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Differentiate the lack of an interface from invalid parameter
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENODEV so that it can be easily distinguished from
both the lack of the ioctl and from a regular invalid parameter.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 6eaacd4eb8cc..eed6ad0fe84a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -113,6 +113,9 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
struct drm_mode_fb_cmd2 r = {};
int ret;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -ENODEV;
+
r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
if (r.pixel_format == DRM_FORMAT_INVALID) {
DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
@@ -352,7 +355,7 @@ int drm_mode_addfb2(struct drm_device *dev,
struct drm_framebuffer *fb;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return -EINVAL;
+ return -ENODEV;
fb = drm_internal_framebuffer_create(dev, r, file_priv);
if (IS_ERR(fb))
@@ -387,7 +390,7 @@ int drm_mode_addfb2_ioctl(struct drm_device *dev,
* ADDFB.
*/
DRM_DEBUG_KMS("addfb2 broken on bigendian");
- return -EINVAL;
+ return -ENODEV;
}
#endif
return drm_mode_addfb2(dev, data, file_priv);
@@ -432,7 +435,7 @@ int drm_mode_rmfb(struct drm_device *dev, u32 fb_id,
int found = 0;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return -EINVAL;
+ return -ENODEV;
fb = drm_framebuffer_lookup(dev, file_priv, fb_id);
if (!fb)
@@ -509,7 +512,7 @@ int drm_mode_getfb(struct drm_device *dev,
int ret;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return -EINVAL;
+ return -ENODEV;
fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
if (!fb)
@@ -582,7 +585,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
int ret;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return -EINVAL;
+ return -ENODEV;
fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
if (!fb)
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Differentiate the lack of an interface from invalid parameter
On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson wrote:
> If the ioctl is not supported on a particular piece of HW/driver
> combination, report ENODEV so that it can be easily distinguished from
> both the lack of the ioctl and from a regular invalid parameter.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
Hm, I thought the canonical errno for "ioctl doesn't apply to this
device" is ENOTTY? And ENODEV means that it applies, but atm nothing
plugged in, or device gone already.
I found a few more modeset ioctl:
- drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl
- drm_mode_getconnector
- drm_mode_getcrtc, drm_mode_setcrtc
- drm_mode_getencoder
- drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ...
Ok now I stop looking through the grep thing, looks like we've been
using EINVAL consistently. I'm all for switching, it makes sense, but
I think we should at least try to be consistent across all kms ioctl.
I'm happy to r-b such a series.
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_framebuffer.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 6eaacd4eb8cc..eed6ad0fe84a 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -113,6 +113,9 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> struct drm_mode_fb_cmd2 r = {};
> int ret;
>
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -ENODEV;
> +
> r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
> if (r.pixel_format == DRM_FORMAT_INVALID) {
> DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
> @@ -352,7 +355,7 @@ int drm_mode_addfb2(struct drm_device *dev,
> struct drm_framebuffer *fb;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> + return -ENODEV;
>
> fb = drm_internal_framebuffer_create(dev, r, file_priv);
> if (IS_ERR(fb))
> @@ -387,7 +390,7 @@ int drm_mode_addfb2_ioctl(struct drm_device *dev,
> * ADDFB.
> */
> DRM_DEBUG_KMS("addfb2 broken on bigendian");
> - return -EINVAL;
> + return -ENODEV;
> }
> #endif
> return drm_mode_addfb2(dev, data, file_priv);
> @@ -432,7 +435,7 @@ int drm_mode_rmfb(struct drm_device *dev, u32 fb_id,
> int found = 0;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> + return -ENODEV;
>
> fb = drm_framebuffer_lookup(dev, file_priv, fb_id);
> if (!fb)
> @@ -509,7 +512,7 @@ int drm_mode_getfb(struct drm_device *dev,
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> + return -ENODEV;
>
> fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> if (!fb)
> @@ -582,7 +585,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> + return -ENODEV;
>
> fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> if (!fb)
> --
> 2.19.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] phy: Add configuration interface
Hi! On Wed, Sep 12, 2018 at 01:12:31PM +0530, Kishon Vijay Abraham I wrote: > On Thursday 06 September 2018 08:26 PM, Maxime Ripard wrote: > > Hi Kishon, > > > > On Thu, Sep 06, 2018 at 02:57:58PM +0530, Kishon Vijay Abraham I wrote: > >> On Wednesday 05 September 2018 02:46 PM, Maxime Ripard wrote: > >>> The phy framework is only allowing to configure the power state of the PHY > >>> using the init and power_on hooks, and their power_off and exit > >>> counterparts. > >>> > >>> While it works for most, simple, PHYs supported so far, some more advanced > >>> PHYs need some configuration depending on runtime parameters. These PHYs > >>> have been supported by a number of means already, often by using ad-hoc > >>> drivers in their consumer drivers. > >>> > >>> That doesn't work too well however, when a consumer device needs to deal > >>> multiple PHYs, or when multiple consumers need to deal with the same PHY > >>> (a > >>> DSI driver and a CSI driver for example). > >>> > >>> So we'll add a new interface, through two funtions, phy_validate and > >>> phy_configure. The first one will allow to check that a current > >>> configuration, for a given mode, is applicable. It will also allow the PHY > >>> driver to tune the settings given as parameters as it sees fit. > >>> > >>> phy_configure will actually apply that configuration in the phy itself. > >>> > >>> Signed-off-by: Maxime Ripard > >>> --- > >>> drivers/phy/phy-core.c | 62 ++- > >>> include/linux/phy/phy.h | 42 - > >>> 2 files changed, 104 insertions(+) > >>> > >>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > >>> index 35fd38c5a4a1..6eaf655e370f 100644 > >>> --- a/drivers/phy/phy-core.c > >>> +++ b/drivers/phy/phy-core.c > >>> @@ -408,6 +408,68 @@ int phy_calibrate(struct phy *phy) > >>> EXPORT_SYMBOL_GPL(phy_calibrate); > >>> > >>> /** > >>> + * phy_configure() - Changes the phy parameters > >>> + * @phy: the phy returned by phy_get() > >>> + * @mode: phy_mode the configuration is applicable to. > >> > >> mode should be used if the same PHY can be configured in multiple modes. > >> But > >> with phy_set_mode() and phy_calibrate() we could achieve the same. > > > > So you would change the prototype to have a configuration applying > > only to the current mode set previously through set_mode? > > yeah. > With phy_configure, if the PHY is not in @mode, it should return an error? Or > will it set the PHY to @mode and apply the configuration in @opts? I wanted to have it return an error either if it was configured in another mode or if the mode was unsupported yes. > > Can we have PHY that operate in multiple modes at the same time? > > Not at the same time. But the same PHY can operate in multiple modes (For > example we have PHYs that can be used either with PCIe or USB3) Ok, that makes sense. I guess we could rely on phy_set_mode then if you prefer. > >>> + * @opts: New configuration to apply > >> > >> Should these configuration come from the consumer driver? > > > > Yes > > How does the consumer driver get these configurations? Is it from user space > or > dt associated with consumer device. It really depends on multiple factors (and I guess on what mode the PHY is actually supposed to support), but in the case covered by this serie, the info mostly come from multiple places: - The resolutions supported by the panel - The resolutions supported by the phy consumer (and its integration, for things like the clock rates it can output) - The resolutions and timings supported by the phy itself (once again, the integration is mostly involved here since it really only depends on which clock rates can be achieved) - The timings boundaries that the specification has - The resolution selected by the user So we'd have that information coming from multiple places: the userspace would select the resolution, drivers would be able to filter out unsupported resolutions, and the DT will provide the integration details to help them do so. But I guess from an API standpoint, it really is expected to be assembled by the phy consumer driver. > >>> +/** > >>> + * phy_validate() - Checks the phy parameters > >>> + * @phy: the phy returned by phy_get() > >>> + * @mode: phy_mode the configuration is applicable to. > >>> + * @opts: Configuration to check > >>> + * > >>> + * Used to check that the current set of parameters can be handled by > >>> + * the phy. Implementations are free to tune the parameters passed as > >>> + * arguments if needed by some implementation detail or > >>> + * constraints. It will not change any actual configuration of the > >>> + * PHY, so calling it as many times as deemed fit will have no side > >>> + * effect. > >>> + * > >>> + * Returns: 0 if successful, an negative error code otherwise > >>> + */ > >>> +int phy_validate(struct phy *phy, enum phy_mode mode, > >>> + union phy_configure_opts *opts) > >> > >>
Re: [PATCH] drm: Differentiate the lack of an interface from invalid parameter
Quoting Daniel Vetter (2018-09-12 09:39:30) > On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson > wrote: > > If the ioctl is not supported on a particular piece of HW/driver > > combination, report ENODEV so that it can be easily distinguished from > > both the lack of the ioctl and from a regular invalid parameter. > > > > Signed-off-by: Chris Wilson > > Cc: Daniel Vetter > > Cc: Ville Syrjälä > > Hm, I thought the canonical errno for "ioctl doesn't apply to this > device" is ENOTTY? That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows about the ioctl but it isn't applicable. Either is fine for my purpose, which is to know the ioctl exists, I just need to distinguish it from EINVAL. > And ENODEV means that it applies, but atm nothing > plugged in, or device gone already. > > I found a few more modeset ioctl: > - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl > - drm_mode_getconnector > - drm_mode_getcrtc, drm_mode_setcrtc > - drm_mode_getencoder > - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ... > > Ok now I stop looking through the grep thing, looks like we've been > using EINVAL consistently. I'm all for switching, it makes sense, but > I think we should at least try to be consistent across all kms ioctl. Ah, but we've been consistent on the other side and have been using ENODEV for the better part of a decade for this meaning (that the ioctl doesn't apply to this HW) :) -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/sun4i: Support color dithering for LCD panels
On Fri, Sep 7, 2018 at 7:23 PM Maxime Ripard wrote: > > On Fri, Sep 07, 2018 at 12:19:42PM +0800, Chen-Yu Tsai wrote: > > > > Hi, > > > > This is v2 of my sun4i-drm LCD color dithering series. v1 was from back > > in April [1]. Most of the driver code is unchanged. > > > > Changes since v1: > > > > - Explicitly list properties from the simple-panel binding that apply > > to the Bananapi 7" panel > > > > - Moved an incorrectly squashed change from patch 3 to patch 1, where > > it belongs > > Applied the first three patches, thanks! Any comments on patches 4 and 5? Thanks ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Differentiate the lack of an interface from invalid parameter
On Wed, Sep 12, 2018 at 10:50 AM, Chris Wilson wrote: > Quoting Daniel Vetter (2018-09-12 09:39:30) >> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson >> wrote: >> > If the ioctl is not supported on a particular piece of HW/driver >> > combination, report ENODEV so that it can be easily distinguished from >> > both the lack of the ioctl and from a regular invalid parameter. >> > >> > Signed-off-by: Chris Wilson >> > Cc: Daniel Vetter >> > Cc: Ville Syrjälä >> >> Hm, I thought the canonical errno for "ioctl doesn't apply to this >> device" is ENOTTY? > > That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows > about the ioctl but it isn't applicable. Either is fine for my purpose, > which is to know the ioctl exists, I just need to distinguish it from > EINVAL. > >> And ENODEV means that it applies, but atm nothing >> plugged in, or device gone already. >> >> I found a few more modeset ioctl: >> - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl >> - drm_mode_getconnector >> - drm_mode_getcrtc, drm_mode_setcrtc >> - drm_mode_getencoder >> - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ... >> >> Ok now I stop looking through the grep thing, looks like we've been >> using EINVAL consistently. I'm all for switching, it makes sense, but >> I think we should at least try to be consistent across all kms ioctl. > > Ah, but we've been consistent on the other side and have been using > ENODEV for the better part of a decade for this meaning (that the ioctl > doesn't apply to this HW) :) Hm indeed, we've been using either ENODEV or EINVAL for "this ioctl doesn't exist/doesn't apply". ENODEV is clearly used in many places (also outside of drm) for "hw absent/gone/disappeared". And we have very few uses of ENOTTY. So I'm kinda leaning towards starting a new trend here, and using ENOTTY for "this ioctl doesn't apply". I don't think we need to differentiate this from the case of "this kernel has no idea about this ioctl at all", since from a userspace pov there's no difference really: Either way it can't use it. But I'm also fine if we're just sticking to ENODEV, just feels like wasting a perfectly useful errno (and there's not many) if we don't give ENOTTY some more use. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] add LG panel to dpcd quirk database
On Tue, 11 Sep 2018, Clint Taylor wrote: > On 09/11/2018 01:56 AM, Lee, Shawn C wrote: >> Only specific N value (0x8000) would be acceptable for LG >> LP140WF6-SPM1 eDP panel which is running at asynchronous >> clock mode. With the other N value, it will enter BITS mode >> and display black screen. This patch series set constant N >> value for specific sink/branch device that would cover >> similar issue. >> >> Cc: Jani Nikula >> Cc: Cooper Chiou >> Cc: Matt Atwood >> Cc: Maarten Lankhorst >> Cc: Dhinakaran Pandiyan >> Cc: Clint Taylor >> >> Lee, Shawn C (3): >>drm: Add support for device_id based detection. >>drm: Change limited M/N quirk to constant N quirk. >>drm: add LG eDP panel to quirk database >> >> drivers/gpu/drm/drm_dp_helper.c | 17 - >> drivers/gpu/drm/i915/intel_display.c | 28 +--- >> drivers/gpu/drm/i915/intel_display.h | 2 +- >> drivers/gpu/drm/i915/intel_dp.c | 8 >> drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++--- >> include/drm/drm_dp_helper.h | 6 +++--- >> 6 files changed, 40 insertions(+), 27 deletions(-) >> > > Tested quirk on Analogix 7737 based USB_C->HDMI dongle that the original > Limited M/N quirk was designed around. New quirk appears to work correctly. Thanks a lot for this! BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Differentiate the lack of an interface from invalid parameter
Quoting Daniel Vetter (2018-09-12 10:02:47) > On Wed, Sep 12, 2018 at 10:50 AM, Chris Wilson > wrote: > > Quoting Daniel Vetter (2018-09-12 09:39:30) > >> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson > >> wrote: > >> > If the ioctl is not supported on a particular piece of HW/driver > >> > combination, report ENODEV so that it can be easily distinguished from > >> > both the lack of the ioctl and from a regular invalid parameter. > >> > > >> > Signed-off-by: Chris Wilson > >> > Cc: Daniel Vetter > >> > Cc: Ville Syrjälä > >> > >> Hm, I thought the canonical errno for "ioctl doesn't apply to this > >> device" is ENOTTY? > > > > That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows > > about the ioctl but it isn't applicable. Either is fine for my purpose, > > which is to know the ioctl exists, I just need to distinguish it from > > EINVAL. > > > >> And ENODEV means that it applies, but atm nothing > >> plugged in, or device gone already. > >> > >> I found a few more modeset ioctl: > >> - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl > >> - drm_mode_getconnector > >> - drm_mode_getcrtc, drm_mode_setcrtc > >> - drm_mode_getencoder > >> - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ... > >> > >> Ok now I stop looking through the grep thing, looks like we've been > >> using EINVAL consistently. I'm all for switching, it makes sense, but > >> I think we should at least try to be consistent across all kms ioctl. > > > > Ah, but we've been consistent on the other side and have been using > > ENODEV for the better part of a decade for this meaning (that the ioctl > > doesn't apply to this HW) :) > > Hm indeed, we've been using either ENODEV or EINVAL for "this ioctl > doesn't exist/doesn't apply". ENODEV is clearly used in many places > (also outside of drm) for "hw absent/gone/disappeared". And we have > very few uses of ENOTTY. So I'm kinda leaning towards starting a new > trend here, and using ENOTTY for "this ioctl doesn't apply". I don't > think we need to differentiate this from the case of "this kernel has > no idea about this ioctl at all", since from a userspace pov there's > no difference really: Either way it can't use it. > > But I'm also fine if we're just sticking to ENODEV, just feels like > wasting a perfectly useful errno (and there's not many) if we don't > give ENOTTY some more use. In going through the drm_core_checks, I noticed one brave soul used -ENOTSUPP. How about that? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] efifb: BGRT: Add nobgrt option
In some setups restoring the BGRT logo is undesirable, allow passing
video=efifb:nobgrt on the kernel commandline to disable it.
Cc: David Herrmann
Reported-by: David Herrmann
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/efifb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3946649b85c8..ba906876cc45 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -42,6 +42,7 @@ struct bmp_dib_header {
u32 colors_important;
} __packed;
+static bool use_bgrt = true;
static bool request_mem_succeeded = false;
static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
@@ -160,6 +161,9 @@ static void efifb_show_boot_graphics(struct fb_info *info)
void *bgrt_image = NULL;
u8 *dst = info->screen_base;
+ if (!use_bgrt)
+ return;
+
if (!bgrt_tab.image_address) {
pr_info("efifb: No BGRT, not showing boot graphics\n");
return;
@@ -290,6 +294,8 @@ static int efifb_setup(char *options)
screen_info.lfb_width =
simple_strtoul(this_opt+6, NULL, 0);
else if (!strcmp(this_opt, "nowc"))
mem_flags &= ~EFI_MEMORY_WC;
+ else if (!strcmp(this_opt, "nobgrt"))
+ use_bgrt = false;
}
}
--
2.19.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"
Hi,
On 03-09-18 17:11, David Herrmann wrote:
Hey
On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede wrote:
Hi,
On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
Hey
Since this commit:
34db50e55656 efifb: Copy the ACPI BGRT
the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our setups. In particular, we have a setup
where an efi-boot-entry draws the early boot-splash on-screen, then
hands-over to the linux-kernel + initrd. The boot-splash daemon in the
initrd then takes over control of possible animations.
With the mentioned commit compiled in, the kernel will redraw the
firmware logo on screen at a random time without any way to intervene.
You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
console takeover support introduced in v4,19-rc1). I assume that this
is intended?
What is the intention of this commit? Why is the kernel re-drawing the
firmware logo unasked? If someone during the boot-process draws
content on the screen, I would prefer if the kernel does not clear
that on driver load.
+/*
+ * If fbcon deffered console takeover is configured, the intent is for the
+ * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
+ * (error) message to display. But the boot graphics may have been destroyed by
+ * e.g. option ROM output, detect this and restore the boot graphics.
+ */
+#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
+defined CONFIG_ACPI_BGRT
...
+static void efifb_show_boot_graphics(struct fb_info *info)
...
+#else
+static inline void efifb_show_boot_graphics(struct fb_info *info) {}
+#endif
Can we either provide an option to disable this feature, or revert the commit?
Hans?
We use the ACPI bgrt extension to get the logo to draw and then
draw it since some devices rely on the OS to draw it and otherwise we
just end up with a blackscreen when doing silent / flickerfree boot.
Ideally you would be able to get your vendor to put the logo in firmware
in the ACPI bgrt extension, then you also do not need to play any tricks
with an EFI binary drawing your own logo. But I can understand if you don't
have control over this, so you need to do this with the EFI binary trick.
I can also understand that you want to use deferred console takeover
in a setup like yours to avoid fbcon messing up what is on the display
during boot, that is exactly what it is for. So I think a reasonable
approach here is to add a kernel commandline option, say:
video=efifb:nobgrt
David, would that work for you?
That would be perfect!
Ok, I just send out a patch for this with you in the Cc.
Sorry for taking a bit long to write the patch.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Differentiate the lack of an interface from invalid parameter
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENOTSUPP so that it can be easily distinguished from
both the lack of the ioctl and from a regular invalid parameter.
v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_context.c | 16
drivers/gpu/drm/drm_crtc.c| 4 ++--
drivers/gpu/drm/drm_encoder.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 13 -
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/drm_lease.c | 8
drivers/gpu/drm/drm_lock.c| 4 ++--
drivers/gpu/drm/drm_mode_config.c | 2 +-
drivers/gpu/drm/drm_mode_object.c | 4 ++--
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 10 +-
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/drm_property.c| 8
drivers/gpu/drm/drm_scatter.c | 8
drivers/gpu/drm/drm_syncobj.c | 14 +++---
drivers/gpu/drm/drm_vblank.c | 4 ++--
22 files changed, 80 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 26690a664ec6..dc4502464126 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
- return -EINVAL;
+ return -ENOTSUPP;
/* disallow for userspace that has not enabled atomic cap (even
* though this may be a bit overkill, since legacy userspace
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ba8cfe65c65b..a07e7a781d64 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
map->flags, &maplist);
@@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
idx = map->offset;
if (idx < 0)
@@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
mutex_lock(&dev->struct_mutex);
list_for_each_entry(r_list, &dev->maplist, head) {
@@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_SG))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
#if IS_ENABLED(CONFIG_AGP)
if (request->flags & _DRM_AGP_BUFFER)
@@ -1267,10 +1267,10 @@ int __drm_legacy_infobufs(struct drm_device *dev,
int count;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1352,10 +1352,10 @@ int drm_legacy_markbufs(struct drm_device *dev, void
*data,
struct drm_buf_entry *entry;
[PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENOTSUPP so that it can be easily distinguished from
both the lack of the ioctl and from a regular invalid parameter.
v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_context.c | 16
drivers/gpu/drm/drm_crtc.c| 4 ++--
drivers/gpu/drm/drm_encoder.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 13 -
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/drm_lease.c | 8
drivers/gpu/drm/drm_lock.c| 4 ++--
drivers/gpu/drm/drm_mode_config.c | 2 +-
drivers/gpu/drm/drm_mode_object.c | 4 ++--
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 10 +-
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/drm_property.c| 8
drivers/gpu/drm/drm_scatter.c | 8
drivers/gpu/drm/drm_syncobj.c | 14 +++---
drivers/gpu/drm/drm_vblank.c | 4 ++--
22 files changed, 80 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 26690a664ec6..dc4502464126 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
- return -EINVAL;
+ return -ENOTSUPP;
/* disallow for userspace that has not enabled atomic cap (even
* though this may be a bit overkill, since legacy userspace
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ba8cfe65c65b..a07e7a781d64 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
map->flags, &maplist);
@@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
idx = map->offset;
if (idx < 0)
@@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
mutex_lock(&dev->struct_mutex);
list_for_each_entry(r_list, &dev->maplist, head) {
@@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_SG))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
#if IS_ENABLED(CONFIG_AGP)
if (request->flags & _DRM_AGP_BUFFER)
@@ -1267,10 +1267,10 @@ int __drm_legacy_infobufs(struct drm_device *dev,
int count;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -ENOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -ENOTSUPP;
if (!dma)
return -EINVAL;
@@ -1352,10 +1352,10 @@ int drm_legacy_markbufs(struct drm_device *dev, void
*data,
struct drm_buf_entry *entry;
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Hi Noralf,
On 08/09/2018 15:46, Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
I can't really ack/nack this move, on one side it's great to have a generic
fbdev emulation
instead of the old fbdev code, but on the other side the Amlogic platform (like
allwinner, samsung, rockchip, ...)
still relies on an Fbdev variant of the libMali that uses smem_start...
I know it's dirty and fbdev based code should be legacy now, but I consider it
like an user-space breakage...
I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that could use
FBINFO_HIDE_SMEM_START and allocate BO's
from the DRM driver, it won't be the case and it will never be the case until
the Lima projects finalizes.
So for me it's a no-go until Lima lands upstream in Linux *and* Mesa.
Neil
>
> Cc: Neil Armstrong
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/meson/meson_drv.c | 19 ++-
> drivers/gpu/drm/meson/meson_drv.h | 1 -
> 2 files changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index d3443125e661..348b5a198b9d 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -68,15 +68,7 @@
> * - Powering Up HDMI controller and PHY
> */
>
> -static void meson_fb_output_poll_changed(struct drm_device *dev)
> -{
> - struct meson_drm *priv = dev->dev_private;
> -
> - drm_fbdev_cma_hotplug_event(priv->fbdev);
> -}
> -
> static const struct drm_mode_config_funcs meson_mode_config_funcs = {
> - .output_poll_changed = meson_fb_output_poll_changed,
> .atomic_check= drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> .fb_create = drm_gem_fb_create,
> @@ -282,13 +274,6 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
>
> drm_mode_config_reset(drm);
>
> - priv->fbdev = drm_fbdev_cma_init(drm, 32,
> - drm->mode_config.num_connector);
> - if (IS_ERR(priv->fbdev)) {
> - ret = PTR_ERR(priv->fbdev);
> - goto free_drm;
> - }
> -
> drm_kms_helper_poll_init(drm);
>
> platform_set_drvdata(pdev, priv);
> @@ -297,6 +282,8 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
> if (ret)
> goto free_drm;
>
> + drm_fbdev_generic_setup(drm, 32);
> +
> return 0;
>
> free_drm:
> @@ -313,11 +300,9 @@ static int meson_drv_bind(struct device *dev)
> static void meson_drv_unbind(struct device *dev)
> {
> struct drm_device *drm = dev_get_drvdata(dev);
> - struct meson_drm *priv = drm->dev_private;
>
> drm_dev_unregister(drm);
> drm_kms_helper_poll_fini(drm);
> - drm_fbdev_cma_fini(priv->fbdev);
> drm_mode_config_cleanup(drm);
> drm_dev_put(drm);
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index 8450d6ac8c9b..aab96260da9f 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -33,7 +33,6 @@ struct meson_drm {
>
> struct drm_device *drm;
> struct drm_crtc *crtc;
> - struct drm_fbdev_cma *fbdev;
> struct drm_plane *primary_plane;
>
> /* Components Data */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm: fix syncobj null_fence_enable_signaling
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
Reviewed-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3a8837c49639..d17ed75ac7e2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,7 +184,6 @@ static const char *drm_syncobj_null_fence_get_name(struct
dma_fence *fence)
static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
{
-dma_fence_enable_sw_signaling(fence);
return !dma_fence_is_signaled(fence);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm: expand drm_syncobj_find_fence to support timeline point v2
we can fetch timeline point fence after expanded.
v2: The parameter fence is the result of the function and should come last.
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 5 +++--
drivers/gpu/drm/v3d/v3d_gem.c | 4 ++--
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
5 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 502b94fb116a..5db7b1b460da 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1102,7 +1102,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, 0, &fence);
if (r)
return r;
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index abbb22c97f7a..e04b0f336af0 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,6 +222,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* drm_syncobj_find_fence - lookup and reference the fence in a sync object
* @file_private: drm file private pointer
* @handle: sync object handle to lookup.
+ * @point: timeline point
* @fence: out parameter for the fence
*
* This is just a convenience function that combines drm_syncobj_find() and
@@ -232,7 +233,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
- u32 handle,
+ u32 handle, u64 point,
struct dma_fence **fence)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
@@ -503,7 +504,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
if (fd < 0)
return fd;
- ret = drm_syncobj_find_fence(file_private, handle, &fence);
+ ret = drm_syncobj_find_fence(file_private, handle, 0, &fence);
if (ret)
goto err_put_fd;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 5ce24098a5fd..9b9ab34fb461 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -521,12 +521,12 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
kref_init(&exec->refcount);
ret = drm_syncobj_find_fence(file_priv, args->in_sync_bcl,
-&exec->bin.in_fence);
+0, &exec->bin.in_fence);
if (ret == -EINVAL)
goto fail;
ret = drm_syncobj_find_fence(file_priv, args->in_sync_rcl,
-&exec->render.in_fence);
+0, &exec->render.in_fence);
if (ret == -EINVAL)
goto fail;
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 7910b9acedd6..928718b467bd 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1173,7 +1173,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
if (args->in_sync) {
ret = drm_syncobj_find_fence(file_priv, args->in_sync,
-&in_fence);
+0, &in_fence);
if (ret)
goto fail;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index e419c79ba94d..ab9055f943c7 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -134,7 +134,7 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
- u32 handle,
+ u32 handle, u64 point,
struct dma_fence **fence);
void drm_syncobj_free(struct kref *kref);
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm: rename null fence to stub fence in syncobj v2
moved to front of file.
stub fence will be used by timeline syncobj as well.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 53 +++
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d17ed75ac7e2..abbb22c97f7a 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,33 @@
#include "drm_internal.h"
#include
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
+{
+return "syncobjstub";
+}
+
+static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
+{
+return !dma_fence_is_signaled(fence);
+}
+
+static void drm_syncobj_stub_fence_release(struct dma_fence *f)
+{
+ kfree(f);
+}
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
+ .release = drm_syncobj_stub_fence_release,
+};
+
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -172,37 +199,15 @@ void drm_syncobj_replace_fence(struct drm_syncobj
*syncobj,
}
EXPORT_SYMBOL(drm_syncobj_replace_fence);
-struct drm_syncobj_null_fence {
- struct dma_fence base;
- spinlock_t lock;
-};
-
-static const char *drm_syncobj_null_fence_get_name(struct dma_fence *fence)
-{
-return "syncobjnull";
-}
-
-static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
-{
-return !dma_fence_is_signaled(fence);
-}
-
-static const struct dma_fence_ops drm_syncobj_null_fence_ops = {
- .get_driver_name = drm_syncobj_null_fence_get_name,
- .get_timeline_name = drm_syncobj_null_fence_get_name,
- .enable_signaling = drm_syncobj_null_fence_enable_signaling,
- .release = NULL,
-};
-
static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
{
- struct drm_syncobj_null_fence *fence;
+ struct drm_syncobj_stub_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (fence == NULL)
return -ENOMEM;
spin_lock_init(&fence->lock);
- dma_fence_init(&fence->base, &drm_syncobj_null_fence_ops,
+ dma_fence_init(&fence->base, &drm_syncobj_stub_fence_ops,
&fence->lock, 0, 0);
dma_fence_signal(&fence->base);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/amdgpu: move cs dependencies front a bit
cs dependencies handling doesn't need in vm resv
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 230e2357e249..aa829c6ef08e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1343,6 +1343,12 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
if (r)
goto out;
+ r = amdgpu_cs_dependencies(adev, &parser);
+ if (r) {
+ DRM_ERROR("Failed in the dependencies handling %d!\n", r);
+ goto out;
+ }
+
r = amdgpu_cs_parser_bos(&parser, data);
if (r) {
if (r == -ENOMEM)
@@ -1354,12 +1360,6 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
reserved_buffers = true;
- r = amdgpu_cs_dependencies(adev, &parser);
- if (r) {
- DRM_ERROR("Failed in the dependencies handling %d!\n", r);
- goto out;
- }
-
for (i = 0; i < parser.job->num_ibs; i++)
trace_amdgpu_cs(&parser, i);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] [RFC]drm: add syncobj timeline support v4
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline semaphore.
* CPU wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait on any
point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point, and
this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 494 -
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 78 ++--
include/uapi/drm/drm.h | 1 +
4 files changed, 425 insertions(+), 152 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..502cdf313aea 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,18 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_pt_fence;
+ struct dma_fence_cb wait_cb;
+ struct rb_node node;
+ u64value;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -109,61 +124,213 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
}
EXPORT_SYMBOL(drm_syncobj_find);
-static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func)
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj,
+ struct drm_syncobj_timeline
*syncobj_timeline)
{
- cb->func = func;
- list_add_tail(&cb->node, &syncobj->cb_list);
+ spin_lock(&syncobj->lock);
+ syncobj_timeline->timeline_context = dma_fence_context_alloc(1);
+ syncobj_timeline->timeline = 0;
+ syncobj_timeline->signal_point = 0;
+ init_waitqueue_head(&syncobj_timeline->wq);
+
+ syncobj_timeline->wait_pt_tree = RB_ROOT;
+ INIT_LIST_HEAD(&syncobj_timeline->signal_pt_list);
+ spin_unlock(&syncobj->lock);
}
-static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
-
[PATCH 4/9] drm: expand replace_fence to support timeline point v2
we can place a fence to a timeline point after expanded.
v2: change func parameter order
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 14 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/v3d/v3d_gem.c | 2 +-
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
6 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 5db7b1b460da..d68b73ff92d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1191,7 +1191,7 @@ static void amdgpu_cs_post_dependencies(struct
amdgpu_cs_parser *p)
int i;
for (i = 0; i < p->num_post_dep_syncobjs; ++i)
- drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence);
+ drm_syncobj_replace_fence(p->post_dep_syncobjs[i], 0, p->fence);
}
static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e04b0f336af0..e9ce623d049e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -167,11 +167,13 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
/**
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
+ * @point: timeline point
* @fence: fence to install in sync file.
*
- * This replaces the fence on a sync object.
+ * This replaces the fence on a sync object, or a timeline point fence.
*/
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
+ u64 point,
struct dma_fence *fence)
{
struct dma_fence *old_fence;
@@ -211,7 +213,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
&fence->lock, 0, 0);
dma_fence_signal(&fence->base);
- drm_syncobj_replace_fence(syncobj, &fence->base);
+ drm_syncobj_replace_fence(syncobj, 0, &fence->base);
dma_fence_put(&fence->base);
@@ -262,7 +264,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, NULL);
+ drm_syncobj_replace_fence(syncobj, 0, NULL);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -302,7 +304,7 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
}
if (fence)
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, 0, fence);
*out_syncobj = syncobj;
return 0;
@@ -487,7 +489,7 @@ static int drm_syncobj_import_sync_file_fence(struct
drm_file *file_private,
return -ENOENT;
}
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, 0, fence);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return 0;
@@ -969,7 +971,7 @@ drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
return ret;
for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], NULL);
+ drm_syncobj_replace_fence(syncobjs[i], 0, NULL);
drm_syncobj_array_free(syncobjs, args->count_handles);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3f0c612d42e7..0a8d2d64f380 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2166,7 +2166,7 @@ signal_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_SIGNAL))
continue;
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, 0, fence);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 9b9ab34fb461..70c54774400b 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -584,7 +584,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
/* Update the return sync object for the */
sync_out = drm_syncobj_find(file_priv, args->out_sync);
if (sync_out) {
- drm_syncobj_replace_fence(sync_out,
+ drm_syncobj_replace_fence(sync_out, 0,
&exec->render.base.s_fence->finished);
drm_syncobj_put(sync_out);
}
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 928718b467bd..5b22e996af6c 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drive
[PATCH 8/9] drm/amdgpu: add timeline support in amdgpu CS
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 111 +++--
include/uapi/drm/amdgpu_drm.h | 9 ++
3 files changed, 100 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 447c4c7a36d6..6e4a3db56833 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -975,6 +975,11 @@ struct amdgpu_cs_chunk {
void*kdata;
};
+struct amdgpu_cs_syncobj_post_dep {
+ struct drm_syncobj *post_dep_syncobj;
+ u64 point;
+};
+
struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -1003,9 +1008,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
-
+ struct amdgpu_cs_syncobj_post_dep *post_dep_syncobjs;
unsigned num_post_dep_syncobjs;
- struct drm_syncobj **post_dep_syncobjs;
};
static inline u32 amdgpu_get_ib_value(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d68b73ff92d2..230e2357e249 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -204,6 +204,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_DEPENDENCIES:
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
default:
@@ -783,7 +785,7 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser
*parser, int error,
&parser->validated);
for (i = 0; i < parser->num_post_dep_syncobjs; i++)
- drm_syncobj_put(parser->post_dep_syncobjs[i]);
+ drm_syncobj_put(parser->post_dep_syncobjs[i].post_dep_syncobj);
kfree(parser->post_dep_syncobjs);
dma_fence_put(parser->fence);
@@ -1098,11 +1100,11 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
}
static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
-uint32_t handle)
+uint32_t handle, u64 point)
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, point, &fence);
if (r)
return r;
@@ -1113,48 +1115,90 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
}
static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
- struct amdgpu_cs_chunk *chunk)
+ struct amdgpu_cs_chunk *chunk,
+ bool timeline)
{
unsigned num_deps;
int i, r;
- struct drm_amdgpu_cs_chunk_sem *deps;
- deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
- num_deps = chunk->length_dw * 4 /
- sizeof(struct drm_amdgpu_cs_chunk_sem);
+ if (!timeline) {
+ struct drm_amdgpu_cs_chunk_sem *deps;
- for (i = 0; i < num_deps; ++i) {
- r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p,
deps[i].handle,
+ 0);
if (r)
return r;
+ }
+ } else {
+ struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+
+ syncobj_deps = (struct drm_amdgpu_cs_chunk_syncobj
*)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_syncobj);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p,
syncobj_deps[i].handle,
+
syncobj_deps[i].point);
+ if (r)
+ return r;
+ }
}
+
return 0;
}
static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
-struct amdgpu_cs_chunk *chunk)
+struct amdgpu_cs_chunk *chunk,
+bool timeli
[PATCH 6/9] drm: add support of syncobj timeline point wait v2
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 87 +-
include/uapi/drm/drm.h | 14 ++
4 files changed, 94 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 40179c5fc6b8..1bdbf2273b49 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -178,6 +178,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ea10e9a26aad..92d94867746b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -669,6 +669,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 502cdf313aea..bcb3ba002985 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -976,6 +976,7 @@ static void syncobj_wait_fence_func(struct dma_fence *fence,
}
static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj
**syncobjs,
+ void __user *user_points,
uint32_t count,
uint32_t flags,
signed long timeout,
@@ -983,13 +984,27 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
+ uint64_t *points;
signed long ret;
uint32_t signaled_count, i;
- entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
- if (!entries)
+ points = kmalloc_array(count, sizeof(*points), GFP_KERNEL);
+ if (points == NULL)
return -ENOMEM;
+ if (!user_points) {
+ memset(points, 0, count * sizeof(uint64_t));
+ } else if (copy_from_user(points, user_points, sizeof(uint64_t) *
count)) {
+ ret = -EFAULT;
+ goto err_free_points;
+ }
+
+
+ entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
+ if (!entries) {
+ ret = -ENOMEM;
+ goto err_free_points;
+ }
/* Walk the list of sync objects and initialize entries. We do
* this up-front so that we can properly return -EINVAL if there is
* a syncobj with a missing fence and then never have the chance of
@@ -998,7 +1013,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
signaled_count = 0;
for (i = 0; i < count; ++i) {
entries[i].task = current;
- ret = drm_syncobj_search_fence(syncobjs[i], 0, 0,
+ ret = drm_syncobj_search_fence(syncobjs[i], points[i], 0,
&entries[i].fence);
if (!entries[i].fence) {
ret = -EINVAL;
@@ -1084,6 +1099,9 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
}
kfree(entries);
+err_free_points:
+ kfree(points);
+
return ret;
}
@@ -1122,20 +1140,33 @@ static signed long drm_timeout_abs_to_jiffies(int64_t
timeout_nsec)
static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_file *file_private,
struct drm_syncobj_wait *wait,
- struct drm_syncobj **syncobjs)
+ struct drm_syncobj_timeline_wait
*timeline_wait,
+ struct drm_syncobj **syncobjs, bool timeline)
{
- signed long tim
[PATCH 7/9] drm: add timeline syncobj payload query ioctl
user mode can query timeline payload.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 53 ++
include/uapi/drm/drm.h | 11 +++
4 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 1bdbf2273b49..3a176e11b4ff 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -184,6 +184,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 92d94867746b..cfd1de44a4cc 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -675,6 +675,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index bcb3ba002985..8466fb38fa19 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1372,3 +1372,56 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+
+static void drm_syncobj_timeline_query_payload(struct drm_syncobj *syncobj,
+ uint64_t *point)
+{
+ if (syncobj->type != DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("Normal syncobj cann't be queried!");
+ *point = 0;
+ return;
+ }
+ *point = syncobj->syncobj_timeline.signal_point;
+}
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_query *args = data;
+ struct drm_syncobj **syncobjs;
+ uint64_t *points;
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+
+ points = kmalloc_array(args->count_handles, sizeof(*points),
+ GFP_KERNEL);
+ if (points == NULL) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0; i < args->count_handles; i++) {
+ drm_syncobj_timeline_query_payload(syncobjs[i], &points[i]);
+ copy_to_user(u64_to_user_ptr(args->points), points,
+sizeof(uint64_t) * args->count_handles);
+ }
+
+ kfree(points);
+out:
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 501e86d81f47..188b63f1975b 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -767,6 +767,15 @@ struct drm_syncobj_array {
__u32 pad;
};
+struct drm_syncobj_timeline_query {
+ __u64 handles;
+ /* points are timeline syncobjs payloads returned by query ioctl */
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -924,6 +933,8 @@ extern "C" {
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_query)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing lis
[PATCH libdrm 1/5] [libdrm] sync drm.h for syncobj part
Signed-off-by: Chunming Zhou
---
include/drm/drm.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0bd91de..d1688269 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -695,6 +695,7 @@ struct drm_prime_handle {
struct drm_syncobj_create {
__u32 handle;
#define DRM_SYNCOBJ_CREATE_SIGNALED (1 << 0)
+#define DRM_SYNCOBJ_CREATE_TYPE_TIMELINE (1 << 1)
__u32 flags;
};
@@ -725,12 +726,32 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+__u64 handles;
+/* wait on specific timeline point for every handles*/
+__u64 points;
+/* absolute timeout */
+__s64 timeout_nsec;
+__u32 count_handles;
+__u32 flags;
+__u32 first_signaled; /* only valid when not waiting all */
+__u32 pad;
+};
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_query {
+__u64 handles;
+/* points are timeline syncobjs payloads returned by query ioctl */
+__u64 points;
+__u32 count_handles;
+__u32 pad;
+};
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -887,6 +908,9 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
drm_syncobj_timeline_query)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/5] [libdrm]: add timeline wait/query ioctl
Signed-off-by: Chunming Zhou
---
xf86drm.c | 44
xf86drm.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index b2388194..0cd1cb75 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4249,3 +4249,47 @@ int drmSyncobjSignal(int fd, const uint32_t *handles,
uint32_t handle_count)
ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_SIGNAL, &args);
return ret;
}
+
+int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+struct drm_syncobj_timeline_wait args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.timeout_nsec = timeout_nsec;
+args.count_handles = num_handles;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, &args);
+if (ret < 0)
+return -errno;
+
+if (first_signaled)
+*first_signaled = args.first_signaled;
+return ret;
+}
+
+
+int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count)
+{
+struct drm_syncobj_timeline_query args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, &args);
+if (ret)
+return ret;
+return 0;
+}
+
+
diff --git a/xf86drm.h b/xf86drm.h
index 7773d71a..49a40633 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -875,6 +875,12 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/5] [libdrm] addr cs chunk for syncobj timeline
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index c363b67f..04663a13 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -482,6 +482,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_DEPENDENCIES 0x03
#define AMDGPU_CHUNK_ID_SYNCOBJ_IN 0x04
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x08
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -553,6 +555,13 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
};
+struct drm_amdgpu_cs_chunk_syncobj {
+ __u32 handle;
+ __u32 pad;
+ __u64 point;
+};
+
+
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD 1
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 4/5] [libdrm]: wrap syncobj timeline query and wait for amdgpu
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h| 39 ++
amdgpu/amdgpu_cs.c | 24 +++
3 files changed, 65 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 58646e85..4f91be54 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -50,6 +50,8 @@ amdgpu_cs_syncobj_import_sync_file
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
amdgpu_cs_syncobj_wait
+amdgpu_cs_syncobj_timeline_wait
+amdgpu_cs_syncobj_query
amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
amdgpu_device_deinitialize
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dc51659a..330658a0 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1489,6 +1489,45 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
+/**
+ * Wait for one or all sync objects on their points to signal.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [in] array of sync points to wait
+ * \param num_handles - \c [in] self-explanatory
+ * \param timeout_nsec - \c [in] self-explanatory
+ * \param flags - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param first_signaled - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+/**
+ * Query sync objects payloads.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param num_handles - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles);
+
/**
* Export kernel sync object to shareable fd.
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 3c9be6c2..b32c0a75 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -658,6 +658,30 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
flags, first_signaled);
}
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineWait(dev->fd, handles, points, num_handles,
+ timeout_nsec, flags, first_signaled);
+}
+
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjQuery(dev->fd, handles, points, num_handles);
+}
+
+
int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 5/5] [libdrm] add syncobj timeline tests
Signed-off-by: Chunming Zhou
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 12 ++
tests/amdgpu/amdgpu_test.h | 21 +++
tests/amdgpu/meson.build | 2 +-
tests/amdgpu/syncobj_tests.c | 258 +++
5 files changed, 294 insertions(+), 2 deletions(-)
create mode 100644 tests/amdgpu/syncobj_tests.c
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index e79c1bd3..61f2b426 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -32,4 +32,5 @@ amdgpu_test_SOURCES = \
vcn_tests.c \
uve_ib.h \
deadlock_tests.c \
- vm_tests.c
+ vm_tests.c \
+ syncobj_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 96fcd687..cdcb93a5 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -56,6 +56,7 @@
#define UVD_ENC_TESTS_STR "UVD ENC Tests"
#define DEADLOCK_TESTS_STR "Deadlock Tests"
#define VM_TESTS_STR "VM Tests"
+#define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
/**
* Open handles for amdgpu devices
@@ -116,6 +117,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_vm_tests_clean,
.pTests = vm_tests,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pInitFunc = suite_syncobj_timeline_tests_init,
+ .pCleanupFunc = suite_syncobj_timeline_tests_clean,
+ .pTests = syncobj_timeline_tests,
+ },
CU_SUITE_INFO_NULL,
};
@@ -165,6 +172,11 @@ static Suites_Active_Status suites_active_stat[] = {
.pName = VM_TESTS_STR,
.pActive = suite_vm_tests_enable,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pActive = suite_syncobj_timeline_tests_enable,
+ },
+
};
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index f2ece3c3..960df046 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -194,6 +194,27 @@ CU_BOOL suite_vm_tests_enable(void);
*/
extern CU_TestInfo vm_tests[];
+/**
+ * Initialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_init();
+
+/**
+ * Deinitialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_syncobj_timeline_tests_enable(void);
+
+/**
+ * Tests in syncobj timeline test suite
+ */
+extern CU_TestInfo syncobj_timeline_tests[];
+
+
/**
* Helper functions
*/
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 4c1237c6..3ceec715 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
files(
'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
- 'vm_tests.c',
+ 'vm_tests.c', 'syncobj_tests.c',
),
dependencies : [dep_cunit, dep_threads],
include_directories : [inc_root, inc_drm,
include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
new file mode 100644
index ..196c66d2
--- /dev/null
+++ b/tests/amdgpu/syncobj_tests.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void amdgpu_syncobj_timeline_test(void);
+
+CU_BOOL suite_syncobj_timeline_tests_enable(void)
+{
+ return CU_TRUE;
+}
+
+int suite_syncobj_timeline_tests_init(void)
+{
+ int r;
+
+ r = amdgpu
Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results
> > in
> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
> > module:
> >
> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> > ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> >
> > This solves the problem by adding a silent symbol for the tcon_top module,
> > building it as a separate module in exactly the cases that we need it,
> > but in a way that it is reachable by the other modules.
> >
> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching mixers
> > with tcon")
> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
> > Tested-by: Jon Hunter
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Daniel Vetter
>
> But I can't help myself and drop the usual questions when I see a small
> soc driver with more Kconfigs than anything else ... is all this pain
> worth it? I know that maybe the desktop approach of stuffing half a
> million lines of driver code into one .ko might be a bit too much for
> socs, but this seems overkill.
>
> I'm also pretty sure it's not justified by any real data, compared to
> overall code size of a drm stack, that shows it's a substantial enough
> saving that it's worth it.
I'm currently running on a project where the boot time to a qt
application from power off should be less than a second. You want to
remove anything you can spare in some situations. And yeah, DRM is the
biggest thing in the way to do that.
> Imo, if you really care about building a minimal driver, stuff everything
> into one .ko and then LTO out the uneeded bits. We've done these
> experiments for i915, that _actually_ saves a ton of binary size, with
> fairly minimal code and maintenance impact. Still, we decided the payoff
> is simply too small to bother making it a production thing.
LTO isn't enabled yet in mainline, is it?
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: [PATCH libdrm 4/5] [libdrm]: wrap syncobj timeline query and wait for amdgpu
On 2018-09-12 11:50 a.m., Chunming Zhou wrote: > Signed-off-by: Chunming Zhou > --- > amdgpu/amdgpu-symbol-check | 2 ++ > amdgpu/amdgpu.h| 39 ++ > amdgpu/amdgpu_cs.c | 24 +++ > 3 files changed, 65 insertions(+) > > diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check > index 58646e85..4f91be54 100755 > --- a/amdgpu/amdgpu-symbol-check > +++ b/amdgpu/amdgpu-symbol-check > @@ -50,6 +50,8 @@ amdgpu_cs_syncobj_import_sync_file > amdgpu_cs_syncobj_reset > amdgpu_cs_syncobj_signal > amdgpu_cs_syncobj_wait > +amdgpu_cs_syncobj_timeline_wait > +amdgpu_cs_syncobj_query > amdgpu_cs_wait_fences > amdgpu_cs_wait_semaphore > amdgpu_device_deinitialize This file should be sorted in lexical order. -- 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 05/20] drm/meson: Use drm_fbdev_generic_setup()
On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: > Hi Noralf, > > On 08/09/2018 15:46, Noralf Trønnes wrote: > > The CMA helper is already using the drm_fb_helper_generic_probe part of > > the generic fbdev emulation. This patch makes full use of the generic > > fbdev emulation by using its drm_client callbacks. This means that > > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > > now handled by the emulation code. Additionally fbdev unregister happens > > automatically on drm_dev_unregister(). > > > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > > driver. This is done to highlight the fact that fbdev emulation is an > > internal client that makes use of the driver, it is not part of the > > driver as such. If fbdev setup fails, an error is printed, but the driver > > succeeds probing. > > I can't really ack/nack this move, on one side it's great to have a > generic fbdev emulation instead of the old fbdev code, but on the > other side the Amlogic platform (like allwinner, samsung, rockchip, > ...) still relies on an Fbdev variant of the libMali that uses > smem_start... > > I know it's dirty and fbdev based code should be legacy now, but I > consider it like an user-space breakage... > > I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that > could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM > driver, it won't be the case and it will never be the case until the > Lima projects finalizes. > > So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. 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 107898] "kfd: Failed to resume IOMMU for device 1002:15dd" on Raven Ridge
https://bugs.freedesktop.org/show_bug.cgi?id=107898 --- Comment #5 from Marvin Damschen --- Output with patch applied: Sep 12 12:08:20 zen kernel: kfd kfd: Allocated 3969056 bytes on gart Sep 12 12:08:20 zen kernel: Topology: Add APU node [0x15dd:0x1002] Sep 12 12:08:20 zen kernel: Failed to attache to group Sep 12 12:08:20 zen kernel: amd_iommu_init_device failed: -22 Sep 12 12:08:20 zen kernel: kfd kfd: Failed to resume IOMMU for device 1002:15dd Sep 12 12:08:20 zen kernel: Creating topology SYSFS entries Sep 12 12:08:20 zen kernel: kfd kfd: device 1002:15dd NOT added due to errors Full log attached. Thank you Marvin -- 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
[Bug 107898] "kfd: Failed to resume IOMMU for device 1002:15dd" on Raven Ridge
https://bugs.freedesktop.org/show_bug.cgi?id=107898 Marvin Damschen changed: What|Removed |Added Attachment #141520|0 |1 is obsolete|| --- Comment #6 from Marvin Damschen --- Created attachment 141533 --> https://bugs.freedesktop.org/attachment.cgi?id=141533&action=edit dmesg 4.19-rc3 with iommu init instrumentation -- 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 1/3] [RFC]drm: add syncobj timeline support v4
On 2018年09月12日 15:22, Christian König wrote:
Ping? Have you seen my comments here?
Sorry, I didn't see this reply. inline...
Looks like you haven't addressed any of them in your last mail.
Christian.
Am 06.09.2018 um 09:25 schrieb Christian König:
Am 06.09.2018 um 08:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an
integer payload
identifying a point in a timeline. Such timeline semaphores support the
Drop the term semaphore here, better use syncobj.
This is from VK_KHR_timeline_semaphore extension describe, not my
invention, I just quote it. In kernel side, we call syncobj, in UMD,
they still call semaphore.
following operations:
* CPU query - A host operation that allows querying the payload
of the
timeline semaphore.
* CPU wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is
signaled before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion
fence, when PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when
timeline is increasing, will compare
wait PTs value with new timeline value, if PT value is lower than
timeline value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait
on any point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal
PT, we need a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate
patch. (Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate
patch.
5. drop the submission_fence implementation and instead use
wait_event() for that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and
Christian)
a. normal syncobj signal op will create a signal PT to tail of
signal pt list.
b. normal syncobj wait op will create a wait pt with last
signal point, and this wait PT is only signaled by related signal
point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
Tested by ./deqp-vk -n dEQP-VK*semaphore* for normal syncobj
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 516
+
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 78 ++--
include/uapi/drm/drm.h | 1 +
4 files changed, 448 insertions(+), 151 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..94b31de23858 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval
is 1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,18 @@ static const struct dma_fence_ops
drm_syncobj_stub_fence_ops = {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64 value;
+ struct list_head list;
+};
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_pt_fence;
+ struct dma_fence_cb wait_cb;
+ struct rb_node node;
+ u64 value;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -109,61 +124,238 @@ struct drm_syncobj *drm_syncobj_find(struct
drm_file *file_private,
}
EXPORT_SYMBOL(drm_syncobj_find);
-static void drm_syncobj_add_callback_locked(struct drm_syncobj
*syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func)
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj,
+ struct drm_syncobj_timeline *syncobj_timeline)
Since we merged timeline and singleton syncobj you can drop the extra
_timeline_ part in the function name I think.
Will try in v5.
{
- cb->func = func;
- list_add_tail(&cb->node, &syncobj->cb_list);
+
[PATCH v2 2/4] drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
From: Vidya Srinivas
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c80e569..d90d51c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6506,6 +6506,9 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210(1 << 23)
+#define PLANE_CTL_FORMAT_Y212(3 << 23)
+#define PLANE_CTL_FORMAT_Y216(5 << 23)
#define PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] Enable Y210, Y212, Y216 formats for ICL
These patches enable packed format YUV422-Y210, Y212 and Y216 for 10, 12 and 16 bit respectively for ICL. For user space component IGT:WIP v2: addressed review comments of mahesh and alexandru hdr handling of these 64 bit pixel format not inscope of this series Vidya Srinivas (4): drm: Add Y210, Y212, Y216 format definitions and fourcc drm/i915/icl: Add Y210, Y212, Y216 plane control definitions drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes drivers/gpu/drm/drm_fourcc.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_display.c | 40 ++-- drivers/gpu/drm/i915/intel_sprite.c | 25 -- include/uapi/drm/drm_fourcc.h| 8 5 files changed, 75 insertions(+), 4 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
From: Vidya Srinivas
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies a DWORD.
Y210:Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:Valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:Valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
v2: is_yuv setted to true (mahesh)
different order of yuv samples (mahesh): still update from
hardware team pending
change in comment (alexandru)
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aa..143c26a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -190,6 +190,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b..95118cc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,14 @@
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
+
+/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
* index 1 = A plane, [7:0] A
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
From: Vidya Srinivas
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_sprite.c | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2b77d93..7c68a0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3512,6 +3512,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
default:
MISSING_CASE(pixel_format);
}
@@ -4960,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
@@ -13422,6 +13431,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
@@ -14551,6 +14563,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
drm_get_format_name(mode_cmd->pixel_format, &format_name));
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 9600ccf..f7e2768 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1419,6 +1419,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes
From: Vidya Srinivas
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_sprite.c | 22 --
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c68a0d..f341cbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -105,6 +105,24 @@
DRM_FORMAT_NV12,
};
+static const uint32_t icl_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13725,8 +13743,11 @@ bool skl_plane_has_planar(struct drm_i915_private
*dev_priv,
if (INTEL_GEN(dev_priv) >= 9) {
primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
PLANE_PRIMARY);
-
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ intel_primary_formats = icl_primary_formats;
+ num_formats = ARRAY_SIZE(icl_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_PRIMARY)) {
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f7e2768..2e61fe19 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1281,6 +1281,21 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1536,8 +1551,11 @@ struct intel_plane *
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- if (skl_plane_has_planar(dev_priv, pipe,
-PLANE_SPRITE0 + plane)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ plane_formats = icl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(icl_plane_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_SPRITE0 + plane)) {
plane_formats = skl_planar_formats;
num_plane_formats = ARRAY_SIZE(skl_planar_formats);
} else {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
On Tuesday, 2018-09-11 14:22:24 -0700, Rodrigo Vivi wrote:
> From: Emil Velikov
>
> They're used internally and never meant to be part of the API.
> Add the drm_private notation, which should resolve that.
>
> v2: (Rodrigo) Add missing include.
>
> Cc: Eric Engestrom
> Cc: Lucas De Marchi
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
> Signed-off-by: Emil Velikov
> Acked-by: Lucas De Marchi
> Signed-off-by: Rodrigo Vivi
> ---
> intel/intel_chipset.c | 4 ++--
> intel/intel_chipset.h | 6 --
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> index d5c33cc5..5aa4a2f2 100644
> --- a/intel/intel_chipset.c
> +++ b/intel/intel_chipset.c
> @@ -44,7 +44,7 @@ static const struct pci_device {
> INTEL_SKL_IDS(9),
> };
>
> -bool intel_is_genx(unsigned int devid, int gen)
> +drm_private bool intel_is_genx(unsigned int devid, int gen)
> {
> const struct pci_device *p,
> *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> @@ -66,7 +66,7 @@ bool intel_is_genx(unsigned int devid, int gen)
> return false;
> }
>
> -bool intel_get_genx(unsigned int devid, int *gen)
> +drm_private bool intel_get_genx(unsigned int devid, int *gen)
> {
> const struct pci_device *p,
> *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 9b1e64f1..990a81e8 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -28,6 +28,8 @@
> #ifndef _INTEL_CHIPSET_H
> #define _INTEL_CHIPSET_H
>
> +#include
Good catch on the missing #include :)
Might want to move it to keep it grouped with the other #include below,
but other than that:
Reviewed-by: Eric Engestrom
> +
> #define PCI_CHIP_I8100x7121
> #define PCI_CHIP_I810_DC100 0x7123
> #define PCI_CHIP_I810_E 0x7125
> @@ -330,8 +332,8 @@
> /* New platforms use kernel pci ids */
> #include
>
> -bool intel_is_genx(unsigned int devid, int gen);
> -bool intel_get_genx(unsigned int devid, int *gen);
> +drm_private bool intel_is_genx(unsigned int devid, int gen);
> +drm_private bool intel_get_genx(unsigned int devid, int *gen);
>
> #define IS_GEN9(devid) intel_is_genx(devid, 9)
> #define IS_GEN10(devid) intel_is_genx(devid, 10)
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Don't disable polling in fallback mode
When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling. Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.
Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan
control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
Reported-by: Thomas Blume
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 3695cde669f8..07914e36939e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -132,11 +132,12 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
duty = nvkm_therm_update_linear(therm);
break;
case NVBIOS_THERM_FAN_OTHER:
- if (therm->cstate)
+ if (therm->cstate) {
duty = therm->cstate;
- else
+ poll = false;
+ } else {
duty = nvkm_therm_update_linear_fallback(therm);
- poll = false;
+ }
break;
}
immd = false;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
(Cc: Daniel Vetter) Den 12.09.2018 11.56, skrev Maxime Ripard: On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: Hi Noralf, On 08/09/2018 15:46, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. I can't really ack/nack this move, on one side it's great to have a generic fbdev emulation instead of the old fbdev code, but on the other side the Amlogic platform (like allwinner, samsung, rockchip, ...) still relies on an Fbdev variant of the libMali that uses smem_start... I know it's dirty and fbdev based code should be legacy now, but I consider it like an user-space breakage... I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM driver, it won't be the case and it will never be the case until the Lima projects finalizes. So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. I don't know the reasoning for blocking smem_start other than what Daniel wrote in these commit messages: da6c7707caf3736c1cf968606bd97c07e79625d4 fbdev: Add FBINFO_HIDE_SMEM_START flag DRM drivers really, really, really don't want random userspace to share buffer behind it's back, bypassing the dma-buf buffer sharing machanism. For that reason we've ruthlessly rejected any IOCTL exposing the physical address of any graphics buffer. Unfortunately fbdev comes with that built-in. We could just set smem_start to 0, but that means we'd have to hand-roll our own fb_mmap implementation. For good reasons many drivers do that, but smem_start/length is still super convenient. Hence instead just stop the leak in the ioctl, to keep fb mmap working as-is. A second patch will set this flag for all drm drivers. 6be8f3bd2c78915a9f3a058a346ae93068d35c01 drm/fb: Stop leaking physical address For buffer sharing, use dma-buf instead. We can't set smem_start to 0 unconditionally since that's used by the fbdev mmap default implementation. And we have plenty of userspace which would like to keep that working. This might break legit userspace - if it does we need to look at a case-by-cases basis how to handle that. Worst case I expect overrides for only specific drivers, since anything remotely modern should be using dma-buf/prime now (which is about 7 years old now for DRM drivers). This issue was uncovered because Noralf's rework to implement a generic fb_probe also implements it's own fb_mmap callback. Which means smem_start didn't have to be set anymore, which blew up some blob in userspace rather badly. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107891] [wine, regression, bisected] RAGE, Wolfenstein The New Order hangs in menu
https://bugs.freedesktop.org/show_bug.cgi?id=107891 --- Comment #1 from Timothy Arceri --- Thanks for another quality bug report! I've sent a patch to revert the change for now. https://patchwork.freedesktop.org/patch/249030/ -- 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 1/3] [RFC]drm: add syncobj timeline support v4
Am 12.09.2018 um 12:20 schrieb zhoucm1:
[SNIP]
Drop the term semaphore here, better use syncobj.
This is from VK_KHR_timeline_semaphore extension describe, not my
invention, I just quote it. In kernel side, we call syncobj, in UMD,
they still call semaphore.
Yeah, but we don't care about close source UMD names in the kernel and
the open source UMD calls it syncobj as well.
[SNIP]
+static void drm_syncobj_find_signal_pt_for_wait_pt(struct
drm_syncobj *syncobj,
+ struct drm_syncobj_wait_pt *wait_pt)
+{
That whole approach still looks horrible complicated to me.
It's already very close to what you said before.
Especially the separation of signal and wait pt is completely
unnecessary as far as I can see.
When a wait pt is requested we just need to search for the signal
point which it will trigger.
Yeah, I tried this, but when I implement cpu wait ioctl on specific
point, we need a advanced wait pt fence, otherwise, we could still
need old syncobj cb.
Why? I mean you just need to call drm_syncobj_find_fence() and when that
one returns NULL you use wait_event_*() to wait for a signal point >=
your wait point to appear and try again.
Regards,
Christian.
Thanks,
David Zhou
Regards,
Christian.
+ struct drm_syncobj_timeline *timeline =
&syncobj->syncobj_timeline;
+ struct drm_syncobj_signal_pt *signal_pt;
+ int ret;
+
+ if (wait_pt->signal_pt_fence) {
+ return;
+ } else if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
+ (wait_pt->value <= timeline->timeline)) {
+ dma_fence_signal(&wait_pt->base.base);
+ rb_erase(&wait_pt->node,
+ &timeline->wait_pt_tree);
+ RB_CLEAR_NODE(&wait_pt->node);
+ dma_fence_put(&wait_pt->base.base);
+ return;
+ }
+
+ list_for_each_entry(signal_pt, &timeline->signal_pt_list, list) {
+ if (wait_pt->value < signal_pt->value)
+ continue;
+ if ((syncobj->type == DRM_SYNCOBJ_TYPE_NORMAL) &&
+ (wait_pt->value != signal_pt->value))
+ continue;
+ wait_pt->signal_pt_fence =
dma_fence_get(&signal_pt->base->base);
+ ret = dma_fence_add_callback(wait_pt->signal_pt_fence,
+ &wait_pt->wait_cb,
+ wait_pt_func);
+ if (ret == -ENOENT) {
+ dma_fence_signal(&wait_pt->base.base);
+ dma_fence_put(wait_pt->signal_pt_fence);
+ wait_pt->signal_pt_fence = NULL;
+ rb_erase(&wait_pt->node,
+ &timeline->wait_pt_tree);
+ RB_CLEAR_NODE(&wait_pt->node);
+ dma_fence_put(&wait_pt->base.base);
+ } else if (ret < 0) {
+ dma_fence_put(wait_pt->signal_pt_fence);
+ DRM_ERROR("add callback error!");
+ } else {
+ /* after adding callback, remove from rb tree */
+ rb_erase(&wait_pt->node,
+ &timeline->wait_pt_tree);
+ RB_CLEAR_NODE(&wait_pt->node);
+ }
+ return;
+ }
+ /* signaled pt was released */
+ if (!wait_pt->signal_pt_fence && (wait_pt->value <=
+ timeline->signal_point)) {
+ dma_fence_signal(&wait_pt->base.base);
+ rb_erase(&wait_pt->node,
+ &timeline->wait_pt_tree);
+ RB_CLEAR_NODE(&wait_pt->node);
+ dma_fence_put(&wait_pt->base.base);
+ }
}
-void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func)
+static int drm_syncobj_timeline_create_signal_pt(struct
drm_syncobj *syncobj,
+ struct dma_fence *fence,
+ u64 point)
{
+ struct drm_syncobj_signal_pt *signal_pt =
+ kzalloc(sizeof(struct drm_syncobj_signal_pt), GFP_KERNEL);
+ struct drm_syncobj_signal_pt *tail_pt;
+ struct dma_fence **fences;
+ struct rb_node *node;
+ struct drm_syncobj_wait_pt *tail_wait_pt = NULL;
+ int num_fences = 0;
+ int ret = 0, i;
+
+ if (!signal_pt)
+ return -ENOMEM;
+ if (syncobj->syncobj_timeline.signal_point >= point) {
+ DRM_WARN("A later signal is ready!");
+ goto out;
+ }
+ if (!fence)
+ goto out;
+
+ fences = kmalloc_array(sizeof(void *), 2, GFP_KERNEL);
+ if (!fences)
+ goto out;
+ fences[num_fences++] = dma_fence_get(fence);
+ /* timeline syncobj must take this dependency */
+ if (syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) {
+ spin_lock(&syncobj->lock);
+ if (!list_empty(&syncobj->syncobj_timeline.signal_pt_list)) {
+ tail_pt =
list_last_entry(&syncobj->syncobj_timeline.signal_pt_list,
+ struct drm_syncobj_signal_pt, list);
+ fences[num_fences++] =
dma_fence_get(&tail_pt->base->base);
+ }
+ spin_unlock(&syncobj->lock);
+ }
+ signal_pt->base = dma_fence_array_create(num_fences, fences,
+ syncobj->syncobj_timeli
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Den 12.09.2018 12.57, skrev Noralf Trønnes: (Cc: Daniel Vetter) Somehow that CC was dropped somewhere after leaving email client. Trying once more. Den 12.09.2018 11.56, skrev Maxime Ripard: On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: Hi Noralf, On 08/09/2018 15:46, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. I can't really ack/nack this move, on one side it's great to have a generic fbdev emulation instead of the old fbdev code, but on the other side the Amlogic platform (like allwinner, samsung, rockchip, ...) still relies on an Fbdev variant of the libMali that uses smem_start... I know it's dirty and fbdev based code should be legacy now, but I consider it like an user-space breakage... I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM driver, it won't be the case and it will never be the case until the Lima projects finalizes. So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. I don't know the reasoning for blocking smem_start other than what Daniel wrote in these commit messages: da6c7707caf3736c1cf968606bd97c07e79625d4 fbdev: Add FBINFO_HIDE_SMEM_START flag DRM drivers really, really, really don't want random userspace to share buffer behind it's back, bypassing the dma-buf buffer sharing machanism. For that reason we've ruthlessly rejected any IOCTL exposing the physical address of any graphics buffer. Unfortunately fbdev comes with that built-in. We could just set smem_start to 0, but that means we'd have to hand-roll our own fb_mmap implementation. For good reasons many drivers do that, but smem_start/length is still super convenient. Hence instead just stop the leak in the ioctl, to keep fb mmap working as-is. A second patch will set this flag for all drm drivers. 6be8f3bd2c78915a9f3a058a346ae93068d35c01 drm/fb: Stop leaking physical address For buffer sharing, use dma-buf instead. We can't set smem_start to 0 unconditionally since that's used by the fbdev mmap default implementation. And we have plenty of userspace which would like to keep that working. This might break legit userspace - if it does we need to look at a case-by-cases basis how to handle that. Worst case I expect overrides for only specific drivers, since anything remotely modern should be using dma-buf/prime now (which is about 7 years old now for DRM drivers). This issue was uncovered because Noralf's rework to implement a generic fb_probe also implements it's own fb_mmap callback. Which means smem_start didn't have to be set anymore, which blew up some blob in userspace rather badly. Noralf. ___ 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
Re: [PATCH v2 2/4] drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c80e569..d90d51c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6506,6 +6506,9 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565(14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK (0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE (1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210(1 << 23)
+#define PLANE_CTL_FORMAT_Y212(3 << 23)
+#define PLANE_CTL_FORMAT_Y216(5 << 23)
#define PLANE_CTL_KEY_ENABLE_MASK (0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION(2 << 21)
Reviewed-by: Juha-Pekka Heikkila
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies a DWORD.
Just to be clear I wouldn't use 'DWORD' here but if it's 64 bits bits
call it so. Not a big issue as its just in the patch comment but still.
Y210:Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:Valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:Valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
v2: is_yuv setted to true (mahesh)
different order of yuv samples (mahesh): still update from
hardware team pending
change in comment (alexandru)
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aa..143c26a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -190,6 +190,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b..95118cc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,14 @@
#define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
I think what Alexandru-Cosmin Gheorghe meant with earlier review comment
is these defines should be better explained here in part which will be
visible in header file. Looking how other formats have been commented
this would probably be something along the lines of
#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /*
[63:0] Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
or something.
/Juha-Pekka
+
+/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
* index 1 = A plane, [7:0] A
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/27] clk: sunxi-ng: Add support for H6 DE3 clocks
On Wed, Sep 5, 2018 at 1:46 AM Jernej Škrabec wrote:
>
> Dne torek, 04. september 2018 ob 11:04:21 CEST je Chen-Yu Tsai napisal(a):
> > On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec
> wrote:
> > > Support for mixer0, mixer1, writeback and rotation units is added.
> > >
> > > Signed-off-by: Jernej Skrabec
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > >
> > > drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 65
> > > drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 1 +
> > > 2 files changed, 66 insertions(+)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> > > b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c index bae5ee67a797..4535c1c27d27
> > > 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> > > @@ -31,6 +31,8 @@ static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1",
> > > "bus-de",>
> > > 0x04, BIT(1), 0);
> > >
> > > static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
> > >
> > > 0x04, BIT(2), 0);
> > >
> > > +static SUNXI_CCU_GATE(bus_rot_clk, "bus-rot", "bus-de",
> > > + 0x04, BIT(3), 0);
> > >
> > > static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
> > >
> > > 0x00, BIT(0), CLK_SET_RATE_PARENT);
> > >
> > > @@ -38,6 +40,8 @@ static SUNXI_CCU_GATE(mixer1_clk, "mixer1",
> > > "mixer1-div",>
> > > 0x00, BIT(1), CLK_SET_RATE_PARENT);
> > >
> > > static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
> > >
> > > 0x00, BIT(2), CLK_SET_RATE_PARENT);
> > >
> > > +static SUNXI_CCU_GATE(rot_clk, "rot", "rot-div",
> > > + 0x00, BIT(3), CLK_SET_RATE_PARENT);
> > >
> > > static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
> > >
> > >CLK_SET_RATE_PARENT);
> > >
> > > @@ -45,6 +49,8 @@ static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de",
> > > 0x0c, 4, 4,>
> > >CLK_SET_RATE_PARENT);
> > >
> > > static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
> > >
> > >CLK_SET_RATE_PARENT);
> > >
> > > +static SUNXI_CCU_M(rot_div_clk, "rot-div", "de", 0x0c, 0x0c, 4,
> > > + CLK_SET_RATE_PARENT);
> > >
> > > static SUNXI_CCU_M(mixer0_div_a83_clk, "mixer0-div", "pll-de", 0x0c, 0,
> > > 4,
> > >
> > >CLK_SET_RATE_PARENT);
> > >
> > > @@ -53,6 +59,24 @@ static SUNXI_CCU_M(mixer1_div_a83_clk, "mixer1-div",
> > > "pll-de", 0x0c, 4, 4,>
> > > static SUNXI_CCU_M(wb_div_a83_clk, "wb-div", "pll-de", 0x0c, 8, 4,
> > >
> > >CLK_SET_RATE_PARENT);
> > >
> > > +static struct ccu_common *sun50i_h6_de3_clks[] = {
> > > + &mixer0_clk.common,
> > > + &mixer1_clk.common,
> > > + &wb_clk.common,
> > > +
> > > + &bus_mixer0_clk.common,
> > > + &bus_mixer1_clk.common,
> > > + &bus_wb_clk.common,
> > > +
> > > + &mixer0_div_clk.common,
> > > + &mixer1_div_clk.common,
> > > + &wb_div_clk.common,
> > > +
> > > + &bus_rot_clk.common,
> > > + &rot_clk.common,
> > > + &rot_div_clk.common,
> > > +};
> > > +
> > >
> > > static struct ccu_common *sun8i_a83t_de2_clks[] = {
> > >
> > > &mixer0_clk.common,
> > > &mixer1_clk.common,
> > >
> > > @@ -92,6 +116,26 @@ static struct ccu_common *sun8i_v3s_de2_clks[] = {
> > >
> > > &wb_div_clk.common,
> > >
> > > };
> > >
> > > +static struct clk_hw_onecell_data sun50i_h6_de3_hw_clks = {
> > > + .hws= {
> > > + [CLK_MIXER0]= &mixer0_clk.common.hw,
> > > + [CLK_MIXER1]= &mixer1_clk.common.hw,
> > > + [CLK_WB]= &wb_clk.common.hw,
> > > + [CLK_ROT] = &rot_clk.common.hw,
> > > +
> > > + [CLK_BUS_MIXER0]= &bus_mixer0_clk.common.hw,
> > > + [CLK_BUS_MIXER1]= &bus_mixer1_clk.common.hw,
> > > + [CLK_BUS_WB]= &bus_wb_clk.common.hw,
> > > + [CLK_BUS_ROT] = &bus_rot_clk.common.hw,
> > > +
> > > + [CLK_MIXER0_DIV]= &mixer0_div_clk.common.hw,
> > > + [CLK_MIXER1_DIV]= &mixer1_div_clk.common.hw,
> > > + [CLK_WB_DIV]= &wb_div_clk.common.hw,
> > > + [CLK_ROT_DIV] = &rot_div_clk.common.hw,
> > > + },
> > > + .num= 12,
> >
> > It's best not to openly code these. It is error prone, like having
> > an index beyond .num, which then never gets registered.
> >
> > Instead, please update CLK_NUMBERS and use that instead. sunxi_ccu_probe()
> > can handle holes in .hws.
>
> I'm not sure this will work. All newly introduced indices are at the end, so
> other arrays will still have same length (hole at the end). You will just
> claim that arrays are larger than they really are, which means b
Re: [PATCH 15/27] drm/sun4i: Not all DW HDMI controllers has scrambled addresses
On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec wrote: > > Currently supported Allwinner SoCs with DW HDMI controller have > scrambled addresses and read lock. However, that is not true in general. > For example, A80 and H6 have normal addresses and normal read access. > > Move code for unscrambling addresses and unlocking read access to it's > own function and call it from init function. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/27] drm/sun4i: Add support for H6 DW HDMI controller
On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec wrote:
>
> H6 has DW HDMI 2.0 controller v2.12a.
>
> It supports 4K at 60 Hz and HDCP 2.2.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> index 16a0c7a88ea8..44143c9f20d0 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -43,6 +43,16 @@ sun8i_dw_hdmi_mode_valid_a83t(struct drm_connector
> *connector,
> return MODE_OK;
> }
>
> +static enum drm_mode_status
> +sun8i_dw_hdmi_mode_valid_h6(struct drm_connector *connector,
> + const struct drm_display_mode *mode)
> +{
> + if (mode->clock > 60)
600 MHz seems slightly arbitrary. AFAIK the dot clock for 4K 60Hz is 594 MHz?
A comment on this limit would be nice.
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
> {
> return IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
> @@ -220,12 +230,20 @@ static int sun8i_dw_hdmi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
> + .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
> +};
> +
Please "version" sort the SoC families and models.
> static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
> .mode_valid = sun8i_dw_hdmi_mode_valid_a83t,
> .set_rate = true,
> };
>
> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
> + {
> + .compatible = "allwinner,sun50i-h6-dw-hdmi",
> + .data = &sun50i_h6_quirks,
> + },
Here also.
Once fixed,
Reviewed-by: Chen-Yu Tsai
> {
> .compatible = "allwinner,sun8i-a83t-dw-hdmi",
> .data = &sun8i_a83t_quirks,
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/6] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct.
As the chip-data that occupies the phy_data pointer initially gets
assigned to the rockchip_hdmi struct, we can now re-use this phy_data
pointer to hold the reference to the rockchip_hdmi struct and use this
reference later on.
Inspiration for this comes from meson and sunxi dw-hdmi, which are using
the same method.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
changes in v3:
- reword commit message
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 57e76dfd5f6d..19f002fa0a09 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -335,7 +335,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
+ struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -350,9 +350,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ plat_data = devm_kmemdup(&pdev->dev, match->data,
+sizeof(*plat_data), GFP_KERNEL);
+ if (!plat_data)
+ return -ENOMEM;
+
hdmi->dev = &pdev->dev;
hdmi->chip_data = plat_data->phy_data;
+ plat_data->phy_data = hdmi;
encoder = &hdmi->encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/6] drm/bridge: dw-hdmi: allow forcing vendor phy-type
In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
vendor-type phy from Innosilicon but still report the HDMI20_TX type.
So allow the glue driver to force the vendor-phy for these cases.
In the future it may be necessary to allow forcing other types, but
for now we'll keep it simply to the case actually seen in the wild.
changes in v3:
- only allow forcing vendor type, as suggested by Laurent
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++-
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5971976284bf..ac37c50d6c4b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2205,7 +2205,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
unsigned int i;
u8 phy_type;
- phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+ phy_type = hdmi->plat_data->phy_force_vendor ?
+ DW_HDMI_PHY_VENDOR_PHY :
+ hdmi_readb(hdmi, HDMI_CONFIG2_ID);
if (phy_type == DW_HDMI_PHY_VENDOR_PHY) {
/* Vendor PHYs require support from the glue layer. */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ccb5aa8468e0..6ef3236bb6dd 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -133,6 +133,7 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_phy_ops *phy_ops;
const char *phy_name;
void *phy_data;
+ bool phy_force_vendor;
/* Synopsys PHY support */
const struct dw_hdmi_mpll_config *mpll_cfg;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/6] drm/rockchip: hdmi support for rk3328
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy from Innosilicon that resides completely separate from the dw-hdmi block and gets accessed via mmio. Additionally the rk3328 dw-hdmi does not report the vendor-phy type but a different one instead, so add the possibility to override the phy type when the glue driver knows better than the ip block itself. changes in v5: - disable CEC_5V option to make CEC actually work (Jonas) changes in v4: - rebased onto 4.19-rc2 - no actual changes - added Rob's Ack on the dw-hdmi compatible changes in v3: - split off phy driver into a separate series - only allow forcing vendor phy type - wording fixes and other nits changes in v2: - phy: prevent overflow in tmdsclk calculation as reported by Martin Cerveny - phy: use unsigned long for all tmdsclk rate uses - phy: simplify tmds rate calculation - dropped patch exporting some dw-hdmi phy functions as a similar patch entered drm-misc already Heiko Stuebner (6): drm/bridge: dw-hdmi: allow forcing vendor phy-type drm/rockchip: dw_hdmi: Allow outputs that don't need output switching dt-bindings: allow optional phys in Rockchip dw_hdmi binding drm/rockchip: dw_hdmi: allow including external phys drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328 .../display/rockchip/dw_hdmi-rockchip.txt | 3 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 126 +- include/drm/bridge/dw_hdmi.h | 1 + 4 files changed, 130 insertions(+), 4 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
The rk3328 uses a dw-hdmi controller with an external hdmi phy from
Innosilicon which uses the generic phy framework for access.
Add the necessary data and the compatible for the rk3328 to the
rockchip dw-hdmi driver.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
Acked-by: Rob Herring
changes in v5:
- disable CEC_5V option to make CEC actually work (Jonas)
changes in v3:
- reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
---
.../display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 102 ++
2 files changed, 103 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 937bfb472e1d..39143424a474 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -13,6 +13,7 @@ Required properties:
- compatible: should be one of the following:
"rockchip,rk3288-dw-hdmi"
+ "rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
- reg: See dw_hdmi.txt.
- reg-io-width: See dw_hdmi.txt. Shall be 4.
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 19f002fa0a09..0566def18d2d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -25,6 +25,24 @@
#define RK3288_GRF_SOC_CON60x025C
#define RK3288_HDMI_LCDC_SEL BIT(4)
+#define RK3328_GRF_SOC_CON20x0408
+
+#define RK3328_HDMI_SDAIN_MSK BIT(11)
+#define RK3328_HDMI_SCLIN_MSK BIT(10)
+#define RK3328_HDMI_HPD_IOEBIT(2)
+#define RK3328_GRF_SOC_CON30x040c
+/* need to be unset if hdmi or i2c should control voltage */
+#define RK3328_HDMI_SDA5V_GRF BIT(15)
+#define RK3328_HDMI_SCL5V_GRF BIT(14)
+#define RK3328_HDMI_HPD5V_GRF BIT(13)
+#define RK3328_HDMI_CEC5V_GRF BIT(12)
+#define RK3328_GRF_SOC_CON40x0410
+#define RK3328_HDMI_HPD_SARADC BIT(13)
+#define RK3328_HDMI_CEC_5V BIT(11)
+#define RK3328_HDMI_SDA_5V BIT(10)
+#define RK3328_HDMI_SCL_5V BIT(9)
+#define RK3328_HDMI_HPD_5V BIT(8)
+
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
@@ -292,6 +310,64 @@ static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
};
+static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
+struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ return phy_power_on(hdmi->phy);
+}
+
+static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void
*data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ enum drm_connector_status status;
+
+ status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+ if (status == connector_status_connected)
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V,
+ RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V));
+ else
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0, RK3328_HDMI_SDA_5V |
RK3328_HDMI_SCL_5V));
+ return status;
+}
+
+static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+ /* Enable and map pins to 3V grf-controlled io-voltage */
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0, RK3328_HDMI_HPD_SARADC | RK3328_HDMI_CEC_5V |
+RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V |
+RK3328_HDMI_HPD_5V));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON3,
+ HIWORD_UPDATE(0, RK3328_HDMI_SDA5V_GRF | RK3328_HDMI_SCL5V_GRF |
+RK3328_HDMI_HPD5V_GRF |
RK3328_HDMI_CEC5V_GRF));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON2,
+ HIWORD_UPDATE(RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK,
+ RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK |
+ RK3328_HDMI_HPD_IOE));
+}
+
static struct rockchip_hdmi_chip_dat
[PATCH v5 3/6] dt-bindings: allow optional phys in Rockchip dw_hdmi binding
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general mmio, so allow these to be referenced via the regular phy interfaces and therefore add optional phy-related properties to the binding. Signed-off-by: Heiko Stuebner Reviewed-by: Rob Herring --- .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt index adc94fc3c9f8..937bfb472e1d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -34,6 +34,8 @@ Optional properties - clock-names: May contain "cec" as defined in dw_hdmi.txt. - clock-names: May contain "grf", power for grf io. - clock-names: May contain "vpll", external clock for some hdmi phy. +- phys: from general PHY binding: the phandle for the PHY device. +- phy-names: Should be "hdmi" if phys references an external phy. Example: -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/6] drm/rockchip: dw_hdmi: allow including external phys
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b09c3531305b..57e76dfd5f6d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,7 @@ struct rockchip_hdmi {
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+ struct phy *phy;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -376,6 +378,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ hdmi->phy = devm_phy_optional_get(dev, "hdmi");
+ if (IS_ERR(hdmi->phy)) {
+ ret = PTR_ERR(hdmi->phy);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/6] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that no output-switching is necessary.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
changes in v3:
- fixed wording issue found by Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 11309a2a4e43..b09c3531305b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,7 +36,7 @@
* @lcdsel_lit: reg value of selecting vop little for HDMI
*/
struct rockchip_hdmi_chip_data {
- u32 lcdsel_grf_reg;
+ int lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
};
@@ -245,6 +245,9 @@ static void dw_hdmi_rockchip_encoder_enable(struct
drm_encoder *encoder)
u32 val;
int ret;
+ if (hdmi->chip_data->lcdsel_grf_reg < 0)
+ return;
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_sprite.c | 22 --
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c68a0d..f341cbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -105,6 +105,24 @@
DRM_FORMAT_NV12,
};
+static const uint32_t icl_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13725,8 +13743,11 @@ bool skl_plane_has_planar(struct drm_i915_private
*dev_priv,
if (INTEL_GEN(dev_priv) >= 9) {
primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
PLANE_PRIMARY);
-
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ intel_primary_formats = icl_primary_formats;
+ num_formats = ARRAY_SIZE(icl_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_PRIMARY)) {
Above doesn't look right. I think it could be written "if(gen>=11) {...}
else if(gen>=9){...". Now it looks support for planar formats on ICL is
totally skipped. As is inside skl_plane_has_planar(..) there's check if
running on ICL no planar support is available but it is only until
planar support for ICL is patched in. I suspect you are going to need
icl_primary_formats[] as well as icl_pri_planar_formats[] in similar way
as on SKL. It is similar issue below with changes for intel_sprite.c
/Juha-Pekka
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f7e2768..2e61fe19 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1281,6 +1281,21 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1536,8 +1551,11 @@ struct intel_plane *
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- if (skl_plane_has_planar(dev_priv, pipe,
-PLANE_SPRITE0 + plane)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ plane_formats = icl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(icl_plane_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_SPRITE0 + plane)) {
plane_formats = skl_planar_formats;
num_plane_formats = ARRAY_SIZE(skl_planar_formats);
} else {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/fb-helper: Remove set but not used variable 'connector_funcs'
On Wed, Sep 12, 2018 at 03:15:30AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/drm_fb_helper.c: In function 'drm_pick_crtcs':
> drivers/gpu/drm/drm_fb_helper.c:2373:43: warning:
> variable 'connector_funcs' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing
Thanks for your patch, applied to -misc-fixes
Sean
> ---
> drivers/gpu/drm/drm_fb_helper.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 73cf10a..16e3a59 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2370,7 +2370,6 @@ static int drm_pick_crtcs(struct drm_fb_helper
> *fb_helper,
> {
> int c, o;
> struct drm_connector *connector;
> - const struct drm_connector_helper_funcs *connector_funcs;
> int my_score, best_score, score;
> struct drm_fb_helper_crtc **crtcs, *crtc;
> struct drm_fb_helper_connector *fb_helper_conn;
> @@ -2399,8 +2398,6 @@ static int drm_pick_crtcs(struct drm_fb_helper
> *fb_helper,
> if (drm_has_preferred_mode(fb_helper_conn, width, height))
> my_score++;
>
> - connector_funcs = connector->helper_private;
> -
> /*
>* select a crtc for this connector and then attempt to configure
>* remaining connectors
>
>
>
--
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 v4 02/25] drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT
On 9/12/2018 6:25 AM, Manasi Navare wrote: This patch defines the DP DSC receiver capability size that gives total number of DP DSC DPCD registers. This also adds a missing #defines for DP DSC support missed in the commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature") v3: * MIN_SLICE_WIDTH = 2560 (Anusha) * Define DP_DSC_SLICE_WIDTH_MULTIPLIER = 320 v2: * Add SHIFT define and DECOMPRESSION_EN define missed in prev patch Cc: dri-devel@lists.freedesktop.org Cc: Jani Nikula Cc: Ville Syrjala Cc: Anusha Srivatsa Cc: Gaurav K Singh Signed-off-by: Manasi Navare Reviewed-by: Anusha Srivatsa The patch looks good to me. Reviewed-by: Gaurav K Singh --- include/drm/drm_dp_helper.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 698082a02b97..7f6237cad10d 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -231,6 +231,8 @@ #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ +# define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) +# define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 # define DP_DSC_RGB (1 << 0) @@ -279,6 +281,8 @@ # define DP_DSC_THROUGHPUT_MODE_1_1000 (14 << 4) #define DP_DSC_MAX_SLICE_WIDTH 0x06C +#define DP_DSC_MIN_SLICE_WIDTH_VALUE2560 +#define DP_DSC_SLICE_WIDTH_MULTIPLIER 320 #define DP_DSC_SLICE_CAP_2 0x06D # define DP_DSC_16_PER_DP_DSC_SINK (1 << 0) @@ -477,6 +481,7 @@ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ +# define DP_DECOMPRESSION_EN(1 << 0) #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE(1 << 0) @@ -963,6 +968,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI #define DP_BRANCH_OUI_HEADER_SIZE 0xc #define DP_RECEIVER_CAP_SIZE 0xf +#define DP_DSC_RECEIVER_CAP_SIZE0xf #define EDP_PSR_RECEIVER_CAP_SIZE 2 #define EDP_DISPLAY_CTL_CAP_SIZE 3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Mon, Sep 10, 2018 at 09:53:25PM +0200, Daniel Vetter wrote: On Mon, Sep 10, 2018 at 09:50:03AM +0100, Brian Starkey wrote: Hi, On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote: > On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote: > > Hi Daniel, > > > > On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: > > > On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: > > > > Some formats have a non-integer number of bytes per pixel, which can't > > > > be handled with the existing 'cpp' field in drm_format_info. To handle > > > > these formats, add a 'bpp' field, which is only used if cpp[0] == 0. > > > > > > > > This updates all the users of format->cpp in the core DRM code, > > > > converting them to use a new function to get the bits-per-pixel for any > > > > format. > > > > > > > > It's assumed that drivers will use the 'bpp' field when they add support > > > > for pixel formats with non-integer bytes-per-pixel. > > > > > > > > Signed-off-by: Brian Starkey > > > > > > I assume you still require that stuff is eventually aligned to bytes? In > > > that case, can we subsume this into the tile work Alex is doing? It's > > > essentially just another special case of having storage-size units > > > measured in bytes which span more than 1x1 pixel. And I kinda don't want a > > > metric pile of special cases here in the format code, because that just > > > means every driver handles a different subset, with different bugs. > > > -Daniel > > > > Sorry for the delay, been struggling to free some cycles to think > > about this. > > > > I'm not sure how to pull this in with the tiling stuff. In the AFBC > > case then our AFBC superblocks are always nice round numbers (256 > > pixels), and so it does end up being a multiple of bytes. > > > > However, AFBC supports different superblock sizes, so picking just one > > doesn't really work out, and putting AFBC in the core format table > > which reflects AFBC doesn't seem good. > > > > We could make something up (e.g. call these formats "tiled" with 2x4 > > tiles, which guarantees a multiple of 8), but it would be an > > arbitrarily-selected lie, which often seems to spell trouble. If we > > did do that, would you re-define cpp as "bytes-per-tile"? Otherwise > > we still need to add a new field anyway. > > > > What's the pile of special cases you're worried about? The helper I've > > added here means that drivers which need to care can use one API and > > not implement their own bugs. > > I'm confused ... the new bits-per-pixel stuff you're adding here is for > yuv formats, not afbc. I'm just suggesting we have only 1 way of > describing such formats that need more descriptive power than cpp, whether > they have some kind of pixel-groups or small tiles. Well, not really. The three formats which have non-integer cpp are: DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and DRM_FORMAT_YUV420_10BIT. These formats are only valid with non-linear modifiers (no linear encoding is defined). Mali only supports them with AFBC. The formats themselves have no notion of tiling or grouping - the modifier adds that. I'm not aware of any non-AFBC uses of these formats, so I don't want to "make up" a small-tile layout restriction for them. Ah, I missed that. > For very special stuff like afbc you need to validate in the driver > anyway, too complicated. So I have no idea why you bring this up here? Sure, we can just let drivers provide their own format_info's for these, if that's what you prefer. The core format checking code can error out if it ever encounters them. It's format_info we're talking about. What I mean is that you just set all these to 0 and let the format_info code ignore it. And then having a bespoke drm_format_check_afbc helper function or similar, which checks all the layout restrictions of afbc. I still maintain that bpp and tile_size are equavalent, and we really don't need both. Both are defacto a form of numerator/denumerator. If you don't like that you have to introduce "fake" tiles for afbc, then we can rename tile_size to numerator and tile_h/w to denumerator_h/w. Doesn't change one bit of the math. bpp simply hardcodes a denumerator of 8, and I don't see why we need that special case. Except if you love to write redundant self tests for all the math :-) So two options that I think are reasonable: - one common numerator/denumerator. I don't care how you call that bikeshed. Sorry for being dense, but I'm still struggling to get my head around what you're suggesting. In particular "bpp simply hardcodes a denumerator of 8" didn't make any sense to me. Could you give concrete examples for how you think this would look for e.g. - DRM_FORMAT_VUY101010. 30-bits per pixel, no tiling. - DRM_FORMAT_Y0L2. 16-bits per pixel, 2x2 pixel tiles I think we need two things: - The size, in bits, of a tile - The width and height, in pixels, of a tile (currently implicitly 1x1) Do you disagree? Are you just saying that in
Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results
> > in
> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
> > module:
> >
> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> > ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> > undefined!
> >
> > This solves the problem by adding a silent symbol for the tcon_top module,
> > building it as a separate module in exactly the cases that we need it,
> > but in a way that it is reachable by the other modules.
> >
> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching mixers
> > with tcon")
> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
> > Tested-by: Jon Hunter
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Daniel Vetter
It's pushed, 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: next-20180911 build: 1 failures 15 warnings (next-20180911)
On Tue, Sep 11, 2018 at 10:18:01PM +0200, Daniel Vetter wrote: > On Tue, Sep 11, 2018 at 10:10 PM, Mark Brown wrote: > > On Tue, Sep 11, 2018 at 08:47:28PM +0100, Build bot for Mark Brown wrote: > > > > Today's -next fails to build an arm64 defconfig due to: > > > >> arm64-defconfig > >> ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] > >> undefined! > >> ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] > >> undefined! > >> ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko] > >> undefined! > > > > DRM_SUN4I unconditionally uses these symbols which are only defined when > > DRM_SUN8I_TOP is enabled, not sure what the exact cause is but there's a > > few recent patches to that driver from Jonathan and Chen-Yu so CCing for > > that. I've been missing arm64 builds for a little while so this > > could've been there before today. > > Patch seems to have been stuck on dri-devel. I smashed an r-b onto it > so Maxime can apply. It's done now. 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: [PATCH v4 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
Am Montag, 10. September 2018, 17:15:46 CEST schrieb Jonas Karlman:
> Hi Heiko,
>
> CEC is not working when CEC 5V is enabled
>
> On 2018-09-10 11:22, Heiko Stuebner wrote:
>
> > The rk3328 uses a dw-hdmi controller with an external hdmi phy from
> > Innosilicon which uses the generic phy framework for access.
> > Add the necessary data and the compatible for the rk3328 to the
> > rockchip dw-hdmi driver.
> >
> > Signed-off-by: Heiko Stuebner
> > Tested-by: Robin Murphy
> > Acked-by: Rob Herring
> >
> > changes in v3:
> > - reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
> > ---
> > .../display/rockchip/dw_hdmi-rockchip.txt | 1 +
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 106 ++
> > 2 files changed, 107 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > index 937bfb472e1d..39143424a474 100644
> > ---
> > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > +++
> > b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > @@ -13,6 +13,7 @@ Required properties:
> >
> > - compatible: should be one of the following:
> > "rockchip,rk3288-dw-hdmi"
> > + "rockchip,rk3328-dw-hdmi"
> > "rockchip,rk3399-dw-hdmi"
> > - reg: See dw_hdmi.txt.
> > - reg-io-width: See dw_hdmi.txt. Shall be 4.
> > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > index 19f002fa0a09..237f31fd8403 100644
> > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > @@ -25,6 +25,24 @@
> >
> > #define RK3288_GRF_SOC_CON60x025C
> > #define RK3288_HDMI_LCDC_SEL BIT(4)
> > +#define RK3328_GRF_SOC_CON20x0408
> > +
> > +#define RK3328_HDMI_SDAIN_MSK BIT(11)
> > +#define RK3328_HDMI_SCLIN_MSK BIT(10)
> > +#define RK3328_HDMI_HPD_IOEBIT(2)
> > +#define RK3328_GRF_SOC_CON30x040c
> > +/* need to be unset if hdmi or i2c should control voltage */
> > +#define RK3328_HDMI_SDA5V_GRF BIT(15)
> > +#define RK3328_HDMI_SCL5V_GRF BIT(14)
> > +#define RK3328_HDMI_HPD5V_GRF BIT(13)
> > +#define RK3328_HDMI_CEC5V_GRF BIT(12)
> > +#define RK3328_GRF_SOC_CON40x0410
> > +#define RK3328_HDMI_HPD_SARADC BIT(13)
> > +#define RK3328_HDMI_CEC_5V BIT(11)
> > +#define RK3328_HDMI_SDA_5V BIT(10)
> > +#define RK3328_HDMI_SCL_5V BIT(9)
> > +#define RK3328_HDMI_HPD_5V BIT(8)
> > +
> > #define RK3399_GRF_SOC_CON20 0x6250
> > #define RK3399_HDMI_LCDC_SEL BIT(6)
> >
> > @@ -292,6 +310,68 @@ static const struct drm_encoder_helper_funcs
> > dw_hdmi_rockchip_encoder_helper_fun
> > .atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
> > };
> >
> > +static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void
> > *data,
> > +struct drm_display_mode *mode)
> > +{
> > + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> > +
> > + return phy_power_on(hdmi->phy);
> > +}
> > +
> > +static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void
> > *data)
> > +{
> > + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> > +
> > + phy_power_off(hdmi->phy);
> > +}
> > +
> > +static enum drm_connector_status
> > +dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
> > +{
> > + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> > + enum drm_connector_status status;
> > +
> > + status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
> > +
> > + if (status == connector_status_connected)
> > + regmap_write(hdmi->regmap,
> > + RK3328_GRF_SOC_CON4,
> > + HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
> > + RK3328_HDMI_SCL_5V,
> > + RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
> > + RK3328_HDMI_SCL_5V));
>
> This differs from BSP kernel and enable of CEC 5V stops CEC from working.
> BSP kernel do not set write enable bit for CEC 5V:
>
> RK3328_IO_5V_DOMAIN ((7 << 9) | (3 << (9 + 16)))
>
> https://github.com/Kwiboo/linux-rockchip/commit/e74ac6a3a581bcb7b2ac9f4d70cf7298df01e417
> makes CEC work on v3 of this patch.
thanks for checking the cec functionality. I've incorporated your change
and sent off v6. Maybe you can take another look and possible provide
some Tested-by (or even Reviewed-by/Acked-by) tags? :-)
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Wed, Sep 12, 2018 at 11:53 AM, Maxime Ripard
wrote:
> On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
>> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
>> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results
>> > in
>> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
>> > module:
>> >
>> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>> > undefined!
>> > ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>> > undefined!
>> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>> > undefined!
>> >
>> > This solves the problem by adding a silent symbol for the tcon_top module,
>> > building it as a separate module in exactly the cases that we need it,
>> > but in a way that it is reachable by the other modules.
>> >
>> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching mixers
>> > with tcon")
>> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
>> > Tested-by: Jon Hunter
>> > Signed-off-by: Maxime Ripard
>>
>> Reviewed-by: Daniel Vetter
>>
>> But I can't help myself and drop the usual questions when I see a small
>> soc driver with more Kconfigs than anything else ... is all this pain
>> worth it? I know that maybe the desktop approach of stuffing half a
>> million lines of driver code into one .ko might be a bit too much for
>> socs, but this seems overkill.
>>
>> I'm also pretty sure it's not justified by any real data, compared to
>> overall code size of a drm stack, that shows it's a substantial enough
>> saving that it's worth it.
>
> I'm currently running on a project where the boot time to a qt
> application from power off should be less than a second. You want to
> remove anything you can spare in some situations. And yeah, DRM is the
> biggest thing in the way to do that.
Oh I know all about the 1s people. But is binary size really that
important figure? I know it's a bit more to load&decompress, but it
shouldn't have any impact on anything running at runtime.
>> Imo, if you really care about building a minimal driver, stuff everything
>> into one .ko and then LTO out the uneeded bits. We've done these
>> experiments for i915, that _actually_ saves a ton of binary size, with
>> fairly minimal code and maintenance impact. Still, we decided the payoff
>> is simply too small to bother making it a production thing.
>
> LTO isn't enabled yet in mainline, is it?
Unfortunately not :-/ We've done the analysis and reported to the
internal people who asked for this that "lto is what you want", but
nothing thus far. I guess the price tag of making LTO work is a bit
too much. Ofc doesn't just need LTO, but also needs some trickery to
make sure all the optional paths are statically determined to never
run. But (at least for us) that's just a few changes to the pci table,
and hard-coding the device info structure. OF/DT would probably need
some work, but should be doable too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/25] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On 9/12/2018 6:25 AM, Manasi Navare wrote:
This patch adds inline functions and helpers for obtaining
DP sink's supported DSC parameters like DSC sink support,
eDP compressed BPP supported, maximum slice count supported
by the sink devices, DSC line buffer bit depth supported on DP sink,
DSC sink maximum color depth by parsing corresponding DPCD registers.
v4:
* Add helper to give line buf bit depth (Manasi)
* Correct the bit masking in color depth helper (manasi)
v3:
* Use SLICE_CAP_2 for DP (Anusha)
v2:
* Add DSC sink support macro (Jani N)
Cc: Gaurav K Singh
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
This patch looks good to me.
Reviewed-by: Gaurav K Singh
---
drivers/gpu/drm/drm_dp_helper.c | 90 +
include/drm/drm_dp_helper.h | 30 +++
2 files changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8c6b9fd89f8a..5d5879f115ce 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1337,3 +1337,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
drm_dp_desc *desc,
return 0;
}
EXPORT_SYMBOL(drm_dp_read_desc);
+
+/**
+ * DRM DP Helpers for DSC
+ */
+u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+ bool is_edp)
+{
+ u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
+
+ if (is_edp) {
+ /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice count
*/
+ if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
+ return 4;
+ if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
+ return 2;
+ if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
+ return 1;
+ } else {
+ /* For DP, use values from DSC_SLICE_CAP_1 and DSC_SLICE_CAP2 */
+ u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 - DP_DSC_SUPPORT];
+
+ if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
+ return 24;
+ if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
+ return 20;
+ if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
+ return 16;
+ if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
+ return 12;
+ if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
+ return 10;
+ if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
+ return 8;
+ if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
+ return 6;
+ if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
+ return 4;
+ if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
+ return 2;
+ if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
+
+u8 drm_dp_dsc_sink_line_buf_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
DP_DSC_SUPPORT];
+
+ switch (line_buf_depth & DP_DSC_LINE_BUF_BIT_DEPTH_MASK) {
+ case DP_DSC_LINE_BUF_BIT_DEPTH_9:
+ return 9;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_10:
+ return 10;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_11:
+ return 11;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_12:
+ return 12;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_13:
+ return 13;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_14:
+ return 14;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_15:
+ return 15;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_16:
+ return 16;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_8:
+ return 8;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
+
+u8 drm_dp_dsc_sink_max_color_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 color_depth = dsc_dpcd[DP_DSC_DEC_COLOR_DEPTH_CAP - DP_DSC_SUPPORT];
+
+ if (color_depth & DP_DSC_12_BPC)
+ return 12;
+ if (color_depth & DP_DSC_10_BPC)
+ return 10;
+ if (color_depth & DP_DSC_8_BPC)
+ return 8;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_max_color_depth);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 7f6237cad10d..ce6297908fd6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1065,6 +1065,36 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
}
+/* DP/eDP DSC support */
+u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+
Re: next-20180911 build: 1 failures 15 warnings (next-20180911)
On Wed, Sep 12, 2018 at 04:02:22PM +0200, Maxime Ripard wrote: > On Tue, Sep 11, 2018 at 10:18:01PM +0200, Daniel Vetter wrote: > > Patch seems to have been stuck on dri-devel. I smashed an r-b onto it > > so Maxime can apply. > It's done now. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #11 from jam...@amd.com --- I think latest ROCm package has fixed this issue. You are welcome to try it. Best Regards! James zhu -- 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] [v3] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Wed, Sep 12, 2018 at 12:25:54PM +0100, Matt Hart wrote:
> On 7 September 2018 at 12:42, Maxime Ripard wrote:
> > On Fri, Sep 07, 2018 at 01:26:30PM +0200, Arnd Bergmann wrote:
> >> On Fri, Sep 7, 2018 at 11:41 AM Jon Hunter wrote:
> >> >
> >> >
> >> > On 11/07/18 15:43, Arnd Bergmann wrote:
> >> > > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module
> >> > > results in
> >> > > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
> >> > > module:
> >> > >
> >> > > ERROR: "sun8i_tcon_top_of_table"
> >> > > [drivers/gpu/drm/sun4i/sun8i-drm-hdmi.ko] undefined!
> >> > > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-drm.ko]
> >> > > undefined!
> >> > >
> >> > > This solves the problem by adding a silent symbol for the tcon_top
> >> > > module,
> >> > > building it as a separate module in exactly the cases that we need it,
> >> > > but in a way that it is reachable by the other modules.
> >> > >
> >> > > Fixes: 57e23de02f48 ("drm/sun4i: DW HDMI: Expand algorithm for
> >> > > possible crtcs")
> >> > > Fixes: ef0cf6441fbb ("drm/sun4i: Add support for traversing graph with
> >> > > TCON TOP")
> >> > > Signed-off-by: Arnd Bergmann
> >> > I am seeing the following on today's -next (20180907) as well the last
> >> > few -next versions for that matter ...
> >> >
> >> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> >> > undefined!
> >> > ERROR: "sun8i_tcon_top_set_hdmi_src"
> >> > [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
> >> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> >> > undefined!
> >> >
> >> > Seems like this issue has cropped up again as Arnd's fix is present. I
> >> > am seeing this on ARM64 builds.
> >>
> >> I have not started build testing on linux-next since the merge window, but
> >> looking at the changes that got queued up, I find commits cf77d79b4e29
> >> ("drm/sun4i: tcon: Add another way for matching mixers with tcon") and
> >> 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") that both
> >> introduced a reference to the tcon_top file from sun4i_tcon.c.
> >>
> >> More IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) checks in
> >> the caller like I did in my patch would help, or alternatively one could
> >> decide to give up and just always include the TCON_TOP.
> >
> > Sorry for the breakage.
> >
> > Can you test:
> >
> > 8<
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 4834c90b4912..c78cd35a1294 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -974,7 +974,8 @@ static bool sun4i_tcon_connected_to_tcon_top(struct
> > device_node *node)
> >
> > remote = of_graph_get_remote_node(node, 0, -1);
> > if (remote) {
> > - ret = !!of_match_node(sun8i_tcon_top_of_table, remote);
> > + ret = !!(IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
> > +of_match_node(sun8i_tcon_top_of_table, remote));
> > of_node_put(remote);
> > }
> >
> > @@ -1402,13 +1403,20 @@ static int sun8i_r40_tcon_tv_set_mux(struct
> > sun4i_tcon *tcon,
> > if (!pdev)
> > return -EINVAL;
> >
> > - if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
> > + if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
> > + encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
> > ret = sun8i_tcon_top_set_hdmi_src(&pdev->dev, id);
> > if (ret)
> > return ret;
> > }
> >
> > - return sun8i_tcon_top_de_config(&pdev->dev, tcon->id, id);
> > + if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP)) {
> > + ret = sun8i_tcon_top_de_config(&pdev->dev, tcon->id, id);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > }
> >
> > static const struct sun4i_tcon_quirks sun4i_a10_quirks = {
> > 8<
>
> Works for me, and still broken in todays next
I pushed that fix, 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: [linux-sunxi] Re: [PATCH 02/27] arm64: allwinner: h6: add system controller device tree node
On Tue, Sep 4, 2018 at 4:44 PM Icenowy Zheng wrote: > > > > 于 2018年9月4日 GMT+08:00 下午4:40:56, Chen-Yu Tsai 写到: > >On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec > >wrote: > >> > >> From: Icenowy Zheng > >> > >> As we have already binding for the H6 system controller, add its node > >> to the device tree. > >> > >> Signed-off-by: Icenowy Zheng > >> [fixed compatible string] > >> Signed-off-by: Jernej Skrabec > > > >Reviewed-by: Chen-Yu Tsai > > By the way can these patches be applied first? (patches > related to syscon). > > They're also needed for EMAC. Applied. BTW, the H6 system control EMAC register also has the internal PHY related controls seen on H3/H5. IIRC you previously mentioned that they have no effect? ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a 64-bit pointer requires calling
compat_ptr(). Most drivers here will ever run in s390, but since we now
have a generic helper for it, it's easy enough to use it consistently.
I double-checked all these drivers to ensure that all ioctl arguments
are used as pointers or are ignored, but are not interpreted as integer
values.
Signed-off-by: Arnd Bergmann
---
drivers/android/binder.c| 2 +-
drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
drivers/dma-buf/dma-buf.c | 4 +---
drivers/dma-buf/sw_sync.c | 2 +-
drivers/dma-buf/sync_file.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
drivers/hid/hidraw.c| 4 +---
drivers/iio/industrialio-core.c | 2 +-
drivers/infiniband/core/uverbs_main.c | 4 ++--
drivers/media/rc/lirc_dev.c | 4 +---
drivers/mfd/cros_ec_dev.c | 4 +---
drivers/misc/vmw_vmci/vmci_host.c | 2 +-
drivers/nvdimm/bus.c| 4 ++--
drivers/nvme/host/core.c| 2 +-
drivers/pci/switch/switchtec.c | 2 +-
drivers/platform/x86/wmi.c | 2 +-
drivers/rpmsg/rpmsg_char.c | 4 ++--
drivers/sbus/char/display7seg.c | 2 +-
drivers/sbus/char/envctrl.c | 4 +---
drivers/scsi/3w-.c | 4 +---
drivers/scsi/cxlflash/main.c| 2 +-
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/pmcraid.c | 4 +---
drivers/staging/android/ion/ion.c | 4 +---
drivers/staging/vme/devices/vme_user.c | 2 +-
drivers/tee/tee_core.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 +-
drivers/usb/class/usbtmc.c | 4 +---
drivers/video/fbdev/ps3fb.c | 2 +-
drivers/virt/fsl_hypervisor.c | 2 +-
fs/btrfs/super.c| 2 +-
fs/ceph/dir.c | 2 +-
fs/ceph/file.c | 2 +-
fs/fuse/dev.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 2 +-
fs/userfaultfd.c| 2 +-
net/rfkill/core.c | 2 +-
37 files changed, 40 insertions(+), 58 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index d58763b6b009..d2464f5759f8 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5576,7 +5576,7 @@ static const struct file_operations binder_fops = {
.owner = THIS_MODULE,
.poll = binder_poll,
.unlocked_ioctl = binder_ioctl,
- .compat_ioctl = binder_ioctl,
+ .compat_ioctl = generic_compat_ioctl_ptrarg,
.mmap = binder_mmap,
.open = binder_open,
.flush = binder_flush,
diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
index abc7a7f64d64..8ff77a70addc 100644
--- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
+++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
@@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int cmd,
unsigned long arg);
static const struct file_operations adf_ctl_ops = {
.owner = THIS_MODULE,
.unlocked_ioctl = adf_ctl_ioctl,
- .compat_ioctl = adf_ctl_ioctl,
+ .compat_ioctl = generic_compat_ioctl_ptrarg,
};
struct adf_ctl_drv_info {
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..a6d7dc4cf7e9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,9 +325,7 @@ static const struct file_operations dma_buf_fops = {
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = dma_buf_ioctl,
-#endif
+ .compat_ioctl = generic_compat_ioctl_ptrarg,
};
/*
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 53c1d6d36a64..bc810506d487 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -419,5 +419,5 @@ const struct file_operations sw_sync_debugfs_fops = {
.open = sw_sync_debugfs_open,
.release= sw_sync_debugfs_release,
.unlocked_ioctl = sw_sync_ioctl,
- .compat_ioctl = sw_sync_ioctl,
+ .compat_ioctl = generic_compat_ioctl_ptrarg,
};
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 35dd06479867..1c64ed60c658 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -488,5 +488,5 @@ static const struct file_operations
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Mon, Sep 10, 2018 at 09:53:25PM +0200, Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 09:50:03AM +0100, Brian Starkey wrote: > > Hi, > > > > On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote: > > > On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote: > > > > Hi Daniel, > > > > > > > > On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: > > > > > On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: > > > > > > Some formats have a non-integer number of bytes per pixel, which > > > > > > can't > > > > > > be handled with the existing 'cpp' field in drm_format_info. To > > > > > > handle > > > > > > these formats, add a 'bpp' field, which is only used if cpp[0] == 0. > > > > > > > > > > > > This updates all the users of format->cpp in the core DRM code, > > > > > > converting them to use a new function to get the bits-per-pixel for > > > > > > any > > > > > > format. > > > > > > > > > > > > It's assumed that drivers will use the 'bpp' field when they add > > > > > > support > > > > > > for pixel formats with non-integer bytes-per-pixel. > > > > > > > > > > > > Signed-off-by: Brian Starkey > > > > > > > > > > I assume you still require that stuff is eventually aligned to bytes? > > > > > In > > > > > that case, can we subsume this into the tile work Alex is doing? It's > > > > > essentially just another special case of having storage-size units > > > > > measured in bytes which span more than 1x1 pixel. And I kinda don't > > > > > want a > > > > > metric pile of special cases here in the format code, because that > > > > > just > > > > > means every driver handles a different subset, with different bugs. > > > > > -Daniel > > > > > > > > Sorry for the delay, been struggling to free some cycles to think > > > > about this. > > > > > > > > I'm not sure how to pull this in with the tiling stuff. In the AFBC > > > > case then our AFBC superblocks are always nice round numbers (256 > > > > pixels), and so it does end up being a multiple of bytes. > > > > > > > > However, AFBC supports different superblock sizes, so picking just one > > > > doesn't really work out, and putting AFBC in the core format table > > > > which reflects AFBC doesn't seem good. > > > > > > > > We could make something up (e.g. call these formats "tiled" with 2x4 > > > > tiles, which guarantees a multiple of 8), but it would be an > > > > arbitrarily-selected lie, which often seems to spell trouble. If we > > > > did do that, would you re-define cpp as "bytes-per-tile"? Otherwise > > > > we still need to add a new field anyway. > > > > > > > > What's the pile of special cases you're worried about? The helper I've > > > > added here means that drivers which need to care can use one API and > > > > not implement their own bugs. > > > > > > I'm confused ... the new bits-per-pixel stuff you're adding here is for > > > yuv formats, not afbc. I'm just suggesting we have only 1 way of > > > describing such formats that need more descriptive power than cpp, whether > > > they have some kind of pixel-groups or small tiles. > > > > Well, not really. The three formats which have non-integer cpp are: > > DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and > > DRM_FORMAT_YUV420_10BIT. These formats are only valid with non-linear > > modifiers (no linear encoding is defined). Mali only supports them > > with AFBC. > > > > The formats themselves have no notion of tiling or grouping - the > > modifier adds that. I'm not aware of any non-AFBC uses of these > > formats, so I don't want to "make up" a small-tile layout restriction > > for them. > > Ah, I missed that. > > > > For very special stuff like afbc you need to validate in the driver > > > anyway, too complicated. So I have no idea why you bring this up here? > > > > Sure, we can just let drivers provide their own format_info's for > > these, if that's what you prefer. The core format checking code can > > error out if it ever encounters them. > > It's format_info we're talking about. What I mean is that you just set all > these to 0 and let the format_info code ignore it. And then having a > bespoke drm_format_check_afbc helper function or similar, which checks all > the layout restrictions of afbc. > > I still maintain that bpp and tile_size are equavalent, and we really > don't need both. Both are defacto a form of numerator/denumerator. If you > don't like that you have to introduce "fake" tiles for afbc, then we can > rename tile_size to numerator and tile_h/w to denumerator_h/w. Doesn't > change one bit of the math. bpp simply hardcodes a denumerator of 8, and I > don't see why we need that special case. Except if you love to write > redundant self tests for all the math :-) My $.02 worth of thoughts: I get the fact that Daniel doesn't like us to add 3 new variables into format_info (bpp, tile_w, tile_h) and that adding a "bits_per_unit" variable should be able to take care of linear (where unit = 1 pixel) and tiled (where unit = ti
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Wed, Sep 12, 2018 at 04:27:04PM +0100, Liviu Dudau wrote: On Mon, Sep 10, 2018 at 09:53:25PM +0200, Daniel Vetter wrote: On Mon, Sep 10, 2018 at 09:50:03AM +0100, Brian Starkey wrote: > Hi, > > On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote: > > On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote: > > > Hi Daniel, > > > > > > On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: > > > > On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: > > > > > Some formats have a non-integer number of bytes per pixel, which can't > > > > > be handled with the existing 'cpp' field in drm_format_info. To handle > > > > > these formats, add a 'bpp' field, which is only used if cpp[0] == 0. > > > > > > > > > > This updates all the users of format->cpp in the core DRM code, > > > > > converting them to use a new function to get the bits-per-pixel for any > > > > > format. > > > > > > > > > > It's assumed that drivers will use the 'bpp' field when they add support > > > > > for pixel formats with non-integer bytes-per-pixel. > > > > > > > > > > Signed-off-by: Brian Starkey > > > > > > > > I assume you still require that stuff is eventually aligned to bytes? In > > > > that case, can we subsume this into the tile work Alex is doing? It's > > > > essentially just another special case of having storage-size units > > > > measured in bytes which span more than 1x1 pixel. And I kinda don't want a > > > > metric pile of special cases here in the format code, because that just > > > > means every driver handles a different subset, with different bugs. > > > > -Daniel > > > > > > Sorry for the delay, been struggling to free some cycles to think > > > about this. > > > > > > I'm not sure how to pull this in with the tiling stuff. In the AFBC > > > case then our AFBC superblocks are always nice round numbers (256 > > > pixels), and so it does end up being a multiple of bytes. > > > > > > However, AFBC supports different superblock sizes, so picking just one > > > doesn't really work out, and putting AFBC in the core format table > > > which reflects AFBC doesn't seem good. > > > > > > We could make something up (e.g. call these formats "tiled" with 2x4 > > > tiles, which guarantees a multiple of 8), but it would be an > > > arbitrarily-selected lie, which often seems to spell trouble. If we > > > did do that, would you re-define cpp as "bytes-per-tile"? Otherwise > > > we still need to add a new field anyway. > > > > > > What's the pile of special cases you're worried about? The helper I've > > > added here means that drivers which need to care can use one API and > > > not implement their own bugs. > > > > I'm confused ... the new bits-per-pixel stuff you're adding here is for > > yuv formats, not afbc. I'm just suggesting we have only 1 way of > > describing such formats that need more descriptive power than cpp, whether > > they have some kind of pixel-groups or small tiles. > > Well, not really. The three formats which have non-integer cpp are: > DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and > DRM_FORMAT_YUV420_10BIT. These formats are only valid with non-linear > modifiers (no linear encoding is defined). Mali only supports them > with AFBC. > > The formats themselves have no notion of tiling or grouping - the > modifier adds that. I'm not aware of any non-AFBC uses of these > formats, so I don't want to "make up" a small-tile layout restriction > for them. Ah, I missed that. > > For very special stuff like afbc you need to validate in the driver > > anyway, too complicated. So I have no idea why you bring this up here? > > Sure, we can just let drivers provide their own format_info's for > these, if that's what you prefer. The core format checking code can > error out if it ever encounters them. It's format_info we're talking about. What I mean is that you just set all these to 0 and let the format_info code ignore it. And then having a bespoke drm_format_check_afbc helper function or similar, which checks all the layout restrictions of afbc. I still maintain that bpp and tile_size are equavalent, and we really don't need both. Both are defacto a form of numerator/denumerator. If you don't like that you have to introduce "fake" tiles for afbc, then we can rename tile_size to numerator and tile_h/w to denumerator_h/w. Doesn't change one bit of the math. bpp simply hardcodes a denumerator of 8, and I don't see why we need that special case. Except if you love to write redundant self tests for all the math :-) My $.02 worth of thoughts: I get the fact that Daniel doesn't like us to add 3 new variables into format_info (bpp, tile_w, tile_h) and that adding a "bits_per_unit" variable should be able to take care of linear (where unit = 1 pixel) and tiled (where unit = tile_w * tile_h pixels) formats. And I also see Daniel's option 2 below, where he says it is reasonable to check AFBC without using format_info. However, the problem we are trying to solve is 2 fold: we ar
Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Wed, Sep 12, 2018 at 04:25:36PM +0200, Daniel Vetter wrote:
> On Wed, Sep 12, 2018 at 11:53 AM, Maxime Ripard
> wrote:
> > On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
> >> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
> >> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module
> >> > results in
> >> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
> >> > module:
> >> >
> >> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> >> > undefined!
> >> > ERROR: "sun8i_tcon_top_set_hdmi_src"
> >> > [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
> >> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> >> > undefined!
> >> >
> >> > This solves the problem by adding a silent symbol for the tcon_top
> >> > module,
> >> > building it as a separate module in exactly the cases that we need it,
> >> > but in a way that it is reachable by the other modules.
> >> >
> >> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching
> >> > mixers with tcon")
> >> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
> >> > Tested-by: Jon Hunter
> >> > Signed-off-by: Maxime Ripard
> >>
> >> Reviewed-by: Daniel Vetter
> >>
> >> But I can't help myself and drop the usual questions when I see a small
> >> soc driver with more Kconfigs than anything else ... is all this pain
> >> worth it? I know that maybe the desktop approach of stuffing half a
> >> million lines of driver code into one .ko might be a bit too much for
> >> socs, but this seems overkill.
> >>
> >> I'm also pretty sure it's not justified by any real data, compared to
> >> overall code size of a drm stack, that shows it's a substantial enough
> >> saving that it's worth it.
> >
> > I'm currently running on a project where the boot time to a qt
> > application from power off should be less than a second. You want to
> > remove anything you can spare in some situations. And yeah, DRM is the
> > biggest thing in the way to do that.
>
> Oh I know all about the 1s people. But is binary size really that
> important figure? I know it's a bit more to load&decompress, but it
> shouldn't have any impact on anything running at runtime.
It really depends on the combination of the CPU speed, the storage
speed, and the compression algorithm. To give you a figure, a quite
good storage device in our case has a bandwith of 10MB/s. If you add a
MB, you lose a tenth of your budget, decompression excluded.
The sole edid_cea_modes, drm_dmt_modes and edid_est_modes, combined,
already take around 50kB. That's around .5% of our time budget just
dedicated to loading structures we will never need, without the option
to compile them out.
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
[pull] amdgpu drm-fixes-4.19
Hi Dave, A few fixes for 4.19: - Fix a small memory leak - SR-IOV reset fix - Fix locking in MMU-notifier error path - Updated SDMA golden settings to fix a PRT hang The following changes since commit 67c6ed7cf9ebe53815f15bfdeb49ad91801c2235: Merge tag 'drm-intel-fixes-2018-09-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-09-07 11:07:03 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.19 for you to fetch changes up to 0165de983272d1fae0809ed9db47c46a412279bc: drm/amdgpu: fix error handling in amdgpu_cs_user_fence_chunk (2018-09-11 16:35:00 -0500) Christian König (2): drm/amdgpu: fix amdgpu_mn_unlock() in the CS error path drm/amdgpu: fix error handling in amdgpu_cs_user_fence_chunk Emily Deng (1): drm/amdgpu: move PSP init prior to IH in gpu reset Tao Zhou (1): drm/amdgpu: Fix SDMA hang in prt mode v2 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 25 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 7 +-- 3 files changed, 22 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] etnaviv: Make sure DMA is setup
Since we don't want to setup up DMA via device tree we end up with
arm64's dummy_dma_ops otherwise.
Links: https://lists.freedesktop.org/archives/etnaviv/2018-August/001925.html
Signed-off-by: Guido Günther
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 9b2720b41571..e488c07f333c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -591,8 +591,19 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct component_match *match = NULL;
+ int ret;
+
+ ret = of_dma_configure(dev, NULL, true);
+ if (ret) {
+ dev_err(&pdev->dev, "Setting up dma ops failed\n");
+ return ret;
+ };
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(&pdev->dev, "dma_coerce_mask_and_coherent failed\n");
+ return ret;
+ };
if (!dev->platform_data) {
struct device_node *core_node;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] etnaviv: Make sure DMA is setup
Hi Guido,
I've just sent out a patch which should hopefully also fix this issue,
in a (slightly) more correct way. I don't have my MX8M system up right
now, so would appreciate if you could test drive this patch.
Regards,
Lucas
Am Mittwoch, den 12.09.2018, 17:44 +0200 schrieb Guido Günther:
> Since we don't want to setup up DMA via device tree we end up with
> arm64's dummy_dma_ops otherwise.
>
> Links: https://lists.freedesktop.org/archives/etnaviv/2018-August/001925.html
> > Signed-off-by: Guido Günther
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 9b2720b41571..e488c07f333c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -591,8 +591,19 @@ static int etnaviv_pdev_probe(struct platform_device
> *pdev)
> {
> > struct device *dev = &pdev->dev;
> > struct component_match *match = NULL;
> > + int ret;
> +
> > + ret = of_dma_configure(dev, NULL, true);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Setting up dma ops failed\n");
> > + return ret;
> > + };
>
> > - dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> > + ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > + if (ret) {
> > + dev_err(&pdev->dev, "dma_coerce_mask_and_coherent failed\n");
> > + return ret;
> > + };
>
> > if (!dev->platform_data) {
> > struct device_node *core_node;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] intel: annotate the intel genx helpers as private
From: Emil Velikov
They're used internally and never meant to be part of the API.
Add the drm_private notation, which should resolve that.
v2: (Rodrigo) Add missing include.
v3: (Rodrigo) Keep includes grouped per Eric suggestion.
Cc: Eric Engestrom
Cc: Lucas De Marchi
Cc: Chris Wilson
Cc: Rodrigo Vivi
Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
Signed-off-by: Emil Velikov
Acked-by: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
Reviewed-by: Eric Engestrom
---
intel/intel_chipset.c | 4 ++--
intel/intel_chipset.h | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index d5c33cc5..5aa4a2f2 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -44,7 +44,7 @@ static const struct pci_device {
INTEL_SKL_IDS(9),
};
-bool intel_is_genx(unsigned int devid, int gen)
+drm_private bool intel_is_genx(unsigned int devid, int gen)
{
const struct pci_device *p,
*pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
@@ -66,7 +66,7 @@ bool intel_is_genx(unsigned int devid, int gen)
return false;
}
-bool intel_get_genx(unsigned int devid, int *gen)
+drm_private bool intel_get_genx(unsigned int devid, int *gen)
{
const struct pci_device *p,
*pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 9b1e64f1..5db207cc 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -329,9 +329,10 @@
/* New platforms use kernel pci ids */
#include
+#include
-bool intel_is_genx(unsigned int devid, int gen);
-bool intel_get_genx(unsigned int devid, int *gen);
+drm_private bool intel_is_genx(unsigned int devid, int gen);
+drm_private bool intel_get_genx(unsigned int devid, int *gen);
#define IS_GEN9(devid) intel_is_genx(devid, 9)
#define IS_GEN10(devid) intel_is_genx(devid, 10)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On Wed, Sep 12, 2018 at 5:47 PM, Maxime Ripard
wrote:
> On Wed, Sep 12, 2018 at 04:25:36PM +0200, Daniel Vetter wrote:
>> On Wed, Sep 12, 2018 at 11:53 AM, Maxime Ripard
>> wrote:
>> > On Tue, Sep 11, 2018 at 10:17:02PM +0200, Daniel Vetter wrote:
>> >> On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
>> >> > Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module
>> >> > results in
>> >> > a link error, as we try to access a symbol from the sun8i_tcon_top.ko
>> >> > module:
>> >> >
>> >> > ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>> >> > undefined!
>> >> > ERROR: "sun8i_tcon_top_set_hdmi_src"
>> >> > [drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
>> >> > ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>> >> > undefined!
>> >> >
>> >> > This solves the problem by adding a silent symbol for the tcon_top
>> >> > module,
>> >> > building it as a separate module in exactly the cases that we need it,
>> >> > but in a way that it is reachable by the other modules.
>> >> >
>> >> > Fixes: cf77d79b4e29 ("drm/sun4i: tcon: Add another way for matching
>> >> > mixers with tcon")
>> >> > Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
>> >> > Tested-by: Jon Hunter
>> >> > Signed-off-by: Maxime Ripard
>> >>
>> >> Reviewed-by: Daniel Vetter
>> >>
>> >> But I can't help myself and drop the usual questions when I see a small
>> >> soc driver with more Kconfigs than anything else ... is all this pain
>> >> worth it? I know that maybe the desktop approach of stuffing half a
>> >> million lines of driver code into one .ko might be a bit too much for
>> >> socs, but this seems overkill.
>> >>
>> >> I'm also pretty sure it's not justified by any real data, compared to
>> >> overall code size of a drm stack, that shows it's a substantial enough
>> >> saving that it's worth it.
>> >
>> > I'm currently running on a project where the boot time to a qt
>> > application from power off should be less than a second. You want to
>> > remove anything you can spare in some situations. And yeah, DRM is the
>> > biggest thing in the way to do that.
>>
>> Oh I know all about the 1s people. But is binary size really that
>> important figure? I know it's a bit more to load&decompress, but it
>> shouldn't have any impact on anything running at runtime.
>
> It really depends on the combination of the CPU speed, the storage
> speed, and the compression algorithm. To give you a figure, a quite
> good storage device in our case has a bandwith of 10MB/s. If you add a
> MB, you lose a tenth of your budget, decompression excluded.
>
> The sole edid_cea_modes, drm_dmt_modes and edid_est_modes, combined,
> already take around 50kB. That's around .5% of our time budget just
> dedicated to loading structures we will never need, without the option
> to compile them out.
Yup, if you want to make drm_edid.c optional, you need LTO. Because I
think we've already gone way overboard with making stuff optional in
the drm core, there's lots of silly little Kconfigs with imo
questionable value. Also, 50kb ... what does that look like
compressed? Should compress exceedingly well.
But that's not what I asked about really, I asked about all the
Kconfigs in su4i. Are those worth it? Especially compared to fixing
this for real, using something like LTO (plus making a few things
hard-coded, per machine configuration, so that gcc can figure it all
out).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 5:08 PM, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Daniel Vetter
At least for the drm and dma-buf bits.
-Daniel
> ---
> drivers/android/binder.c| 2 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +---
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
> drivers/hid/hidraw.c| 4 +---
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 ++--
> drivers/media/rc/lirc_dev.c | 4 +---
> drivers/mfd/cros_ec_dev.c | 4 +---
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/nvdimm/bus.c| 4 ++--
> drivers/nvme/host/core.c| 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 ++--
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +---
> drivers/scsi/3w-.c | 4 +---
> drivers/scsi/cxlflash/main.c| 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/pmcraid.c | 4 +---
> drivers/staging/android/ion/ion.c | 4 +---
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +---
> drivers/video/fbdev/ps3fb.c | 2 +-
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c| 2 +-
> fs/ceph/dir.c | 2 +-
> fs/ceph/file.c | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c| 2 +-
> net/rfkill/core.c | 2 +-
> 37 files changed, 40 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index d58763b6b009..d2464f5759f8 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5576,7 +5576,7 @@ static const struct file_operations binder_fops = {
> .owner = THIS_MODULE,
> .poll = binder_poll,
> .unlocked_ioctl = binder_ioctl,
> - .compat_ioctl = binder_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> .mmap = binder_mmap,
> .open = binder_open,
> .flush = binder_flush,
> diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> index abc7a7f64d64..8ff77a70addc 100644
> --- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> +++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> @@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int
> cmd, unsigned long arg);
> static const struct file_operations adf_ctl_ops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = adf_ctl_ioctl,
> - .compat_ioctl = adf_ctl_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> struct adf_ctl_drv_info {
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..a6d7dc4cf7e9 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -325,9 +325,7 @@ static const struct file_operations dma_buf_fops = {
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> .unlocked_ioctl = dma_buf_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = dma_buf_ioctl,
> -#endif
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> /*
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index 53c1d6d36a64..bc810506d487 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -419,5 +419,5 @@ const struct file_operations sw_sync_debugfs_fops = {
> .open = sw_sync_debugfs_open,
> .release= sw_sync_debugfs_release,
> .unlocked_ioctl = sw_sync_ioctl,
> -
