Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote: > > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay > wrote: > > > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote: > > > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > > I think I found a userspace-accessible way to create sync_files and > > > > dma_fences that would fulfill the requirements: > > > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > > > > > I'm just not sure if that's a good interface to use, since it appears > > > > to be designed only for debugging. Will have to check for additional > > > > requirements of signalling an error when the process that created the > > > > fence is killed. > > It is expressly only for debugging and testing. Exposing such an API > to userspace would break the finite time guarantees that are relied > upon to keep sync_file a secure API. Ok, I was figuring that was probably the case. > > > Something like that can certainly be lifted for general use if it makes > > > sense. But then with a software renderer I don't really see how fences > > > help you at all. With a software renderer you know exactly when the > > > frame is finished and you can just defer pushing it over to the next > > > pipeline element until that time. You won't gain any parallelism by > > > using fences as the CPU is busy doing the rendering and will not run > > > other stuff concurrently, right? > > > > There definitely may be other hardware and/or processes that can > > process some stuff concurrently with the main application, such as the > > compositor and or video encoding processes (for video capture). > > Additionally, from what I understand, sync_file is the standard way to > > export and import explicit synchronization between processes and > > between drivers on Linux, so it seems like a good idea to support it > > from an interoperability standpoint even if it turns out that there > > aren't any scheduling/timing benefits. > > There are different ways that one can handle interoperability, > however. One way is to try and make the software rasterizer look as > much like a GPU as possible: lots of threads to make things as > asynchronous as possible, "real" implementations of semaphores and > fences, etc. This is basically the route I've picked, though rather than making lots of native threads, I'm planning on having just one thread per core and have a work-stealing scheduler (inspired by Rust's rayon crate) schedule all the individual render/compute jobs, because that allows making a lot more jobs to allow finer load balancing. > Another is to let a SW rasterizer be a SW rasterizer: do > everything immediately, thread only so you can exercise all the CPU > cores, and minimally implement semaphores and fences well enough to > maintain compatibility. If you take the first approach, then we have > to solve all these problems with letting userspace create unsignaled > sync_files which it will signal later and figure out how to make it > safe. If you take the second approach, you'll only ever have to > return already signaled sync_files and there's no problem with the > sync_file finite time guarantees. The main issue with doing everything immediately is that a lot of the function calls that games expect to take a very short time (e.g. vkQueueSubmit) would instead take a much longer time, potentially causing problems. One idea for a safe userspace-backed sync_file is to have a step counter that counts down until the sync_file is ready, where if userspace doesn't tell it to count any steps in a certain amount of time, then the sync_file switches to the error state. This way, it will error shortly after a process deadlocks for some reason, while still having the finite-time guarantee. When the sync_file is created, the step counter would be set to the number of jobs that the fence is waiting on. It can also be set to pause the timeout to wait until another sync_file signals, to handle cases where a sync_file is waiting on a userspace process that is waiting on another sync_file. The main issue is that the kernel would have to make sure that the sync_file graph doesn't have loops, maybe by erroring all sync_files that it finds in the loop. Does that sound like a good idea? Jacob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Dave, 20. 3. 18. 오전 11:17에 Dave Airlie 이(가) 쓴 글: > This seems to contain a exynos drm fixes backmerge, please don't do > that without a headsup. > > Can you send one without that or do you need a fixes backmerge, if so > please request me to do that first, then rebase this and send it. Sorry for confusing you. Dropped the backmerge from exynos drm fixes and pushed it again. Please let me know if there is any problem. Thanks, Inki Dae > > Dave. > > On Mon, 16 Mar 2020 at 11:04, Inki Dae wrote: >> >> Just two cleanups - one is to mask encoder bitmask using >> drm_encoder_mask(), and other is to use mode->clock >> instead of calculating it again. >> >> Please kindly let me know if there is any problem. >> >> Thanks, >> Inki Dae >> >> The following changes since commit 69ddce0970d9d1de63bed9c24eefa0814db29a5a: >> >> Merge tag 'amd-drm-next-5.7-2020-03-10' of >> git://people.freedesktop.org/~agd5f/linux into drm-next (2020-03-13 09:09:11 >> +1000) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos >> tags/exynos-drm-next-for-v5.7 >> >> for you to fetch changes up to 0c9a609ca444298e438ee9c6daaf53c14277f1ad: >> >> drm/exynos: Use mode->clock instead of reverse calculating it from the >> vrefresh (2020-03-16 09:50:28 +0900) >> >> >> Two cleanups >> . Replace the hand rolled encoder bitmask thing with drm_encoder_mask() >> . Use mode->clock instead of reverse calculating it from the vrefresh >> >> >> Inki Dae (1): >> Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of >> git://git.kernel.org/.../daeinki/drm-exynos into exynos-drm-next >> >> Marek Szyprowski (1): >> drm/exynos: Fix cleanup of IOMMU related objects >> >> Ville Syrjälä (2): >> drm/exynos: Use drm_encoder_mask() >> drm/exynos: Use mode->clock instead of reverse calculating it from the >> vrefresh >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 --- >> drivers/gpu/drm/exynos/exynos_drm_dma.c | 28 >> ++- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 -- >> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 -- >> drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-- >> 12 files changed, 56 insertions(+), 33 deletions(-) >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://protect2.fireeye.com/url?k=2f99e96f-720f5018-2f986220-0cc47a312ab0-6a58a038adb2e152=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
linux-next: manual merge of the drm tree with the omap tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
arch/arm/configs/omap2plus_defconfig
between commit:
98c2cc359f8f ("ARM: omap2plus_defconfig: Update for moved and dropped
options")
from the omap tree and commit:
e7e67d9a2f1d ("drm/omap: Switch the HDMI and VENC outputs to drm_bridge")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/configs/omap2plus_defconfig
index eedb26ff93f9,54f1a21de7e0..
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@@ -360,10 -353,10 +360,9 @@@ CONFIG_OMAP2_DSS_DSI=
CONFIG_DRM_OMAP_PANEL_DSI_CM=m
CONFIG_DRM_TILCDC=m
CONFIG_DRM_PANEL_SIMPLE=m
+ CONFIG_DRM_DISPLAY_CONNECTOR=m
+ CONFIG_DRM_SIMPLE_BRIDGE=m
-CONFIG_DRM_TI_TFP410=m
+ CONFIG_DRM_TI_TPD12S015=m
CONFIG_DRM_PANEL_LG_LB035Q02=m
CONFIG_DRM_PANEL_NEC_NL8048HL11=m
CONFIG_DRM_PANEL_SHARP_LS037V7DW01=m
pgpI8nRxUw1nA.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
This seems to contain a exynos drm fixes backmerge, please don't do that without a headsup. Can you send one without that or do you need a fixes backmerge, if so please request me to do that first, then rebase this and send it. Dave. On Mon, 16 Mar 2020 at 11:04, Inki Dae wrote: > > Just two cleanups - one is to mask encoder bitmask using > drm_encoder_mask(), and other is to use mode->clock > instead of calculating it again. > > Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit 69ddce0970d9d1de63bed9c24eefa0814db29a5a: > > Merge tag 'amd-drm-next-5.7-2020-03-10' of > git://people.freedesktop.org/~agd5f/linux into drm-next (2020-03-13 09:09:11 > +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > tags/exynos-drm-next-for-v5.7 > > for you to fetch changes up to 0c9a609ca444298e438ee9c6daaf53c14277f1ad: > > drm/exynos: Use mode->clock instead of reverse calculating it from the > vrefresh (2020-03-16 09:50:28 +0900) > > > Two cleanups > . Replace the hand rolled encoder bitmask thing with drm_encoder_mask() > . Use mode->clock instead of reverse calculating it from the vrefresh > > > Inki Dae (1): > Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of > git://git.kernel.org/.../daeinki/drm-exynos into exynos-drm-next > > Marek Szyprowski (1): > drm/exynos: Fix cleanup of IOMMU related objects > > Ville Syrjälä (2): > drm/exynos: Use drm_encoder_mask() > drm/exynos: Use mode->clock instead of reverse calculating it from the > vrefresh > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +++-- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 --- > drivers/gpu/drm/exynos/exynos_drm_dma.c | 28 > ++- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 -- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 -- > drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-- > 12 files changed, 56 insertions(+), 33 deletions(-) > ___ > 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: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote: > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote: > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > I think I found a userspace-accessible way to create sync_files and > > > dma_fences that would fulfill the requirements: > > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > > > I'm just not sure if that's a good interface to use, since it appears > > > to be designed only for debugging. Will have to check for additional > > > requirements of signalling an error when the process that created the > > > fence is killed. It is expressly only for debugging and testing. Exposing such an API to userspace would break the finite time guarantees that are relied upon to keep sync_file a secure API. > > Something like that can certainly be lifted for general use if it makes > > sense. But then with a software renderer I don't really see how fences > > help you at all. With a software renderer you know exactly when the > > frame is finished and you can just defer pushing it over to the next > > pipeline element until that time. You won't gain any parallelism by > > using fences as the CPU is busy doing the rendering and will not run > > other stuff concurrently, right? > > There definitely may be other hardware and/or processes that can > process some stuff concurrently with the main application, such as the > compositor and or video encoding processes (for video capture). > Additionally, from what I understand, sync_file is the standard way to > export and import explicit synchronization between processes and > between drivers on Linux, so it seems like a good idea to support it > from an interoperability standpoint even if it turns out that there > aren't any scheduling/timing benefits. There are different ways that one can handle interoperability, however. One way is to try and make the software rasterizer look as much like a GPU as possible: lots of threads to make things as asynchronous as possible, "real" implementations of semaphores and fences, etc. Another is to let a SW rasterizer be a SW rasterizer: do everything immediately, thread only so you can exercise all the CPU cores, and minimally implement semaphores and fences well enough to maintain compatibility. If you take the first approach, then we have to solve all these problems with letting userspace create unsignaled sync_files which it will signal later and figure out how to make it safe. If you take the second approach, you'll only ever have to return already signaled sync_files and there's no problem with the sync_file finite time guarantees. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 01/11] drm/i915: Use 64-bit division macro
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: "Ville Syrjälä" Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Rodrigo Vivi Cc: Maarten Lankhorst Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index bc14e9c..843cac1 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( + panel->backlight.level = DIV_ROUND_UP_ULL( pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.enabled = panel->backlight.level != 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 10/11] backlight: pwm_bl: Use 64-bit division function
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: Guru Das Srinagesh Reviewed-by: Daniel Thompson --- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index efb4efc..3e5dbcf 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, + pb->scale)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment
Yes, I will do it. On Tue, Mar 17, 2020 at 2:04 PM Daniel Vetter wrote: > On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote: > > Ccing dri-devel and linux-kernel. > > git apply-mbox chokes on this, can you pls resubmit? > > Thanks, Daniel > > > > > -- Forwarded message - > > From: Igor Matheus Andrade Torrente > > Date: Mon, Mar 16, 2020 at 6:04 PM > > Subject: [PATCH] Staging: drm_gem: Fix a typo in a function comment > > To: , , > > , , , < > > sumit.sem...@linaro.org> > > Cc: Igor Matheus Andrade Torrente , < > > rodrigo.sique...@amd.com>, , < > > andrealm...@collabora.com> > > > > > > Replace "pionter" with "pointer" in the > > drm_gem_handle_create description. > > > > Signed-off-by: Igor Matheus Andrade Torrente > > --- > > drivers/gpu/drm/drm_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > index 6e960d57371e..c356379f5e97 100644 > > --- a/drivers/gpu/drm/drm_gem.c > > +++ b/drivers/gpu/drm/drm_gem.c > > @@ -432,7 +432,7 @@ drm_gem_handle_create_tail(struct drm_file > *file_priv, > > * drm_gem_handle_create - create a gem handle for an object > > * @file_priv: drm file-private structure to register the handle for > > * @obj: object to register > > - * @handlep: pionter to return the created handle to the caller > > + * @handlep: pointer to return the created handle to the caller > > * > > * Create a handle for this object. This adds a handle reference to the > > object, > > * which includes a regular reference count. Callers will likely want to > > -- > > 2.20.1 > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
Le mardi 17 mars 2020 à 11:27 -0500, Jason Ekstrand a écrit : > On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne > wrote: > > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > > > Hi Jason, > > > > > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote: > > > > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote: > > > > > > (I know I'm going to be spammed by so many mailing list ...) > > > > > > > > > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > > > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > > > > > > wrote: > > > > > > > > All, > > > > > > > > > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most > > > > > > > > people > > > > > > > > who reply will get at least one mailing list rejection. > > > > > > > > However, this > > > > > > > > is an issue that affects a LOT of components and that's why it's > > > > > > > > thorny to begin with. Please pardon the length of this e-mail > > > > > > > > as > > > > > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. > > > > > > > > At > > > > > > > > least, that seems to be the consensus among all the graphics > > > > > > > > people > > > > > > > > I've talked to. I had a chat with one of the lead Android > > > > > > > > graphics > > > > > > > > engineers recently who told me that doing explicit sync from > > > > > > > > the start > > > > > > > > was one of the best engineering decisions Android ever made. > > > > > > > > It's > > > > > > > > also the direction being taken by more modern APIs such as > > > > > > > > Vulkan. > > > > > > > > > > > > > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > > > > > > > > > For those that aren't familiar with this space, GPUs, media > > > > > > > > encoders, > > > > > > > > etc. are massively parallel and synchronization of some form is > > > > > > > > required to ensure that everything happens in the right order > > > > > > > > and > > > > > > > > avoid data races. Implicit synchronization is when bits of > > > > > > > > work (3D, > > > > > > > > compute, video encode, etc.) are implicitly based on the > > > > > > > > absolute > > > > > > > > CPU-time order in which API calls occur. Explicit > > > > > > > > synchronization is > > > > > > > > when the client (whatever that means in any given context) > > > > > > > > provides > > > > > > > > the dependency graph explicitly via some sort of synchronization > > > > > > > > primitives. If you're still confused, consider the following > > > > > > > > examples: > > > > > > > > > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say > > > > > > > > you have > > > > > > > > two OpenGL contexts sharing an image where one writes to it and > > > > > > > > the > > > > > > > > other textures from it. The way the OpenGL spec works, the > > > > > > > > client has > > > > > > > > to make the API calls to render to the image before (in CPU > > > > > > > > time) it > > > > > > > > makes the API calls which texture from the image. As long as > > > > > > > > it does > > > > > > > > this (and maybe inserts a glFlush?), the driver will ensure > > > > > > > > that the > > > > > > > > rendering completes before the texturing happens and you get > > > > > > > > correct > > > > > > > > contents. > > > > > > > > > > > > > > > > Implicit synchronization can also happen across processes. > > > > > > > > Wayland, > > > > > > > > for instance, is currently built on implicit sync where the > > > > > > > > client > > > > > > > > does their rendering and then does a hand-off (via > > > > > > > > wl_surface::commit) > > > > > > > > to tell the compositor it's done at which point the compositor > > > > > > > > can now > > > > > > > > texture from the surface. The hand-off ensures that the > > > > > > > > client's > > > > > > > > OpenGL API calls happen before the server's OpenGL API calls. > > > > > > > > > > > > > > > > A good example of explicit synchronization is the Vulkan API. > > > > > > > > There, > > > > > > > > a client (or multiple clients) can simultaneously build command > > > > > > > > buffers in different threads where one of those command buffers > > > > > > > > renders to an image and the other textures from it and then > > > > > > > > submit > > > > > > > > both of them at the same time with instructions to the driver > > > > > > > > for > > > > > > > > which order to execute them in. The execution order is > > > > > > > > described via > > > > > > > > the VkSemaphore primitive. With the new > > > > > > > > VK_KHR_timeline_semaphore > > > > > > > > extension, you can even submit the work which does the texturing > > > > > > > > BEFORE the work which does the rendering and
[PATCH v2] drm: Correct a typo in a function comment
Replace "pionter" with "pointer" in the drm_gem_handle_create description. Changes in v2: - Change subject text Signed-off-by: Igor Matheus Andrade Torrente --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 6e960d57371e..c356379f5e97 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -432,7 +432,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, * drm_gem_handle_create - create a gem handle for an object * @file_priv: drm file-private structure to register the handle for * @obj: object to register - * @handlep: pionter to return the created handle to the caller + * @handlep: pointer to return the created handle to the caller * * Create a handle for this object. This adds a handle reference to the object, * which includes a regular reference count. Callers will likely want to -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Tue, Mar 17, 2020 at 01:59:55PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: > > I've been using v7 of Ralph's tester and it is working well - it has > > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are > > you able? > > > > This hunk seems trivial enough to me, can we include it now? > > I can send a separate patch for it once the tester covers it. I don't > want to add it to the original patch as it is a significant behavior > change compared to the existing code. Okay. I'm happy enough for now that amdgpu will get ERROR on device_private pages. That is a bug fix in of itself. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 00/11] Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ Guru Das Srinagesh (11): drm/i915: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro ir-rx51: Use 64-bit division macro pwm: clps711x: Use 64-bit division macro pwm: pwm-imx-tpm: Use 64-bit division macro pwm: imx27: Use 64-bit division macro and function pwm: sifive: Use 64-bit division macro pwm: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function pwm: core: Convert period and duty cycle to u64 drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c| 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c| 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c| 2 +- drivers/pwm/sysfs.c| 8 drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h| 12 ++-- 13 files changed, 25 insertions(+), 24 deletions(-) Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Philipp Zabel Cc: Fabrice Gasnier Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: linux-ri...@lists.infradead.org Cc: Yash Shah Cc: Atish Patra Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Alexander Shiyan Cc: Mauro Carvalho Chehab Cc: Richard Fontana Cc: Thomas Gleixner Cc: Kate Stewart Cc: Allison Randal Cc: linux-me...@vger.kernel.org Cc: Kamil Debski Cc: Bartlomiej Zolnierkiewicz Cc: Jean Delvare Cc: Guenter Roeck Cc: Liam Girdwood Cc: Mark Brown Cc: linux-hw...@vger.kernel.org Cc: Jani Nikula Cc: Joonas
Re: [PATCH RESEND] drm/lease: fix potential race in fill_object_idr
On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter wrote: > > On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote: > > We should hold idr_mutex for idr_alloc. > > > > Signed-off-by: Qiujun Huang > > I've not seen the first version of this anywhere in my inbox, not sure > where that got lost. > > Anyway, this seems like a false positive - I'm assuming this was caught > with KCSAN. The commit message really should mention that. > > fill_object_idr creates the idr, which yes is only access later on under > the idr_mutex. But here it's not yet visible to any other thread, and > hence lockless access is safe and correct. Agree that. Thanks. > > No idea what the KCSAN complains about safe access like this best practice > is. > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Initialize shadow to false in gfx_v9_0_rlcg_wreg
clang warns:
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow'
is used uninitialized whenever 'if' condition is
false [-Wsometimes-uninitialized]
if (offset == grbm_cntl || offset == grbm_idx)
^
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:757:6: note: uninitialized use
occurs here
if (shadow) {
^~
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:2: note: remove the 'if' if
its condition is always true
if (offset == grbm_cntl || offset == grbm_idx)
^~
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:738:13: note: initialize the
variable 'shadow' to silence this warning
bool shadow;
^
= 0
1 warning generated.
It is not wrong so initialize shadow to false to ensure shadow is always
used initialized.
Fixes: 2e0cc4d48b91 ("drm/amdgpu: revise RLCG access path")
Link: https://github.com/ClangBuiltLinux/linux/issues/936
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 7bc2486167e7..affbff76758c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -735,7 +735,7 @@ void gfx_v9_0_rlcg_wreg(struct amdgpu_device *adev, u32
offset, u32 v)
static void *spare_int;
static uint32_t grbm_cntl;
static uint32_t grbm_idx;
- bool shadow;
+ bool shadow = false;
scratch_reg0 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG0_BASE_IDX] + mmSCRATCH_REG0)*4;
scratch_reg1 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG1_BASE_IDX] + mmSCRATCH_REG1)*4;
--
2.26.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lease: fix WARNING in idr_destroy
On Wed, Mar 18, 2020 at 12:57 AM Daniel Vetter wrote:
>
> On Mon, Mar 16, 2020 at 11:36:08AM +0800, Qiujun Huang wrote:
> > leases has been destroyed:
> > drm_master_put
> > ->drm_master_destroy
> > ->idr_destroy
> >
> > so the "out_lessee" needn't to call idr_destroy again.
> >
> > Reported-and-tested-by:
> > syzbot+05835159fe322770f...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang
> > ---
> > drivers/gpu/drm/drm_lease.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> > index b481caf..54506c2 100644
> > --- a/drivers/gpu/drm/drm_lease.c
> > +++ b/drivers/gpu/drm/drm_lease.c
> > @@ -577,11 +577,14 @@ int drm_mode_create_lease_ioctl(struct drm_device
> > *dev,
> >
> > out_lessee:
> > drm_master_put();
> > + goto err_exit;
>
> I think this is correct, but also confusioning and inconsistent with the
> existing style. Most error cases before drm_lease_create explicit destroy
> the idr, except the one for drm_lease_create.
Yeah, it is.
>
> Instead of your patch I'd
> - remove the idr_destry from the error unrolling here
> - add it the to drm_lease_create error case
> - add a comment above the call to drm_lease_crete that it takes ownership
> of the lease idr
>
> Can you pls respin and retest to make sure that patch is still correct?
I get that, thanks.
>
> Thanks, Daniel
>
> >
> > out_leases:
> > - put_unused_fd(fd);
> > idr_destroy();
> >
> > +err_exit:
> > + put_unused_fd(fd);
> > +
> > DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
> > return ret;
> > }
> > --
> > 1.8.3.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: Plumbing explicit synchronization through the Linux ecosystem
Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > Hi Jason, > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote: > > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote: > > > > (I know I'm going to be spammed by so many mailing list ...) > > > > > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > > > > wrote: > > > > > > All, > > > > > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most > > > > > > people > > > > > > who reply will get at least one mailing list rejection. However, > > > > > > this > > > > > > is an issue that affects a LOT of components and that's why it's > > > > > > thorny to begin with. Please pardon the length of this e-mail as > > > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. At > > > > > > least, that seems to be the consensus among all the graphics people > > > > > > I've talked to. I had a chat with one of the lead Android graphics > > > > > > engineers recently who told me that doing explicit sync from the > > > > > > start > > > > > > was one of the best engineering decisions Android ever made. It's > > > > > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > > > > > For those that aren't familiar with this space, GPUs, media > > > > > > encoders, > > > > > > etc. are massively parallel and synchronization of some form is > > > > > > required to ensure that everything happens in the right order and > > > > > > avoid data races. Implicit synchronization is when bits of work > > > > > > (3D, > > > > > > compute, video encode, etc.) are implicitly based on the absolute > > > > > > CPU-time order in which API calls occur. Explicit synchronization > > > > > > is > > > > > > when the client (whatever that means in any given context) provides > > > > > > the dependency graph explicitly via some sort of synchronization > > > > > > primitives. If you're still confused, consider the following > > > > > > examples: > > > > > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say you > > > > > > have > > > > > > two OpenGL contexts sharing an image where one writes to it and the > > > > > > other textures from it. The way the OpenGL spec works, the client > > > > > > has > > > > > > to make the API calls to render to the image before (in CPU time) it > > > > > > makes the API calls which texture from the image. As long as it > > > > > > does > > > > > > this (and maybe inserts a glFlush?), the driver will ensure that the > > > > > > rendering completes before the texturing happens and you get correct > > > > > > contents. > > > > > > > > > > > > Implicit synchronization can also happen across processes. Wayland, > > > > > > for instance, is currently built on implicit sync where the client > > > > > > does their rendering and then does a hand-off (via > > > > > > wl_surface::commit) > > > > > > to tell the compositor it's done at which point the compositor can > > > > > > now > > > > > > texture from the surface. The hand-off ensures that the client's > > > > > > OpenGL API calls happen before the server's OpenGL API calls. > > > > > > > > > > > > A good example of explicit synchronization is the Vulkan API. > > > > > > There, > > > > > > a client (or multiple clients) can simultaneously build command > > > > > > buffers in different threads where one of those command buffers > > > > > > renders to an image and the other textures from it and then submit > > > > > > both of them at the same time with instructions to the driver for > > > > > > which order to execute them in. The execution order is described > > > > > > via > > > > > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > > > > > extension, you can even submit the work which does the texturing > > > > > > BEFORE the work which does the rendering and the driver will sort it > > > > > > out. > > > > > > > > > > > > The #1 problem with implicit synchronization (which explicit solves) > > > > > > is that it leads to a lot of over-synchronization both in client > > > > > > space > > > > > > and in driver/device space. The client has to synchronize a lot > > > > > > more > > > > > > because it has to ensure that the API calls happen in a particular > > > > > > order. The driver/device have to synchronize a lot more because > > > > > > they > > > > > > never know what is going to end up being a synchronization point as > > > > > > an > > > > > > API call on another thread/process may occur at any time. As we > > > > > > move > > > > > > to more and more multi-threaded programming this
[PATCH v2] drm: Alligne a comment block
Fix a checkpatch warning caused by a misaligned comment block.
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 000fa4a1899f..6e960d57371e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -222,10 +222,10 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object
*obj)
return;
/*
- * Must bump handle count first as this may be the last
- * ref, in which case the object would disappear before we
- * checked for a name
- */
+* Must bump handle count first as this may be the last
+* ref, in which case the object would disappear before we
+* checked for a name
+*/
mutex_lock(>object_name_lock);
if (--obj->handle_count == 0) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 20 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 716 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 24 +- drivers/gpu/drm/nouveau/dispnv50/disp.h | 10 + drivers/gpu/drm/nouveau/dispnv50/handles.h | 1 + drivers/gpu/drm/nouveau/dispnv50/head.c | 85 ++- drivers/gpu/drm/nouveau/dispnv50/head.h | 11 +- drivers/gpu/drm/nouveau/dispnv50/head907d.c | 14 +- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 6 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 7 +-
[PATCH 9/9] drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 20 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 716 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 24 +- drivers/gpu/drm/nouveau/dispnv50/disp.h | 10 + drivers/gpu/drm/nouveau/dispnv50/handles.h | 1 + drivers/gpu/drm/nouveau/dispnv50/head.c | 85 ++- drivers/gpu/drm/nouveau/dispnv50/head.h | 11 +- drivers/gpu/drm/nouveau/dispnv50/head907d.c | 14 +- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 6 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 7 +- drivers/gpu/drm/nouveau/nouveau_display.c | 60 +- 21 files changed, 1342 insertions(+), 74 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c create mode 100644
[PATCH 2/9] drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create()
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8f6455697ba7..e29ea40e7c33 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -507,20 +507,28 @@ nv50_head_create(struct drm_device *dev, int index)
if (disp->disp->object.oclass < GV100_DISP) {
ret = nv50_base_new(drm, head->base.index, );
+ if (ret)
+ goto fail_free;
+
ret = nv50_ovly_new(drm, head->base.index, );
+ if (ret)
+ goto fail_free;
} else {
ret = nv50_wndw_new(drm, DRM_PLANE_TYPE_PRIMARY,
head->base.index * 2 + 0, );
+ if (ret)
+ goto fail_free;
+
ret = nv50_wndw_new(drm, DRM_PLANE_TYPE_OVERLAY,
head->base.index * 2 + 1, );
- }
- if (ret == 0)
- ret = nv50_curs_new(drm, head->base.index, );
- if (ret) {
- kfree(head);
- return ERR_PTR(ret);
+ if (ret)
+ goto fail_free;
}
+ ret = nv50_curs_new(drm, head->base.index, );
+ if (ret)
+ goto fail_free;
+
crtc = >base.base;
drm_crtc_init_with_planes(dev, crtc, >plane, >plane,
_head_func, "head-%d", head->base.index);
@@ -533,11 +541,16 @@ nv50_head_create(struct drm_device *dev, int index)
if (head->func->olut_set) {
ret = nv50_lut_init(disp, >client.mmu, >olut);
- if (ret) {
- nv50_head_destroy(crtc);
- return ERR_PTR(ret);
- }
+ if (ret)
+ goto fail_crtc_cleanup;
}
return head;
+
+fail_crtc_cleanup:
+ drm_crtc_cleanup(crtc);
+fail_free:
+ kfree(head);
+
+ return ERR_PTR(ret);
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 --
drivers/gpu/drm/nouveau/dispnv50/disp.h | 14 ++
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index f510eeafca4b..ef01f2473947 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -56,24 +56,6 @@
#include
-/**
- * Atomic state
- */
-
-struct nv50_outp_atom {
- struct list_head head;
-
- struct drm_encoder *encoder;
- bool flush_disable;
-
- union nv50_outp_atom_mask {
- struct {
- bool ctrl:1;
- };
- u8 mask;
- } set, clr;
-};
-
/**
* EVO channel
*/
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index d54fe00ac3a3..8935ebce8ab0 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -70,6 +70,20 @@ struct nv50_dmac {
struct mutex lock;
};
+struct nv50_outp_atom {
+ struct list_head head;
+
+ struct drm_encoder *encoder;
+ bool flush_disable;
+
+ union nv50_outp_atom_mask {
+ struct {
+ bool ctrl:1;
+ };
+ u8 mask;
+ } set, clr;
+};
+
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
u64 syncbuf, struct nv50_dmac *dmac);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/nouveau/kms/nv50-: Move hard-coded object handles into header
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just go ahead and move any hard-coded
handles into a single header. This is just to keep things slightly
organized, and to make it a little bit easier if we need to add more
handles in the future.
This patch should contain no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c| 7 +--
drivers/gpu/drm/nouveau/dispnv50/handles.h | 15 +++
drivers/gpu/drm/nouveau/dispnv50/wndw.c| 3 ++-
3 files changed, 22 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ef01f2473947..bfea85782d0e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -26,6 +26,7 @@
#include "core.h"
#include "head.h"
#include "wndw.h"
+#include "handles.h"
#include
#include
@@ -153,7 +154,8 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (!syncbuf)
return 0;
- ret = nvif_object_init(>base.user, 0xf000, NV_DMA_IN_MEMORY,
+ ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_SYNCBUF,
+ NV_DMA_IN_MEMORY,
&(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
@@ -164,7 +166,8 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- ret = nvif_object_init(>base.user, 0xf001, NV_DMA_IN_MEMORY,
+ ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_VRAM,
+ NV_DMA_IN_MEMORY,
&(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/handles.h
b/drivers/gpu/drm/nouveau/dispnv50/handles.h
new file mode 100644
index ..e3a62c7a0d08
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/dispnv50/handles.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+#ifndef __NV50_KMS_HANDLES_H__
+#define __NV50_KMS_HANDLES_H__
+
+/*
+ * Various hard-coded object handles that nouveau uses. These are made-up by
+ * nouveau developers, not Nvidia. The only significance of the handles chosen
+ * is that they must all be unique.
+ */
+#define NV50_DISP_HANDLE_SYNCBUF
0xf000
+#define NV50_DISP_HANDLE_VRAM
0xf001
+
+#define NV50_DISP_HANDLE_WNDW_CTX(kind)(0xfb00 |
kind)
+
+#endif /* !__NV50_KMS_HANDLES_H__ */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 39cca8eaa066..cb67a715bd69 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -21,6 +21,7 @@
*/
#include "wndw.h"
#include "wimm.h"
+#include "handles.h"
#include
#include
@@ -44,7 +45,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct
nouveau_framebuffer *fb)
struct nouveau_drm *drm = nouveau_drm(fb->base.dev);
struct nv50_wndw_ctxdma *ctxdma;
const u8kind = fb->nvbo->kind;
- const u32 handle = 0xfb00 | kind;
+ const u32 handle = NV50_DISP_HANDLE_WNDW_CTX(kind);
struct {
struct nv_dma_v0 base;
union {
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's depth in the atomic state hasn't been modified.
Normally this wouldn't matter, since we don't modify OR state outside of
modesets, but since the CRC capture region is implemented as part of the
OR state in hardware we'll want to make sure all commits modifying OR
state are idempotent so as to avoid changing the depth unexpectedly.
So, fix this by simply not writing the reduced depth value we come up
with to the atomic state.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 11 +++
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 11 +++
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 00011ce109a6..68920f8d9c79 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -27,17 +27,20 @@ static void
headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+ u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
* improved later for deep colour etc.
*/
switch (asyh->or.depth) {
- case 6: asyh->or.depth = 5; break;
- case 5: asyh->or.depth = 4; break;
- case 2: asyh->or.depth = 1; break;
- case 0: asyh->or.depth = 4; break;
+ case 6: depth = 5; break;
+ case 5: depth = 4; break;
+ case 2: depth = 1; break;
+ case 0: depth = 4; break;
default:
+ depth = asyh->or.depth;
WARN_ON(1);
break;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 938d910a1b1e..0296cd1d761f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -27,17 +27,20 @@ static void
headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+ u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
* improved later for deep colour etc.
*/
switch (asyh->or.depth) {
- case 6: asyh->or.depth = 5; break;
- case 5: asyh->or.depth = 4; break;
- case 2: asyh->or.depth = 1; break;
- case 0: asyh->or.depth = 4; break;
+ case 6: depth = 5; break;
+ case 5: depth = 4; break;
+ case 2: depth = 1; break;
+ case 0: depth = 4; break;
default:
+ depth = asyh->or.depth;
WARN_ON(1);
break;
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/nouveau/kms/nv50-: Fix disabling dithering
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index e29ea40e7c33..72bc3bce396a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -84,18 +84,20 @@ nv50_head_atomic_check_dither(struct nv50_head_atom *armh,
{
u32 mode = 0x00;
- if (asyc->dither.mode == DITHERING_MODE_AUTO) {
- if (asyh->base.depth > asyh->or.bpc * 3)
- mode = DITHERING_MODE_DYNAMIC2X2;
- } else {
- mode = asyc->dither.mode;
- }
+ if (asyc->dither.mode) {
+ if (asyc->dither.mode == DITHERING_MODE_AUTO) {
+ if (asyh->base.depth > asyh->or.bpc * 3)
+ mode = DITHERING_MODE_DYNAMIC2X2;
+ } else {
+ mode = asyc->dither.mode;
+ }
- if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
- if (asyh->or.bpc >= 8)
- mode |= DITHERING_DEPTH_8BPC;
- } else {
- mode |= asyc->dither.depth;
+ if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
+ if (asyh->or.bpc >= 8)
+ mode |= DITHERING_DEPTH_8BPC;
+ } else {
+ mode |= asyc->dither.depth;
+ }
}
asyh->dither.enable = mode;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/nouveau/kms/nv50-: s/harm/armh/g
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index bb737f9281e6..39cca8eaa066 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -397,7 +397,7 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct
drm_plane_state *state)
struct nv50_wndw *wndw = nv50_wndw(plane);
struct nv50_wndw_atom *armw = nv50_wndw_atom(wndw->plane.state);
struct nv50_wndw_atom *asyw = nv50_wndw_atom(state);
- struct nv50_head_atom *harm = NULL, *asyh = NULL;
+ struct nv50_head_atom *armh = NULL, *asyh = NULL;
bool modeset = false;
int ret;
@@ -418,9 +418,9 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct
drm_plane_state *state)
/* Fetch assembly state for the head the window used to belong to. */
if (armw->state.crtc) {
- harm = nv50_head_atom_get(asyw->state.state, armw->state.crtc);
- if (IS_ERR(harm))
- return PTR_ERR(harm);
+ armh = nv50_head_atom_get(asyw->state.state, armw->state.crtc);
+ if (IS_ERR(armh))
+ return PTR_ERR(armh);
}
/* LUT configuration can potentially cause the window to be disabled. */
@@ -444,8 +444,8 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct
drm_plane_state *state)
asyh->wndw.mask |= BIT(wndw->id);
} else
if (armw->visible) {
- nv50_wndw_atomic_check_release(wndw, asyw, harm);
- harm->wndw.mask &= ~BIT(wndw->id);
+ nv50_wndw_atomic_check_release(wndw, asyw, armh);
+ armh->wndw.mask &= ~BIT(wndw->id);
} else {
return 0;
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason we'll need this is for CRC support.
See: on nvidia hardware, each CRC entry in the CRC notifier dma context
has a "tag". This tag corresponds to the nth update on a specific
EVO/NvDisplay channel, which itself is referred to as the "controlling
channel". For gf119+ this can be the core channel, ovly channel, or base
channel. Since we don't expose CRC entry tags to userspace, we simply
ignore this feature and always use the core channel as the controlling
channel. Simple.
Things get a little bit more complicated on gv100+ though. GV100+ only
lets us set the controlling channel to a specific wndw channel, and that
wndw must be owned by the head that we're grabbing CRCs when we enable
CRC generation. Thus, we always need to make sure that each atomic head
state has at least one wndw that is mapped to the head, which will be
used as the controlling channel.
Note that since we don't have flexible wndw mappings yet, we don't
expect to run into any scenarios yet where we'd have a head with no
mapped wndws. When we do add support for flexible wndw mappings however,
we'll need to make sure that we handle reprogramming CRC capture if our
controlling wndw is moved to another head (and potentially reject the
new head state entirely if we can't find another available wndw to
replace it).
With that being said, nouveau currently tracks wndw visibility on heads.
It does not keep track of the actual ownership mappings, which are
(currently) statically programmed. To fix this, we introduce another
bitmask into nv50_head_atom.wndw to keep track of ownership separately
from visibility. We then introduce a nv50_head callback to handle
populating the wndw ownership map, and call it during the atomic check
phase when core->assign_windows is set to true.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 16
drivers/gpu/drm/nouveau/dispnv50/head.h | 2 ++
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 10 ++
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 ++
5 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 24f7700768da..62faaf60f47a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -18,6 +18,7 @@ struct nv50_head_atom {
struct {
u32 mask;
+ u32 owned;
u32 olut;
} wndw;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 4d1c58468dbc..f510eeafca4b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2253,12 +2253,28 @@ static int
nv50_disp_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
{
struct nv50_atom *atom = nv50_atom(state);
+ struct nv50_core *core = nv50_disp(dev)->core;
struct drm_connector_state *old_connector_state, *new_connector_state;
struct drm_connector *connector;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+ struct nv50_head *head;
+ struct nv50_head_atom *asyh;
int ret, i;
+ if (core->assign_windows && core->func->head->static_wndw_map) {
+ drm_for_each_crtc(crtc, dev) {
+ new_crtc_state = drm_atomic_get_crtc_state(state,
+ crtc);
+ if (IS_ERR(new_crtc_state))
+ return PTR_ERR(new_crtc_state);
+
+ head = nv50_head(crtc);
+ asyh = nv50_head_atom(new_crtc_state);
+ core->func->head->static_wndw_map(head, asyh);
+ }
+ }
+
/* We need to handle colour management on a per-plane basis. */
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->color_mgmt_changed) {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h
b/drivers/gpu/drm/nouveau/dispnv50/head.h
index c32b27cdaefc..c05bbba9e247 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
@@ -40,6 +40,7 @@ struct nv50_head_func {
void (*dither)(struct nv50_head *, struct nv50_head_atom *);
void (*procamp)(struct nv50_head *, struct nv50_head_atom *);
void (*or)(struct nv50_head *, struct nv50_head_atom *);
+ void (*static_wndw_map)(struct nv50_head *, struct nv50_head_atom *);
};
extern const struct nv50_head_func head507d;
@@ -86,6 +87,7 @@ int headc37d_curs_format(struct
[PATCH 0/9] drm/nouveau: Introduce CRC support for gf119+
Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrjälä came up with: vblank works. Basically, this is just a generic DRM interface that allows for scheduling high-priority workers that start on a given vblank interrupt. Note that while we're currently only using this in nouveau, Intel has plans to use this for i915 as well (hence why they came up with it!). Anyway-welcome to the future! :) Lyude Paul (8): drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create() drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit drm/nouveau/kms/nv50-: Fix disabling dithering drm/nouveau/kms/nv50-: s/harm/armh/g drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h drm/nouveau/kms/nv50-: Move hard-coded object handles into header drm/nouveau/kms/nvd9-: Add CRC support Ville Syrjälä (1): drm/vblank: Add vblank works drivers/gpu/drm/drm_vblank.c| 322 + drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 21 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 716 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 65 +- drivers/gpu/drm/nouveau/dispnv50/disp.h | 24 + drivers/gpu/drm/nouveau/dispnv50/handles.h | 16 + drivers/gpu/drm/nouveau/dispnv50/head.c | 142 +++- drivers/gpu/drm/nouveau/dispnv50/head.h | 13 +- drivers/gpu/drm/nouveau/dispnv50/head907d.c | 14 +- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 27 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 20 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 15 +- drivers/gpu/drm/nouveau/nouveau_display.c | 60 +- include/drm/drm_vblank.h| 34 + 24 files changed, 1821 insertions(+), 130 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.h create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc907d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/vblank: Add vblank works
From: Ville Syrjälä
Add some kind of vblank workers. The interface is similar to regular
delayed works, and also allows for re-scheduling.
Whatever hardware programming we do in the work must be fast
(must at least complete during the vblank, sometimes during
the first few scanlines of vblank), so we'll fire up a per-crtc
high priority thread for this.
[based off patches from Ville Syrjälä ,
change below to signoff later]
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_vblank.c | 322 +++
include/drm/drm_vblank.h | 34
2 files changed, 356 insertions(+)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index da7b0b0c1090..06c796b6c381 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -25,7 +25,9 @@
*/
#include
+#include
#include
+#include
#include
#include
@@ -91,6 +93,7 @@
static bool
drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
ktime_t *tvblank, bool in_vblank_irq);
+static int drm_vblank_get(struct drm_device *dev, unsigned int pipe);
static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
@@ -440,6 +443,9 @@ void drm_vblank_cleanup(struct drm_device *dev)
drm_core_check_feature(dev, DRIVER_MODESET));
del_timer_sync(>disable_timer);
+
+ wake_up_all(>vblank_work.work_wait);
+ kthread_stop(vblank->vblank_work.thread);
}
kfree(dev->vblank);
@@ -447,6 +453,108 @@ void drm_vblank_cleanup(struct drm_device *dev)
dev->num_crtcs = 0;
}
+static int vblank_work_thread(void *data)
+{
+ struct drm_vblank_crtc *vblank = data;
+
+ while (!kthread_should_stop()) {
+ struct drm_vblank_work *work, *next;
+ LIST_HEAD(list);
+ u64 count;
+ int ret;
+
+ spin_lock_irq(>dev->event_lock);
+
+ ret = wait_event_interruptible_lock_irq(vblank->queue,
+ kthread_should_stop() ||
+
!list_empty(>vblank_work.work_list),
+
vblank->dev->event_lock);
+
+ WARN_ON(ret && !kthread_should_stop() &&
+ list_empty(>vblank_work.irq_list) &&
+ list_empty(>vblank_work.work_list));
+
+ list_for_each_entry_safe(work, next,
+>vblank_work.work_list,
+list) {
+ list_move_tail(>list, );
+ work->state = DRM_VBL_WORK_RUNNING;
+ }
+
+ spin_unlock_irq(>dev->event_lock);
+
+ if (list_empty())
+ continue;
+
+ count = atomic64_read(>count);
+ list_for_each_entry(work, , list)
+ work->func(work, count);
+
+ spin_lock_irq(>dev->event_lock);
+
+ list_for_each_entry_safe(work, next, , list) {
+ if (work->reschedule) {
+ list_move_tail(>list,
+ >vblank_work.irq_list);
+ drm_vblank_get(vblank->dev, vblank->pipe);
+ work->reschedule = false;
+ work->state = DRM_VBL_WORK_WAITING;
+ } else {
+ list_del_init(>list);
+ work->cancel = false;
+ work->state = DRM_VBL_WORK_IDLE;
+ }
+ }
+
+ spin_unlock_irq(>dev->event_lock);
+
+ wake_up_all(>vblank_work.work_wait);
+ }
+
+ return 0;
+}
+
+static void vblank_work_init(struct drm_vblank_crtc *vblank)
+{
+ struct sched_param param = {
+ .sched_priority = MAX_RT_PRIO - 1,
+ };
+ int ret;
+
+ INIT_LIST_HEAD(>vblank_work.irq_list);
+ INIT_LIST_HEAD(>vblank_work.work_list);
+ init_waitqueue_head(>vblank_work.work_wait);
+
+ vblank->vblank_work.thread =
+ kthread_run(vblank_work_thread, vblank, "card %d crtc %d",
+ vblank->dev->primary->index, vblank->pipe);
+
+ ret = sched_setscheduler(vblank->vblank_work.thread,
+SCHED_FIFO, );
+ WARN_ON(ret);
+}
+
+/**
+ * drm_vblank_work_init - initialize a vblank work item
+ * @work: vblank work item
+ * @crtc: CRTC whose vblank will trigger the work execution
+ * @func: work function to be executed
+ *
+ * Initialize a vblank work item for a specific crtc.
+ */
+void drm_vblank_work_init(struct drm_vblank_work *work, struct drm_crtc *crtc,
+ void (*func)(struct
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote: > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > I think I found a userspace-accessible way to create sync_files and > > dma_fences that would fulfill the requirements: > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > I'm just not sure if that's a good interface to use, since it appears > > to be designed only for debugging. Will have to check for additional > > requirements of signalling an error when the process that created the > > fence is killed. > > Something like that can certainly be lifted for general use if it makes > sense. But then with a software renderer I don't really see how fences > help you at all. With a software renderer you know exactly when the > frame is finished and you can just defer pushing it over to the next > pipeline element until that time. You won't gain any parallelism by > using fences as the CPU is busy doing the rendering and will not run > other stuff concurrently, right? There definitely may be other hardware and/or processes that can process some stuff concurrently with the main application, such as the compositor and or video encoding processes (for video capture). Additionally, from what I understand, sync_file is the standard way to export and import explicit synchronization between processes and between drivers on Linux, so it seems like a good idea to support it from an interoperability standpoint even if it turns out that there aren't any scheduling/timing benefits. Jacob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau/connector: Fix indenting in nouveau_connector_detect()
No functional changes
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 9a9a7f5003d3..0d42a7e5deff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -582,7 +582,7 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
nv_connector->edid = drm_get_edid(connector, i2c);
drm_connector_update_edid_property(connector,
- nv_connector->edid);
+ nv_connector->edid);
if (!nv_connector->edid) {
NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
connector->name);
@@ -635,7 +635,7 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
encoder->helper_private;
if (helper->detect(encoder, connector) ==
- connector_status_connected) {
+ connector_status_connected) {
nouveau_connector_set_encoder(connector, nv_encoder);
conn_status = connector_status_connected;
goto out;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau/connector: Fix DDC error when probing force-disabled connectors
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 0d42a7e5deff..9fb00c4b9764 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -550,6 +550,9 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
+ if (connector->force == DRM_FORCE_OFF)
+ return conn_status;
+
/* Cleanup the previous EDID block. */
if (nv_connector->edid) {
drm_connector_update_edid_property(connector, NULL);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Remove nouveau_bios_connector_entry()
This function doesn't exist Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_bios.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h b/drivers/gpu/drm/nouveau/nouveau_bios.h index 18eb061ccafb..5495f004a297 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.h +++ b/drivers/gpu/drm/nouveau/nouveau_bios.h @@ -163,8 +163,6 @@ u8 *olddcb_conn(struct drm_device *, u8 idx); int nouveau_bios_init(struct drm_device *); void nouveau_bios_takedown(struct drm_device *dev); int nouveau_run_vbios_init(struct drm_device *); -struct dcb_connector_table_entry * -nouveau_bios_connector_entry(struct drm_device *, int index); bool nouveau_bios_fp_mode(struct drm_device *, struct drm_display_mode *); uint8_t *nouveau_bios_embedded_edid(struct drm_device *); int nouveau_bios_parse_lvds_table(struct drm_device *, int pxclk, -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On 3/17/20 5:59 AM, Christoph Hellwig wrote:
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
I've been using v7 of Ralph's tester and it is working well - it has
DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
you able?
This hunk seems trivial enough to me, can we include it now?
I can send a separate patch for it once the tester covers it. I don't
want to add it to the original patch as it is a significant behavior
change compared to the existing code.
Attached is an updated version of my HMM tests based on linux-5.6.0-rc6.
I ran this OK with Jason's 8+1 HMM patches, Christoph's 1-5 misc HMM clean ups,
and Christoph's 1-4 device private page changes applied.
I'm working on getting my nouveau tests running again on a different test
machine and will report on that when ready.
>From d499fb343bfa9764695ecdcd759fb16bc1ca3c93 Mon Sep 17 00:00:00 2001
From: Ralph Campbell
Date: Tue, 17 Mar 2020 11:10:38 -0700
Subject: [PATCH] mm/hmm/test: add self tests for HMM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add some basic stand alone self tests for HMM.
Signed-off-by: Ralph Campbell
Signed-off-by: Jérôme Glisse
---
MAINTAINERS|3 +
include/uapi/linux/test_hmm.h | 59 ++
lib/Kconfig.debug | 12 +
lib/Makefile |1 +
lib/test_hmm.c | 1210 +
tools/testing/selftests/vm/.gitignore |1 +
tools/testing/selftests/vm/Makefile|3 +
tools/testing/selftests/vm/config |2 +
tools/testing/selftests/vm/hmm-tests.c | 1353
tools/testing/selftests/vm/run_vmtests | 16 +
tools/testing/selftests/vm/test_hmm.sh | 97 ++
11 files changed, 2757 insertions(+)
create mode 100644 include/uapi/linux/test_hmm.h
create mode 100644 lib/test_hmm.c
create mode 100644 tools/testing/selftests/vm/hmm-tests.c
create mode 100755 tools/testing/selftests/vm/test_hmm.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1d18cb5d18..98c80a589a52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7608,7 +7608,10 @@ L: linux...@kvack.org
S: Maintained
F: mm/hmm*
F: include/linux/hmm*
+F: include/uapi/linux/test_hmm*
F: Documentation/vm/hmm.rst
+F: lib/test_hmm*
+F: tools/testing/selftests/vm/*hmm*
HOST AP DRIVER
M: Jouni Malinen
diff --git a/include/uapi/linux/test_hmm.h b/include/uapi/linux/test_hmm.h
new file mode 100644
index ..8c5f70c160bf
--- /dev/null
+++ b/include/uapi/linux/test_hmm.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * This is a module to test the HMM (Heterogeneous Memory Management) API
+ * of the kernel. It allows a userspace program to expose its entire address
+ * space through the HMM test module device file.
+ */
+#ifndef _UAPI_LINUX_HMM_DMIRROR_H
+#define _UAPI_LINUX_HMM_DMIRROR_H
+
+#include
+#include
+
+/*
+ * Structure to pass to the HMM test driver to mimic a device accessing
+ * system memory and ZONE_DEVICE private memory through device page tables.
+ *
+ * @addr: (in) user address the device will read/write
+ * @ptr: (in) user address where device data is copied to/from
+ * @npages: (in) number of pages to read/write
+ * @cpages: (out) number of pages copied
+ * @faults: (out) number of device page faults seen
+ */
+struct hmm_dmirror_cmd {
+ __u64 addr;
+ __u64 ptr;
+ __u64 npages;
+ __u64 cpages;
+ __u64 faults;
+};
+
+/* Expose the address space of the calling process through hmm device file */
+#define HMM_DMIRROR_READ _IOWR('H', 0x00, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_WRITE _IOWR('H', 0x01, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_MIGRATE _IOWR('H', 0x02, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_SNAPSHOT _IOWR('H', 0x03, struct hmm_dmirror_cmd)
+
+/*
+ * Values returned in hmm_dmirror_cmd.ptr for HMM_DMIRROR_SNAPSHOT.
+ * HMM_DMIRROR_PROT_ERROR: no valid mirror PTE for this page
+ * HMM_DMIRROR_PROT_NONE: unpopulated PTE or PTE with no access
+ * HMM_DMIRROR_PROT_READ: read-only PTE
+ * HMM_DMIRROR_PROT_WRITE: read/write PTE
+ * HMM_DMIRROR_PROT_ZERO: special read-only zero page
+ * HMM_DMIRROR_PROT_DEV_PRIVATE_LOCAL: Migrated device private page on the
+ * device the ioctl() is made
+ * HMM_DMIRROR_PROT_DEV_PRIVATE_REMOTE: Migrated device private page on some
+ * other device
+ */
+enum {
+ HMM_DMIRROR_PROT_ERROR = 0xFF,
+ HMM_DMIRROR_PROT_NONE = 0x00,
+ HMM_DMIRROR_PROT_READ = 0x01,
+ HMM_DMIRROR_PROT_WRITE = 0x02,
+ HMM_DMIRROR_PROT_ZERO = 0x10,
+ HMM_DMIRROR_PROT_DEV_PRIVATE_LOCAL = 0x20,
+ HMM_DMIRROR_PROT_DEV_PRIVATE_REMOTE = 0x30,
+};
+
+#endif /* _UAPI_LINUX_HMM_DMIRROR_H */
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 69def4a9df00..4d22ce7879a7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2162,6 +2162,18 @@ config TEST_MEMINIT
If unsure, say N.
+config TEST_HMM
+ tristate "Test
Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault
On 3/17/20 4:56 AM, Jason Gunthorpe wrote: On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote: The reason for it being backwards is that "normally" a device doesn't want the device private page to be faulted back to system memory, it wants to get the device private struct page so it can update its page table to point to the memory already in the device. The "backwards" is you set the flag on input and never get it on output, clear the flag in input and maybe get it on output. Compare with valid or write which don't work that way. Also, a device like Nvidia's GPUs may have an alternate path for copying one GPU's memory to another (nvlink) without going through system memory so getting a device private struct page/PFN from hmm_range_fault() that isn't "owned" by the faulting GPU is useful. I agree that the current code isn't well tested or thought out for multiple devices (rdma, NVMe drives, GPUs, etc.) but it also ties in with peer-to-peer access via PCIe. I think the series here is a big improvement. The GPU driver can set owners that match the hidden cluster interconnect. Jason I agree this is an improvement. I was just thinking about possible future use cases. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On 3/17/20 12:34 AM, Christoph Hellwig wrote: On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote: On 3/16/20 12:32 PM, Christoph Hellwig wrote: Remove the code to fault device private pages back into system memory that has never been used by any driver. Also replace the usage of the HMM_PFN_DEVICE_PRIVATE flag in the pfns array with a simple is_device_private_page check in nouveau. Signed-off-by: Christoph Hellwig Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a driver can look at the struct page but what if a driver needs to fault in a page from another device's private memory? Should it call handle_mm_fault()? Obviously no driver cared for that so far. Once we have test cases for that and thus testable code we can add code to fault it in from hmm_vma_handle_pte. I'm OK with the series. I think I would have been less confused if I looked at patch 4 then 3. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: drm_vm: Use fallthrough;
On Tue, 2020-03-17 at 17:48 +0100, Daniel Vetter wrote: > On Thu, Mar 12, 2020 at 12:17:12PM -0700, Joe Perches wrote: > > Convert /* fallthrough */ style comments to fallthrough; > > > > Convert the various uses of fallthrough comments to fallthrough; > > > > Done via script > > Link: > > https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git@perches.com/ > > > > And by hand: > > > > This file has a fallthrough comment outside of an #ifdef block > > that causes gcc to emit a warning if converted in-place. > > > > So move the new fallthrough; inside the containing #ifdef/#endif too. > > > > Signed-off-by: Joe Perches > > Acked-by: Daniel Vetter > > I'm assuming this all lands through a special pull? Or should I apply > this? Hi Daniel. I think you should apply this. The idea here is to allow a scripted conversion at some point and this patch is necessary to avoid new compiler warnings after running the script. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
Hi,
On Mon, Mar 16, 2020 at 4:06 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered, PM core adds a refcount on all the
> devices and calls device suspend, since usage count is
> already incremented, runtime suspend was not getting called
> and it kept the clocks on which resulted in target not
> entering into XO shutdown.
>
> Add changes to manage runtime devices during pm sleep.
>
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 41
> +
> drivers/gpu/drm/msm/dsi/dsi.c | 7 ++
> drivers/gpu/drm/msm/msm_drv.c | 14 +++
> drivers/gpu/drm/msm/msm_kms.h | 2 ++
> 4 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index cb08faf..6e103d5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -26,6 +26,7 @@
> #include "dpu_encoder.h"
> #include "dpu_plane.h"
> #include "dpu_crtc.h"
> +#include "dsi.h"
>
> #define CREATE_TRACE_POINTS
> #include "dpu_trace.h"
> @@ -250,6 +251,37 @@ static void dpu_kms_disable_commit(struct msm_kms *kms)
> pm_runtime_put_sync(_kms->pdev->dev);
> }
>
> +static void _dpu_kms_disable_dpu(struct msm_kms *kms)
> +{
> + struct drm_device *dev;
> + struct msm_drm_private *priv;
> + struct dpu_kms *dpu_kms;
> + int i = 0;
> + struct msm_dsi *dsi;
> +
> + dpu_kms = to_dpu_kms(kms);
> + dev = dpu_kms->dev;
> + if (!dev) {
> + DPU_ERROR("invalid device\n");
> + return;
> + }
> +
> + priv = dev->dev_private;
> + if (!priv) {
> + DPU_ERROR("invalid private data\n");
> + return;
> + }
> +
> + dpu_kms_disable_commit(kms);
> +
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (!priv->dsi[i])
> + continue;
> + dsi = priv->dsi[i];
> + pm_runtime_put_sync(>pdev->dev);
> + }
> +}
> +
> static ktime_t dpu_kms_vsync_time(struct msm_kms *kms, struct drm_crtc *crtc)
> {
> struct drm_encoder *encoder;
> @@ -683,6 +715,7 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init= dpu_kms_debugfs_init,
> #endif
> + .disable_dpu = _dpu_kms_disable_dpu,
> };
>
> static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
> @@ -1053,7 +1086,15 @@ static int __maybe_unused dpu_runtime_resume(struct
> device *dev)
> return rc;
> }
>
> +
> +static int __maybe_unused dpu_pm_suspend_late(struct device *dev)
> +{
> + pm_runtime_get_noresume(dev);
> + return 0;
> +}
> +
> static const struct dev_pm_ops dpu_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(dpu_pm_suspend_late, NULL)
> SET_RUNTIME_PM_OPS(dpu_runtime_suspend, dpu_runtime_resume, NULL)
> };
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index 55ea4bc2..3d3740e 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -154,12 +154,19 @@ static int dsi_dev_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int __maybe_unused dsi_pm_suspend_late(struct device *dev)
> +{
> + pm_runtime_get_noresume(dev);
> + return 0;
> +}
> +
> static const struct of_device_id dt_match[] = {
> { .compatible = "qcom,mdss-dsi-ctrl" },
> {}
> };
>
> static const struct dev_pm_ops dsi_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(dsi_pm_suspend_late, NULL)
> SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume,
> NULL)
> };
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index e4b750b..12ec1c6 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1038,6 +1038,7 @@ static int msm_pm_suspend(struct device *dev)
> {
> struct drm_device *ddev = dev_get_drvdata(dev);
> struct msm_drm_private *priv = ddev->dev_private;
> + struct msm_kms *kms = priv->kms;
>
> if (WARN_ON(priv->pm_state))
> drm_atomic_state_put(priv->pm_state);
> @@ -1049,6 +1050,11 @@ static int msm_pm_suspend(struct device *dev)
> return ret;
> }
>
> + if (kms->funcs->disable_dpu)
> + kms->funcs->disable_dpu(kms);
> +
> + pm_runtime_put_sync(dev);
> +
> return 0;
> }
>
> @@ -1067,6 +1073,13 @@ static int msm_pm_resume(struct device *dev)
>
> return ret;
> }
> +
> +static int msm_pm_suspend_late(struct device *dev)
> +{
> + pm_runtime_get_noresume(dev);
> + return 0;
> +}
> +
> #endif
>
> #ifdef CONFIG_PM
[PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dma-buf. While work is ongoing to change
many of the userspace APIs and protocols to an explicit synchronization
model, switching over piecemeal is difficult due to the number of
potential components involved. On the kernel side, many drivers use
dma-buf including GPU (3D/compute), display, v4l, and others. In
userspace, we have X11, several Wayland compositors, 3D drivers, compute
drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually
manage the fences attached to a dma-buf. Alternatively, one can think
of this as making dma-buf's implicit synchronization simply a carrier
for an explicit fence. This is accomplished by adding two IOCTLs to
dma-buf for importing and exporting a sync file to/from the dma-buf.
This way a userspace component which is uses explicit synchronization,
such as a Vulkan driver, can manually set the write fence on a buffer
before handing it off to an implicitly synchronized component such as a
Wayland compositor or video encoder. In this way, each of the different
components can be upgraded to an explicit synchronization model one at a
time as long as the userspace pieces connecting them are aware of it and
import/export fences at the right times.
There is a potential race condition with this API if userspace is not
careful. A typical use case for implicit synchronization is to wait for
the dma-buf to be ready, use it, and then signal it for some other
component. Because a sync_file cannot be created until it is guaranteed
to complete in finite time, userspace can only signal the dma-buf after
it has already submitted the work which uses it to the kernel and has
received a sync_file back. There is no way to atomically submit a
wait-use-signal operation. This is not, however, really a problem with
this API so much as it is a problem with explicit synchronization
itself. The way this is typically handled is to have very explicit
ownership transfer points in the API or protocol which ensure that only
one component is using it at any given time. Both X11 (via the PRESENT
extension) and Wayland provide such ownership transfer points via
explicit present and idle messages.
The decision was intentionally made in this patch to make the import and
export operations IOCTLs on the dma-buf itself rather than as a DRM
IOCTL. This makes it the import/export operation universal across all
components which use dma-buf including GPU, display, v4l, and others.
It also means that a userspace component can do the import/export
without access to the DRM fd which may be tricky to get in cases where
the client communicates with DRM via a userspace API such as OpenGL or
Vulkan. At a future date we may choose to add direct import/export APIs
to components such as drm_syncobj to avoid allocating a file descriptor
and going through two ioctls. However, that seems to be something of a
micro-optimization as import/export operations are likely to happen at a
rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
Signed-off-by: Jason Ekstrand
---
drivers/dma-buf/dma-buf.c| 84
include/uapi/linux/dma-buf.h | 11 -
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d4097856c86b..d34d27aa3077 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -348,6 +349,83 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const
char __user *buf)
return ret;
}
+static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
+const void __user *user_data)
+{
+ struct dma_buf_sync_file arg;
+ struct dma_fence *fence, *singleton = NULL;
+ int ret = 0;
+
+ if (copy_from_user(, user_data, sizeof(arg)))
+ return -EFAULT;
+
+ if (arg.flags != 0)
+ return -EINVAL;
+
+ fence = sync_file_get_fence(arg.fd);
+ if (!fence)
+ return -EINVAL;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+
+ ret =
Re: [PATCH] drm/lima: add trace point for tasks
On Mon, Mar 16, 2020 at 6:41 PM Qiang Yu wrote: > Not concrete reason, as the comment, trace point when > dma_fence_signal act as the task completion event, so not add duplicate > one. I see. Patch is: Reviewed-by: Vasily Khoruzhick Regards, Vasily ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Better regex for dma_buf|fence|resv
We're getting some random other stuff that we're not really interested in, so match only word boundaries. Also avoid the capture group while at it. Suggested by Joe Perches. Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Cc: Joe Perches Cc: Sumit Semwal Cc: Sam Ravnborg Signed-off-by: Daniel Vetter --- v2: No single quotes in MAINTAINERS (Joe) v3: Fix typo in commit message (Sam) --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3005be638c2c..ed6088a01bfe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5025,7 +5025,7 @@ F:include/linux/dma-buf* F: include/linux/reservation.h F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst -K: dma_(buf|fence|resv) +K: \bdma_(?:buf|fence|resv)\b T: git git://anongit.freedesktop.org/drm/drm-misc DMA-BUF HEAPS FRAMEWORK -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/8] *** Per context fencing ***
On Mon, Mar 16, 2020 at 3:44 PM Gerd Hoffmann wrote: > > Hi, > > > >> At virtio level it is pretty simple: The host completes the SUBMIT_3D > > >> virtio command when it finished rendering, period. > > >> > > >> > > >> On the guest side we don't need the fence_id. The completion callback > > >> gets passed the virtio_gpu_vbuffer, so it can figure which command did > > >> actually complete without looking at virtio_gpu_ctrl_hdr->fence_id. > > >> > > >> On the host side we depend on the fence_id right now, but only because > > >> that is the way the virgl_renderer_callbacks->write_fence interface is > > >> designed. We have to change that anyway for per-context (or whatever) > > >> fences, so it should not be a problem to drop the fence_id dependency > > >> too and just pass around an opaque pointer instead. > > > > I am still catching up, but IIUC, indeed I don't think the host needs > > to depend on fence_id. We should be able to repurpose fence_id. > > I'd rather ignore it altogether for FENCE_V2 (or whatever we call the > feature flag). That's fine when one assumes each virtqueue has one host GPU timeline. But when there are multiple (e.g., multiplexing multiple contexts over one virtqueue, or multiple VkQueues), fence_id can be repurposed as the host timeline id. > > > On the other hand, the VIRTIO_GPU_FLAG_FENCE flag is interesting, and > > it indicates that the vbuf is on the host GPU timeline instead of the > > host CPU timeline. > > Yep, we have to keep that (unless we do command completion on GPU > timeline unconditionally with FENCE_V2). I think it will be useful when EXECBUFFER is used for metadata query and write the metadata directly to a guest BO's sg list. We want the query to be on the CPU timeline. > cheers, > Gerd > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/3] dt-bindings: display: grammar fixes in panel/
Hi Sam, Thank you for the patch. On Sat, Mar 14, 2020 at 04:30:47PM +0100, Sam Ravnborg wrote: > Fix a few grammar/editorial issues spotted by Laurent Pinchart. > > Signed-off-by: Sam Ravnborg > Cc: Laurent Pinchart > Cc: Rob Herring > --- > .../bindings/display/panel/display-timings.yaml | 8 > .../devicetree/bindings/display/panel/panel-common.yaml | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/display-timings.yaml > b/Documentation/devicetree/bindings/display/panel/display-timings.yaml > index c8c0c9cb0492..56903ded005e 100644 > --- a/Documentation/devicetree/bindings/display/panel/display-timings.yaml > +++ b/Documentation/devicetree/bindings/display/panel/display-timings.yaml > @@ -4,7 +4,7 @@ > $id: http://devicetree.org/schemas/display/panel/display-timings.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: display timing bindings > +title: display timings bindings > > maintainers: >- Thierry Reding > @@ -14,7 +14,7 @@ maintainers: > description: | >A display panel may be able to handle several display timings, >with different resolutions. > - The display-timings node makes it possible to specify the timing > + The display-timings node makes it possible to specify the timings >and to specify the timing that is native for the display. > > properties: > @@ -25,8 +25,8 @@ properties: > $ref: /schemas/types.yaml#/definitions/phandle > description: | >The default display timing is the one specified as native-mode. > - If no native-mode is specified then the first node is assumed the > - native mode. > + If no native-mode is specified then the first node is assumed > + to be the native mode. > > patternProperties: >"^timing": > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-common.yaml > b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > index ed051ba12084..dee4faffd204 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > @@ -63,9 +63,9 @@ properties: > >display-timings: > description: > - Some display panels supports several resolutions with different timing. > + Some display panels supports several resolutions with different > timings. s/supports/support/ >The display-timings bindings supports specifying several timings and > - optional specify which is the native mode. > + optionally specify which is the native mode. s/specify/specifying/ ? Reviewed-by: Laurent Pinchart > allOf: >- $ref: display-timings.yaml# > -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/3] drm/panel-simple: drop use of data-mapping property
Hi Sam, Thank you for the patch. On Sat, Mar 14, 2020 at 04:30:46PM +0100, Sam Ravnborg wrote: > The "data-mapping" property may not be the best way to describe the > interface between panels and display interfaces. > Drop use of in the panel-simple driver, so we have time to find > the right way to describe this interface. For the same reason as for patch 1/3, Reviewed-by: Laurent Pinchart > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Rob Herring > Cc: Maxime Ripard > Cc: Laurent Pinchart > --- > drivers/gpu/drm/panel/panel-simple.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index 0ce81b1f36af..3ad828eaefe1 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -361,7 +361,6 @@ static int panel_dpi_probe(struct device *dev, > struct panel_desc *desc; > unsigned int bus_flags; > struct videomode vm; > - const char *mapping; > int ret; > > np = dev->of_node; > @@ -386,16 +385,6 @@ static int panel_dpi_probe(struct device *dev, > of_property_read_u32(np, "width-mm", >size.width); > of_property_read_u32(np, "height-mm", >size.height); > > - of_property_read_string(np, "data-mapping", ); > - if (!strcmp(mapping, "rgb24")) > - desc->bus_format = MEDIA_BUS_FMT_RGB888_1X24; > - else if (!strcmp(mapping, "rgb565")) > - desc->bus_format = MEDIA_BUS_FMT_RGB565_1X16; > - else if (!strcmp(mapping, "bgr666")) > - desc->bus_format = MEDIA_BUS_FMT_RGB666_1X18; > - else if (!strcmp(mapping, "lvds666")) > - desc->bus_format = MEDIA_BUS_FMT_RGB666_1X24_CPADHI; > - > /* Extract bus_flags from display_timing */ > bus_flags = 0; > vm.flags = timing->flags; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/3] dt-bindings: display: drop data-mapping from panel-dpi
Hi Sam,
Thank you for the patch.
On Sat, Mar 14, 2020 at 04:30:45PM +0100, Sam Ravnborg wrote:
> data-mapping may not be the best way to describe the
> data format used between panels and display interface.
>
> Drop it from the panel-dpi binding so we do not start to rely on it.
> We can then work out how to best describe this mapping and when
> we know it, we can add it to this binding.
I certainly welcome that, as we need to define how to express this
information in a more detailed way, taking into account all use cases.
Reviewed-by: Laurent Pinchart
I think this qualifies as a v5.7 fix.
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Rob Herring
> ---
> .../devicetree/bindings/display/panel/panel-dpi.yaml | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> index f63870384c00..0cd74c8dab42 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> @@ -21,15 +21,6 @@ properties:
>- {}
>- const: panel-dpi
>
> - data-mapping:
> -enum:
> - - rgb24
> - - rgb565
> - - bgr666
> -description: |
> - Describes the media format, how the display panel is connected
> - to the display interface.
> -
>backlight: true
>enable-gpios: true
>height-mm: true
> @@ -52,7 +43,6 @@ examples:
> compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
> label = "osddisplay";
> power-supply = <_supply>;
> -data-mapping = "rgb565";
> backlight = <>;
>
> port {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 87/89] drm/vc4: hdmi: Support the BCM2711 HDMI controllers
On 2/24/20 4:07 AM, Maxime Ripard wrote:
static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
{
struct drm_display_mode *mode = >crtc->state->adjusted_mode;
@@ -1314,6 +1438,92 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return 0;
}
This function fails on my Raspberry Pi 4 running patched 5.6-rc6. The
errors printed to syslog are as follows:
[ 15.167559] vc4-drm gpu: [drm] *ERROR* fbdev: Failed to setup generic
emulation (ret=-22)
[ 46.116273] WARNING: CPU: 2 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi_phy.c:414 vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 47.127798] Timeout waiting for VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE
[ 47.127865] WARNING: CPU: 1 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi.c:652 vc4_hdmi_encoder_enable+0x1518/0x1e10
[vc4]
[ 47.128353] WARNING: CPU: 1 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi.c:671 vc4_hdmi_encoder_enable+0x18c8/0x1e10
[vc4]
-
Backtrace:
[ 46.116373] pc : vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 46.116386] lr : vc4_hdmi_encoder_enable+0x1cc/0x1e10 [vc4]
[ 46.116440] vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 46.116451] vc4_hdmi_encoder_enable+0x1cc/0x1e10 [vc4]
[ 46.116497] vc4_atomic_complete_commit+0x3f0/0x530 [vc4]
[ 46.116508] vc4_atomic_commit+0x1d8/0x1f8 [vc4]
The specific offending conditional (before the warning on line 652)
under vc4_hdmi_encoder_enable() in drm/vc4/vc4_hdmi.c:
645 if (vc4_encoder->hdmi_monitor) {
646 HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
647 HDMI_READ(HDMI_SCHEDULER_CONTROL) |
648 VC4_HDMI_SCHEDULER_CONTROL_MODE_HDMI);
649
650 ret = wait_for(HDMI_READ(HDMI_SCHEDULER_CONTROL) &
651 VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE, 1000);
652 WARN_ONCE(ret, "Timeout waiting for "
653 "VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE\n");
Which causes vc4_hdmi_encoder_enable() to fail.
The failure of vc5_hdmi_phy_init() earlier left the phy inactive,
causing the encoder enabling function above to fail.
The offending code around line 414 in vc4_hdmi_phy.c, under
vc5_hdmi_phy_init() reads
411 HDMI_WRITE(HDMI_TX_PHY_TMDS_CLK_WORD_SEL, word_sel);
412
413 HDMI_WRITE(HDMI_TX_PHY_CTL_3,
414VC4_SET_FIELD(phy_get_cp_current(vco_freq),
415 VC4_HDMI_TX_PHY_CTL_3_ICP) |
416VC4_SET_FIELD(1, VC4_HDMI_TX_PHY_CTL_3_CP) |
417VC4_SET_FIELD(1, VC4_HDMI_TX_PHY_CTL_3_CP1) |
418VC4_SET_FIELD(3, VC4_HDMI_TX_PHY_CTL_3_CZ) |
419VC4_SET_FIELD(4, VC4_HDMI_TX_PHY_CTL_3_RP) |
420VC4_SET_FIELD(6, VC4_HDMI_TX_PHY_CTL_3_RZ));
As the hdmi-related timeout occurs 30 seconds after the drm failure, I'm
bound to believe that the timeout occurs due to the drm setup failure
leaving nothing for the phy functions to act on.
Earlier in the syslog an error potentially related to the
VC4_SET_FIELD(phy_get_cp_current(vco_freq) failure:
[3.729745] raspberrypi-clk raspberrypi-clk: Missing firmware node
[3.743915] raspberrypi-clk: probe of raspberrypi-clk failed with
error -2
I thought the patch series added the firmware node? Perhaps the bcm2835
clock stub in the bcm2835 common dts is not being imported in the
bcm2711 devicetree?
The result is a connected hdmi monitor has signal from the simple
framebuffer until the failed modeswitch, upon which it loses signal.
I'm looking around for these possibilities in the kernel tree, though I
thought the code worked as it was?
I did have to disable CONFIG_DRM_VC4_HDMI_CEC in Kconfig to get the
patches to compile as another user in linux-arm-kernel discovered the
CEC code relied on removed functions (Jian-Hong Pan).
I still hope these patches can be cleaned up/fixed to make the 5.7 merge
window.
Daniel Rodriguez
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote: > > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay: > > > One related issue with explicit sync using sync_file is that combined > > > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > > > rendering in userspace (like llvmpipe but for Vulkan and with extra > > > instructions for GPU tasks) but need to synchronize with other > > > drivers/processes is that there should be some way to create an > > > explicit fence/semaphore from userspace and later signal it. This > > > seems to conflict with the requirement for a sync_file to complete in > > > finite time, since the user process could be stopped or killed. > > > > > > Any ideas? > > > > Finite just means "not infinite". If you stop the process that's doing > > part of the pipeline processing you block the pipeline, you get to keep > > the pieces in that case. > > Seems reasonable. > > > That's one of the issues with implicit sync > > that explicit may solve: a single client taking way too much time to > > render something can block the whole pipeline up until the display > > flip. With explicit sync the compositor can just decide to use the last > > client buffer if the latest buffer isn't ready by some deadline. > > > > With regard to the process getting killed: whatever you sync primitive > > is, you need to make sure to signal the fence (possibly with an error > > condition set) when you are not going to make progress anymore. So > > whatever your means to creating the sync_fd from your software renderer > > is, it needs to signal any outstanding fences on the sync_fd when the > > fd is closed. > > I think I found a userspace-accessible way to create sync_files and > dma_fences that would fulfill the requirements: > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > I'm just not sure if that's a good interface to use, since it appears > to be designed only for debugging. Will have to check for additional > requirements of signalling an error when the process that created the > fence is killed. Something like that can certainly be lifted for general use if it makes sense. But then with a software renderer I don't really see how fences help you at all. With a software renderer you know exactly when the frame is finished and you can just defer pushing it over to the next pipeline element until that time. You won't gain any parallelism by using fences as the CPU is busy doing the rendering and will not run other stuff concurrently, right? Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote: > > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay: > > One related issue with explicit sync using sync_file is that combined > > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > > rendering in userspace (like llvmpipe but for Vulkan and with extra > > instructions for GPU tasks) but need to synchronize with other > > drivers/processes is that there should be some way to create an > > explicit fence/semaphore from userspace and later signal it. This > > seems to conflict with the requirement for a sync_file to complete in > > finite time, since the user process could be stopped or killed. > > > > Any ideas? > > Finite just means "not infinite". If you stop the process that's doing > part of the pipeline processing you block the pipeline, you get to keep > the pieces in that case. Seems reasonable. > That's one of the issues with implicit sync > that explicit may solve: a single client taking way too much time to > render something can block the whole pipeline up until the display > flip. With explicit sync the compositor can just decide to use the last > client buffer if the latest buffer isn't ready by some deadline. > > With regard to the process getting killed: whatever you sync primitive > is, you need to make sure to signal the fence (possibly with an error > condition set) when you are not going to make progress anymore. So > whatever your means to creating the sync_fd from your software renderer > is, it needs to signal any outstanding fences on the sync_fd when the > fd is closed. I think I found a userspace-accessible way to create sync_files and dma_fences that would fulfill the requirements: https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c I'm just not sure if that's a good interface to use, since it appears to be designed only for debugging. Will have to check for additional requirements of signalling an error when the process that created the fence is killed. Jacob > > Regards, > Lucas > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Am Dienstag, den 17.03.2020, 11:33 -0400 schrieb Nicolas Dufresne: > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > > Hi Jason, > > > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote: > > > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote: > > > > > (I know I'm going to be spammed by so many mailing list ...) > > > > > > > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > > > > > wrote: > > > > > > > All, > > > > > > > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most > > > > > > > people > > > > > > > who reply will get at least one mailing list rejection. However, > > > > > > > this > > > > > > > is an issue that affects a LOT of components and that's why it's > > > > > > > thorny to begin with. Please pardon the length of this e-mail as > > > > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. At > > > > > > > least, that seems to be the consensus among all the graphics > > > > > > > people > > > > > > > I've talked to. I had a chat with one of the lead Android > > > > > > > graphics > > > > > > > engineers recently who told me that doing explicit sync from the > > > > > > > start > > > > > > > was one of the best engineering decisions Android ever made. It's > > > > > > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > > > > > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > > > > > > > For those that aren't familiar with this space, GPUs, media > > > > > > > encoders, > > > > > > > etc. are massively parallel and synchronization of some form is > > > > > > > required to ensure that everything happens in the right order and > > > > > > > avoid data races. Implicit synchronization is when bits of work > > > > > > > (3D, > > > > > > > compute, video encode, etc.) are implicitly based on the absolute > > > > > > > CPU-time order in which API calls occur. Explicit > > > > > > > synchronization is > > > > > > > when the client (whatever that means in any given context) > > > > > > > provides > > > > > > > the dependency graph explicitly via some sort of synchronization > > > > > > > primitives. If you're still confused, consider the following > > > > > > > examples: > > > > > > > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say you > > > > > > > have > > > > > > > two OpenGL contexts sharing an image where one writes to it and > > > > > > > the > > > > > > > other textures from it. The way the OpenGL spec works, the > > > > > > > client has > > > > > > > to make the API calls to render to the image before (in CPU time) > > > > > > > it > > > > > > > makes the API calls which texture from the image. As long as it > > > > > > > does > > > > > > > this (and maybe inserts a glFlush?), the driver will ensure that > > > > > > > the > > > > > > > rendering completes before the texturing happens and you get > > > > > > > correct > > > > > > > contents. > > > > > > > > > > > > > > Implicit synchronization can also happen across processes. > > > > > > > Wayland, > > > > > > > for instance, is currently built on implicit sync where the client > > > > > > > does their rendering and then does a hand-off (via > > > > > > > wl_surface::commit) > > > > > > > to tell the compositor it's done at which point the compositor > > > > > > > can now > > > > > > > texture from the surface. The hand-off ensures that the client's > > > > > > > OpenGL API calls happen before the server's OpenGL API calls. > > > > > > > > > > > > > > A good example of explicit synchronization is the Vulkan API. > > > > > > > There, > > > > > > > a client (or multiple clients) can simultaneously build command > > > > > > > buffers in different threads where one of those command buffers > > > > > > > renders to an image and the other textures from it and then submit > > > > > > > both of them at the same time with instructions to the driver for > > > > > > > which order to execute them in. The execution order is described > > > > > > > via > > > > > > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > > > > > > extension, you can even submit the work which does the texturing > > > > > > > BEFORE the work which does the rendering and the driver will sort > > > > > > > it > > > > > > > out. > > > > > > > > > > > > > > The #1 problem with implicit synchronization (which explicit > > > > > > > solves) > > > > > > > is that it leads to a lot of over-synchronization both in client > > > > > > > space > > > > > > > and in driver/device space. The client has to synchronize a lot > > > > > > > more > > > > > > > because it has to ensure that the
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay: > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but need to synchronize with other > drivers/processes is that there should be some way to create an > explicit fence/semaphore from userspace and later signal it. This > seems to conflict with the requirement for a sync_file to complete in > finite time, since the user process could be stopped or killed. > > Any ideas? Finite just means "not infinite". If you stop the process that's doing part of the pipeline processing you block the pipeline, you get to keep the pieces in that case. That's one of the issues with implicit sync that explicit may solve: a single client taking way too much time to render something can block the whole pipeline up until the display flip. With explicit sync the compositor can just decide to use the last client buffer if the latest buffer isn't ready by some deadline. With regard to the process getting killed: whatever you sync primitive is, you need to make sure to signal the fence (possibly with an error condition set) when you are not going to make progress anymore. So whatever your means to creating the sync_fd from your software renderer is, it needs to signal any outstanding fences on the sync_fd when the fd is closed. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Fix an error handling path 'msm_drm_init()'
Hi,
On Sun, Mar 15, 2020 at 12:42 PM Christophe JAILLET
wrote:
>
> If this memory allocation fails, we have to go through the error handling
> path to perform some clean-up, as already done in other other paths of
> this function.
>
> Fixes: db735fc4036b ("drm/msm: Set dma maximum segment size for mdss")
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/msm/msm_drv.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
This has already been posted as:
https://lore.kernel.org/r/20200309101410.ga18...@duo.ucw.cz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote: > > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but need to synchronize with other > drivers/processes is that there should be some way to create an > explicit fence/semaphore from userspace and later signal it. This > seems to conflict with the requirement for a sync_file to complete in > finite time, since the user process could be stopped or killed. Yeah... That's going to be a problem. The only way I could see that working is if you created a sync_file that had a timeout associated with it. However, then you run into the issue where you may have corruption if stuff doesn't complete on time. Then again, you're not really dealing with an external unit and so the latency cost of going across the window system protocol probably isn't massively different from the latency cost of triggering the sync_file. Maybe the answer there is to just do everything in-order and not worry about synchronization? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote: > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer > wrote: > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: > >>> The synchronization works because the Mesa driver waits for idle > (drains > >>> the GFX pipeline) at the end of command buffers and there is only 1 > >>> graphics queue, so everything is ordered. > >>> > >>> The GFX pipeline runs asynchronously to the command buffer, meaning the > >>> command buffer only starts draws and doesn't wait for completion. If > the > >>> Mesa driver didn't wait at the end of the command buffer, the command > >>> buffer would finish and a different process could start execution of > its > >>> own command buffer while shaders of the previous process are still > >> running. > >>> > >>> If the Mesa driver submits a command buffer internally (because it's > >> full), > >>> it doesn't wait, so the GFX pipeline doesn't notice that a command > buffer > >>> ended and a new one started. > >>> > >>> The waiting at the end of command buffers happens only when the flush > is > >>> external (Swap buffers, glFlush). > >>> > >>> It's a performance problem, because the GFX queue is blocked until the > >> GFX > >>> pipeline is drained at the end of every frame at least. > >>> > >>> So explicit fences for SwapBuffers would help. > >> > >> Not sure what difference it would make, since the same thing needs to be > >> done for explicit fences as well, doesn't it? > > > > No. Explicit fences don't require userspace to wait for idle in the > command > > buffer. Fences are signalled when the last draw is complete and caches > are > > flushed. Before that happens, any command buffer that is not dependent on > > the fence can start execution. There is never a need for the GPU to be > idle > > if there is enough independent work to do. > > I don't think explicit fences in the context of this discussion imply > using that different fence signalling mechanism though. My understanding > is that the API proposed by Jason allows implicit fences to be used as > explicit ones and vice versa, so presumably they have to use the same > signalling mechanism. > > > Anyway, maybe the different fence signalling mechanism you describe > could be used by the amdgpu kernel driver in general, then Mesa could > drop the waits for idle and get the benefits with implicit sync as well? > Yes. If there is any waiting, or should be done in the GPU scheduler, not in the command buffer, so that independent command buffers can use the GFX queue. Marek > > -- > Earthling Michel Dänzer | https://redhat.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: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
One related issue with explicit sync using sync_file is that combined CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the rendering in userspace (like llvmpipe but for Vulkan and with extra instructions for GPU tasks) but need to synchronize with other drivers/processes is that there should be some way to create an explicit fence/semaphore from userspace and later signal it. This seems to conflict with the requirement for a sync_file to complete in finite time, since the user process could be stopped or killed. Any ideas? Jacob Lifshay ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Better regex for dma_buf|fence|resv
We're getting some random other stuff that we're not relly interested
in, so match only word boundaries. Also avoid the capture group while
at it.
Suggested by Joe Perches.
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Joe Perches
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
---
v2: No single quotes in MAINTAINERS (Joe)
---
MAINTAINERS | 2 +-
drivers/gpu/drm/drm_managed.c | 27 +--
include/drm/drm_managed.h | 2 +-
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3005be638c2c..ed6088a01bfe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5025,7 +5025,7 @@ F:include/linux/dma-buf*
F: include/linux/reservation.h
F: include/linux/*fence.h
F: Documentation/driver-api/dma-buf.rst
-K: dma_(buf|fence|resv)
+K: \bdma_(?:buf|fence|resv)\b
T: git git://anongit.freedesktop.org/drm/drm-misc
DMA-BUF HEAPS FRAMEWORK
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index 5148ef786c3b..c256c9679eb5 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -52,6 +52,12 @@ struct drmres {
u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
};
+static void free_dr(struct drmres *dr)
+{
+ kfree_const(dr->node.name);
+ kfree(dr);
+}
+
void drm_managed_release(struct drm_device *dev)
{
struct drmres *dr, *tmp;
@@ -65,13 +71,13 @@ void drm_managed_release(struct drm_device *dev)
dr->node.release(dev, dr->node.size ? *(void
**)>data : NULL);
list_del(>node.entry);
- kfree(dr);
+ free_dr(dr);
}
drm_dbg_drmres(dev, "drmres release end\n");
}
/*
- * Always inline so that kmallc_track_caller tracks the actual interesting
+ * Always inline so that kmalloc_track_caller tracks the actual interesting
* caller outside of drm_managed.c.
*/
static __always_inline struct drmres * alloc_dr(drmres_release_t release,
@@ -120,7 +126,7 @@ static void add_dr(struct drm_device *dev, struct drmres
*dr)
/**
* drmm_add_final_kfree - add release action for the final kfree()
* @dev: DRM device
- * @parent: pointer to the kmalloc allocation containing @dev
+ * @container: pointer to the kmalloc allocation containing @dev
*
* Since the allocation containing the struct _device must be allocated
* before it can be initialized with drm_dev_init() there's no way to allocate
@@ -129,12 +135,13 @@ static void add_dr(struct drm_device *dev, struct drmres
*dr)
* will be released in the final drm_dev_put() for @dev, after all other
release
* actions installed through drmm_add_action() have been processed.
*/
-void drmm_add_final_kfree(struct drm_device *dev, void *parent)
+void drmm_add_final_kfree(struct drm_device *dev, void *container)
{
WARN_ON(dev->managed.final_kfree);
- WARN_ON(dev < (struct drm_device *) parent);
- WARN_ON(dev + 1 >= (struct drm_device *) (parent + ksize(parent)));
- dev->managed.final_kfree = parent;
+ WARN_ON(dev < (struct drm_device *) container);
+ WARN_ON(dev + 1 >=
+ (struct drm_device *) (container + ksize(container)));
+ dev->managed.final_kfree = container;
}
EXPORT_SYMBOL(drmm_add_final_kfree);
@@ -154,7 +161,7 @@ int __drmm_add_action(struct drm_device *dev,
return -ENOMEM;
}
- dr->node.name = name;
+ dr->node.name = kstrdup_const(name, GFP_KERNEL);
if (data) {
void_ptr = (void **)>data;
*void_ptr = data;
@@ -212,7 +219,7 @@ void drmm_remove_action(struct drm_device *dev,
if (WARN_ON(!dr))
return;
- kfree(dr);
+ free_dr(dr);
}
EXPORT_SYMBOL(drmm_remove_action);
@@ -300,6 +307,6 @@ void drmm_kfree(struct drm_device *dev, void *data)
if (WARN_ON(!dr_match))
return;
- kfree(dr_match);
+ free_dr(dr_match);
}
EXPORT_SYMBOL(drmm_kfree);
diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
index af152cfb173c..e4021484c78d 100644
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -51,7 +51,7 @@ void drmm_remove_action(struct drm_device *dev,
drmres_release_t action,
void *data);
-void drmm_add_final_kfree(struct drm_device *dev, void *parent);
+void drmm_add_final_kfree(struct drm_device *dev, void *container);
void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment
On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote: > Ccing dri-devel and linux-kernel. git apply-mbox chokes on this, can you pls resubmit? Thanks, Daniel > > -- Forwarded message - > From: Igor Matheus Andrade Torrente > Date: Mon, Mar 16, 2020 at 6:04 PM > Subject: [PATCH] Staging: drm_gem: Fix a typo in a function comment > To: , , > , , , < > sumit.sem...@linaro.org> > Cc: Igor Matheus Andrade Torrente , < > rodrigo.sique...@amd.com>, , < > andrealm...@collabora.com> > > > Replace "pionter" with "pointer" in the > drm_gem_handle_create description. > > Signed-off-by: Igor Matheus Andrade Torrente > --- > drivers/gpu/drm/drm_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 6e960d57371e..c356379f5e97 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -432,7 +432,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, > * drm_gem_handle_create - create a gem handle for an object > * @file_priv: drm file-private structure to register the handle for > * @obj: object to register > - * @handlep: pionter to return the created handle to the caller > + * @handlep: pointer to return the created handle to the caller > * > * Create a handle for this object. This adds a handle reference to the > object, > * which includes a regular reference count. Callers will likely want to > -- > 2.20.1 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm/lease: fix potential race in fill_object_idr
On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> We should hold idr_mutex for idr_alloc.
>
> Signed-off-by: Qiujun Huang
I've not seen the first version of this anywhere in my inbox, not sure
where that got lost.
Anyway, this seems like a false positive - I'm assuming this was caught
with KCSAN. The commit message really should mention that.
fill_object_idr creates the idr, which yes is only access later on under
the idr_mutex. But here it's not yet visible to any other thread, and
hence lockless access is safe and correct.
No idea what the KCSAN complains about safe access like this best practice
is.
-Daniel
> ---
> drivers/gpu/drm/drm_lease.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index b481caf..427ee21 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -418,6 +418,7 @@ static int fill_object_idr(struct drm_device *dev,
> goto out_free_objects;
> }
>
> + mutex_lock(>mode_config.idr_mutex);
> /* add their IDs to the lease request - taking into account
> universal planes */
> for (o = 0; o < object_count; o++) {
> @@ -437,7 +438,7 @@ static int fill_object_idr(struct drm_device *dev,
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object %d cannot be inserted into
> leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
> struct drm_crtc *crtc = obj_to_crtc(obj);
> @@ -445,20 +446,22 @@ static int fill_object_idr(struct drm_device *dev,
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object primary plane %d cannot
> be inserted into leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> if (crtc->cursor) {
> ret = idr_alloc(leases, _lease_idr_object,
> crtc->cursor->base.id, crtc->cursor->base.id + 1, GFP_KERNEL);
> if (ret < 0) {
> DRM_DEBUG_LEASE("Object cursor plane %d
> cannot be inserted into leases (%d)\n",
> object_id, ret);
> - goto out_free_objects;
> + goto out_unlock;
> }
> }
> }
> }
>
> ret = 0;
> +out_unlock:
> + mutex_unlock(>mode_config.idr_mutex);
> out_free_objects:
> for (o = 0; o < object_count; o++) {
> if (objects[o])
> --
> 1.8.3.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] drm/lease: fix WARNING in idr_destroy
On Mon, Mar 16, 2020 at 11:36:08AM +0800, Qiujun Huang wrote:
> leases has been destroyed:
> drm_master_put
> ->drm_master_destroy
> ->idr_destroy
>
> so the "out_lessee" needn't to call idr_destroy again.
>
> Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
> Signed-off-by: Qiujun Huang
> ---
> drivers/gpu/drm/drm_lease.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index b481caf..54506c2 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -577,11 +577,14 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
>
> out_lessee:
> drm_master_put();
> + goto err_exit;
I think this is correct, but also confusioning and inconsistent with the
existing style. Most error cases before drm_lease_create explicit destroy
the idr, except the one for drm_lease_create.
Instead of your patch I'd
- remove the idr_destry from the error unrolling here
- add it the to drm_lease_create error case
- add a comment above the call to drm_lease_crete that it takes ownership
of the lease idr
Can you pls respin and retest to make sure that patch is still correct?
Thanks, Daniel
>
> out_leases:
> - put_unused_fd(fd);
> idr_destroy();
>
> +err_exit:
> + put_unused_fd(fd);
> +
> DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
> return ret;
> }
> --
> 1.8.3.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 v3] drm/bochs: downgrade pci_request_region failure from error to warning
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> Shutdown of firmware framebuffer has a bunch of problems. Because
> of this the framebuffer region might still be reserved even after
> drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime fun where the cleanup might be delayed if
the char device node is still open?
-Daniel
>
> Don't consider pci_request_region() failure for the framebuffer
> region as fatal error to workaround this issue.
>
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index 952199cc0462..dce4672e3fc8 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev)
> size = min(size, mem);
> }
>
> - if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
> - DRM_ERROR("Cannot request framebuffer\n");
> - return -EBUSY;
> - }
> + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
>
> bochs->fb_map = ioremap(addr, size);
> if (bochs->fb_map == NULL) {
> --
> 2.18.2
>
--
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 1/3] drm: drm_vm: Use fallthrough;
On Thu, Mar 12, 2020 at 12:17:12PM -0700, Joe Perches wrote: > Convert /* fallthrough */ style comments to fallthrough; > > Convert the various uses of fallthrough comments to fallthrough; > > Done via script > Link: > https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git@perches.com/ > > And by hand: > > This file has a fallthrough comment outside of an #ifdef block > that causes gcc to emit a warning if converted in-place. > > So move the new fallthrough; inside the containing #ifdef/#endif too. > > Signed-off-by: Joe Perches Acked-by: Daniel Vetter I'm assuming this all lands through a special pull? Or should I apply this? -Daniel > --- > drivers/gpu/drm/drm_vm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index 64619f..fd65c59 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -595,8 +595,8 @@ static int drm_mmap_locked(struct file *filp, struct > vm_area_struct *vma) > vma->vm_ops = _vm_ops; > break; > } > + fallthrough;/* to _DRM_FRAME_BUFFER... */ > #endif > - /* fall through - to _DRM_FRAME_BUFFER... */ > case _DRM_FRAME_BUFFER: > case _DRM_REGISTERS: > offset = drm_core_get_reg_ofs(dev); > @@ -621,7 +621,7 @@ static int drm_mmap_locked(struct file *filp, struct > vm_area_struct *vma) > vma->vm_end - vma->vm_start, vma->vm_page_prot)) > return -EAGAIN; > vma->vm_page_prot = drm_dma_prot(map->type, vma); > - /* fall through - to _DRM_SHM */ > + fallthrough;/* to _DRM_SHM */ > case _DRM_SHM: > vma->vm_ops = _vm_shm_ops; > vma->vm_private_data = (void *)map; > -- > 2.24.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne wrote: > > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > > Hi Jason, > > > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote: > > > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote: > > > > > (I know I'm going to be spammed by so many mailing list ...) > > > > > > > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > > > > > wrote: > > > > > > > All, > > > > > > > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most > > > > > > > people > > > > > > > who reply will get at least one mailing list rejection. However, > > > > > > > this > > > > > > > is an issue that affects a LOT of components and that's why it's > > > > > > > thorny to begin with. Please pardon the length of this e-mail as > > > > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. At > > > > > > > least, that seems to be the consensus among all the graphics > > > > > > > people > > > > > > > I've talked to. I had a chat with one of the lead Android > > > > > > > graphics > > > > > > > engineers recently who told me that doing explicit sync from the > > > > > > > start > > > > > > > was one of the best engineering decisions Android ever made. It's > > > > > > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > > > > > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > > > > > > > For those that aren't familiar with this space, GPUs, media > > > > > > > encoders, > > > > > > > etc. are massively parallel and synchronization of some form is > > > > > > > required to ensure that everything happens in the right order and > > > > > > > avoid data races. Implicit synchronization is when bits of work > > > > > > > (3D, > > > > > > > compute, video encode, etc.) are implicitly based on the absolute > > > > > > > CPU-time order in which API calls occur. Explicit > > > > > > > synchronization is > > > > > > > when the client (whatever that means in any given context) > > > > > > > provides > > > > > > > the dependency graph explicitly via some sort of synchronization > > > > > > > primitives. If you're still confused, consider the following > > > > > > > examples: > > > > > > > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say you > > > > > > > have > > > > > > > two OpenGL contexts sharing an image where one writes to it and > > > > > > > the > > > > > > > other textures from it. The way the OpenGL spec works, the > > > > > > > client has > > > > > > > to make the API calls to render to the image before (in CPU time) > > > > > > > it > > > > > > > makes the API calls which texture from the image. As long as it > > > > > > > does > > > > > > > this (and maybe inserts a glFlush?), the driver will ensure that > > > > > > > the > > > > > > > rendering completes before the texturing happens and you get > > > > > > > correct > > > > > > > contents. > > > > > > > > > > > > > > Implicit synchronization can also happen across processes. > > > > > > > Wayland, > > > > > > > for instance, is currently built on implicit sync where the client > > > > > > > does their rendering and then does a hand-off (via > > > > > > > wl_surface::commit) > > > > > > > to tell the compositor it's done at which point the compositor > > > > > > > can now > > > > > > > texture from the surface. The hand-off ensures that the client's > > > > > > > OpenGL API calls happen before the server's OpenGL API calls. > > > > > > > > > > > > > > A good example of explicit synchronization is the Vulkan API. > > > > > > > There, > > > > > > > a client (or multiple clients) can simultaneously build command > > > > > > > buffers in different threads where one of those command buffers > > > > > > > renders to an image and the other textures from it and then submit > > > > > > > both of them at the same time with instructions to the driver for > > > > > > > which order to execute them in. The execution order is described > > > > > > > via > > > > > > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > > > > > > extension, you can even submit the work which does the texturing > > > > > > > BEFORE the work which does the rendering and the driver will sort > > > > > > > it > > > > > > > out. > > > > > > > > > > > > > > The #1 problem with implicit synchronization (which explicit > > > > > > > solves) > > > > > > > is that it leads to a lot of over-synchronization both in client > > > > > > > space > > > > > > > and in driver/device space. The client has to synchronize a lot > > > > > > > more > > > > > > > because it has to ensure that the API calls happen in a
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hi Tejun, What's your thoughts on this latest series? Regards, Kenny On Wed, Feb 26, 2020 at 2:02 PM Kenny Ho wrote: > > This is a submission for the introduction of a new cgroup controller for the > drm subsystem follow a series of RFCs [v1, v2, v3, v4] > > Changes from PR v1 > * changed cgroup controller name from drm to gpu > * removed lgpu > * added compute.weight resources, clarified resources being distributed as > partitions of compute device > > PR v1: https://www.spinics.net/lists/cgroups/msg24479.html > > Changes from the RFC base on the feedbacks: > * drop all drm.memory.* related implementation and focus only on buffer and > lgpu > * add weight resource type for logical gpu (lgpu) > * uncoupled drmcg device iteration from drm_minor > > I'd also like to highlight the fact that these patches are currently released > under MIT/X11 license aligning with the norm of the drm subsystem, but I am > working to have the cgroup parts release under GPLv2 to align with the norm > of the cgroup subsystem. > > RFC: > [v1]: > https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html > [v2]: https://www.spinics.net/lists/cgroups/msg22074.html > [v3]: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036026.html > [v4]: https://patchwork.kernel.org/cover/11120371/ > > Changes since the start of RFC are as follows: > > v4: > Unchanged (no review needed) > * drm.memory.*/ttm resources (Patch 9-13, I am still working on memory > bandwidth > and shrinker) > Base on feedbacks on v3: > * update nominclature to drmcg > * embed per device drmcg properties into drm_device > * split GEM buffer related commits into stats and limit > * rename function name to align with convention > * combined buffer accounting and check into a try_charge function > * support buffer stats without limit enforcement > * removed GEM buffer sharing limitation > * updated documentations > New features: > * introducing logical GPU concept > * example implementation with AMD KFD > > v3: > Base on feedbacks on v2: > * removed .help type file from v2 > * conform to cgroup convention for default and max handling > * conform to cgroup convention for addressing device specific limits (with > major:minor) > New function: > * adopted memparse for memory size related attributes > * added macro to marshall drmcgrp cftype private ?(DRMCG_CTF_PRIV, etc.) > * added ttm buffer usage stats (per cgroup, for system, tt, vram.) > * added ttm buffer usage limit (per cgroup, for vram.) > * added per cgroup bandwidth stats and limiting (burst and average bandwidth) > > v2: > * Removed the vendoring concepts > * Add limit to total buffer allocation > * Add limit to the maximum size of a buffer allocation > > v1: cover letter > > The purpose of this patch series is to start a discussion for a generic cgroup > controller for the drm subsystem. The design proposed here is a very early > one. We are hoping to engage the community as we develop the idea. > > Backgrounds > === > Control Groups/cgroup provide a mechanism for aggregating/partitioning sets of > tasks, and all their future children, into hierarchical groups with > specialized > behaviour, such as accounting/limiting the resources which processes in a > cgroup can access[1]. Weights, limits, protections, allocations are the main > resource distribution models. Existing cgroup controllers includes cpu, > memory, io, rdma, and more. cgroup is one of the foundational technologies > that enables the popular container application deployment and management > method. > > Direct Rendering Manager/drm contains code intended to support the needs of > complex graphics devices. Graphics drivers in the kernel may make use of DRM > functions to make tasks like memory management, interrupt handling and DMA > easier, and provide a uniform interface to applications. The DRM has also > developed beyond traditional graphics applications to support compute/GPGPU > applications. > > Motivations > === > As GPU grow beyond the realm of desktop/workstation graphics into areas like > data center clusters and IoT, there are increasing needs to monitor and > regulate GPU as a resource like cpu, memory and io. > > Matt Roper from Intel began working on similar idea in early 2018 [2] for the > purpose of managing GPU priority using the cgroup hierarchy. While that > particular use case may not warrant a standalone drm cgroup controller, there > are other use cases where having one can be useful [3]. Monitoring GPU > resources such as VRAM and buffers, CU (compute unit [AMD's nomenclature])/EU > (execution unit [Intel's nomenclature]), GPU job scheduling [4] can help > sysadmins get a better understanding of the applications usage profile. > Further usage regulations of the aforementioned resources can also help > sysadmins > optimize workload deployment on limited GPU resources. > > With the increased importance of machine learning, data science and other > cloud-based
Re: Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 3:01 AM Simon Ser wrote: > > On Monday, March 16, 2020 5:04 PM, Jason Ekstrand > wrote: > > > Hopefully, that will provide some motivation for other compositors > > (kwin, gnome-shell, etc.) because they now have a real user of it in > > an upstream driver for a major desktop platform and not just a few > > weston examples. However, someone is going to have to drive the > > actual development in those compositors. I'd be very happy if more > > people got involved, :-) > > FWIW, a wlroots pull request is in progress [0]. The plan is first to > accept fence FDs from clients, then send them our fences as a second > step. What exactly are the semantics there? Are you going to somehow wait inside wlroots for the buffer to be 100% idle or are you expecting the client to somehow use explicit for sending buffers implicit to wait for idle? If it's the latter, that's not going to work. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/7] pwm: replace polarity enum with macros
To avoid duplication of pwm polarity definitions,
remove "enum pwm_polarity" and use macros instead.
Prepare to use both polarity flags in DTs.
Signed-off-by: Oleksandr Suvorov
---
drivers/pwm/core.c | 2 +-
drivers/pwm/pwm-atmel-tcb.c | 8
drivers/pwm/pwm-bcm-kona.c | 2 +-
drivers/pwm/pwm-bcm2835.c | 2 +-
drivers/pwm/pwm-berlin.c| 2 +-
drivers/pwm/pwm-ep93xx.c| 2 +-
drivers/pwm/pwm-hibvt.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
drivers/pwm/pwm-omap-dmtimer.c | 2 +-
drivers/pwm/pwm-renesas-tpu.c | 4 ++--
drivers/pwm/pwm-samsung.c | 2 +-
drivers/pwm/pwm-stm32.c | 2 +-
drivers/pwm/pwm-tiecap.c| 2 +-
drivers/pwm/pwm-tiehrpwm.c | 4 ++--
drivers/pwm/pwm-vt8500.c| 2 +-
drivers/pwm/sysfs.c | 2 +-
drivers/staging/greybus/pwm.c | 2 +-
drivers/video/backlight/lp8788_bl.c | 2 +-
include/linux/mfd/lp8788.h | 2 +-
include/linux/pwm.h | 29 -
include/trace/events/pwm.h | 2 +-
21 files changed, 33 insertions(+), 46 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 08afbb5b98aa..2cb9db8d545b 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -257,7 +257,7 @@ static bool pwm_ops_check(const struct pwm_ops *ops)
* Returns: 0 on success or a negative error code on failure.
*/
int pwmchip_add_with_polarity(struct pwm_chip *chip,
- enum pwm_polarity polarity)
+ unsigned int polarity)
{
struct pwm_device *pwm;
unsigned int i;
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index 98526a286347..9e8a0b4b1751 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -31,7 +31,7 @@
ATMEL_TC_BEEVT | ATMEL_TC_BSWTRG)
struct atmel_tcb_pwm_device {
- enum pwm_polarity polarity; /* PWM polarity */
+ unsigned int polarity; /* PWM polarity */
unsigned div; /* PWM clock divider */
unsigned duty; /* PWM duty expressed in clk cycles */
unsigned period;/* PWM period expressed in clk cycles */
@@ -60,7 +60,7 @@ static inline struct atmel_tcb_pwm_chip *to_tcb_chip(struct
pwm_chip *chip)
static int atmel_tcb_pwm_set_polarity(struct pwm_chip *chip,
struct pwm_device *pwm,
- enum pwm_polarity polarity)
+ unsigned int polarity)
{
struct atmel_tcb_pwm_device *tcbpwm = pwm_get_chip_data(pwm);
@@ -147,7 +147,7 @@ static void atmel_tcb_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
unsigned group = pwm->hwpwm / 2;
unsigned index = pwm->hwpwm % 2;
unsigned cmr;
- enum pwm_polarity polarity = tcbpwm->polarity;
+ unsigned int polarity = tcbpwm->polarity;
/*
* If duty is 0 the timer will be stopped and we have to
@@ -206,7 +206,7 @@ static int atmel_tcb_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
unsigned group = pwm->hwpwm / 2;
unsigned index = pwm->hwpwm % 2;
u32 cmr;
- enum pwm_polarity polarity = tcbpwm->polarity;
+ unsigned int polarity = tcbpwm->polarity;
/*
* If duty is 0 the timer will be stopped and we have to
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 02da511814f1..83eab0cc51ce 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -174,7 +174,7 @@ static int kona_pwmc_config(struct pwm_chip *chip, struct
pwm_device *pwm,
}
static int kona_pwmc_set_polarity(struct pwm_chip *chip, struct pwm_device
*pwm,
- enum pwm_polarity polarity)
+ unsigned int polarity)
{
struct kona_pwmc *kp = to_kona_pwmc(chip);
unsigned int chan = pwm->hwpwm;
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 91e24f01b54e..2110aef85f19 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -107,7 +107,7 @@ static void bcm2835_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
}
static int bcm2835_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
- enum pwm_polarity polarity)
+ unsigned int polarity)
{
struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
u32 value;
diff --git a/drivers/pwm/pwm-berlin.c b/drivers/pwm/pwm-berlin.c
index b91c477cc84b..1a080bf33047 100644
--- a/drivers/pwm/pwm-berlin.c
+++ b/drivers/pwm/pwm-berlin.c
@@ -127,7 +127,7 @@ static int berlin_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm_dev,
static int berlin_pwm_set_polarity(struct
[PATCH] Remove stable HAINAN board from max_sclk override check in radeon and amdgpu modules
Signed-off-by: Yassine Oudjana
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 1 -
drivers/gpu/drm/radeon/si_dpm.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 4cb4c891120b..0860e85a2d35 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3439,7 +3439,6 @@ static void si_apply_state_adjust_rules(struct
amdgpu_device *adev,
if (adev->asic_type == CHIP_HAINAN) {
if ((adev->pdev->revision == 0x81) ||
- (adev->pdev->revision == 0x83) ||
(adev->pdev->revision == 0xC3) ||
(adev->pdev->device == 0x6664) ||
(adev->pdev->device == 0x6665) ||
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 05e8b4d0af3f..2cb85dbe728f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2979,7 +2979,6 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
if (rdev->family == CHIP_HAINAN) {
if ((rdev->pdev->revision == 0x81) ||
- (rdev->pdev->revision == 0x83) ||
(rdev->pdev->revision == 0xC3) ||
(rdev->pdev->device == 0x6664) ||
(rdev->pdev->device == 0x6665) ||
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On Fri, Feb 14, 2020 at 7:36 AM Michel Dänzer wrote: > > On 2020-02-14 12:49 p.m., Jani Nikula wrote: > > On Fri, 14 Feb 2020, Chris Wilson wrote: > >> Quoting Jani Nikula (2020-02-14 06:36:15) > >>> On Thu, 13 Feb 2020, Nathan Chancellor wrote: > A recent commit in clang added -Wtautological-compare to -Wall, which is > enabled for i915 after -Wtautological-compare is disabled for the rest > of the kernel so we see the following warning on x86_64: > > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: > result of comparison of constant 576460752303423487 with expression of > type 'unsigned int' is always false > [-Wtautological-constant-out-of-range-compare] > if (unlikely(remain > N_RELOC(ULONG_MAX))) > ^ > ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely' > # define unlikely(x)__builtin_expect(!!(x), 0) > ^ > 1 warning generated. > > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not > account for the case where this file is built for 32-bit x86, where > ULONG_MAX == UINT_MAX and this check is still relevant. > > Cast remain to unsigned long, which keeps the generated code the same > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and > the warning is silenced so we can catch more potential issues in the > future. > > Link: https://github.com/ClangBuiltLinux/linux/issues/778 > Suggested-by: Michel Dänzer > Signed-off-by: Nathan Chancellor > >>> > >>> Works for me as a workaround, > >> > >> But the whole point was that the compiler could see that it was > >> impossible and not emit the code. Doesn't this break that? > > > > It seems that goal and the warning are fundamentally incompatible. > > Not really: > > if (sizeof(remain) >= sizeof(unsigned long) && > unlikely(remain > N_RELOC(ULONG_MAX))) > return -EINVAL; > > In contrast to the cast, this doesn't generate any machine code on 64-bit: > > https://godbolt.org/z/GmUE4S > > but still generates the same code on 32-bit: > > https://godbolt.org/z/hAoz8L Exactly. This check is only a tautology when `sizeof(long) == sizeof(int)` (ie. ILP32 platforms, like 32b x86), notice how BOTH GCC AND Clang generate exactly the same code: https://godbolt.org/z/6ShrDM Both compilers eliminate the check when `-m32` is not set, and generate the exact same check otherwise. How about: ``` diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index d3f4f28e9468..25b9d3f3ad57 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1415,8 +1415,10 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev) urelocs = u64_to_user_ptr(entry->relocs_ptr); remain = entry->relocation_count; +#ifndef CONFIG_64BIT if (unlikely(remain > N_RELOC(ULONG_MAX))) return -EINVAL; +#endif /* * We must check that the entire relocation array is safe ``` We now have 4 proposed solutions: 1. https://lore.kernel.org/lkml/20191123195321.41305-1-natechancel...@gmail.com/ 2. https://lore.kernel.org/lkml/20200211050808.29463-1-natechancel...@gmail.com/ 3. https://lore.kernel.org/lkml/20200214054706.33870-1-natechancel...@gmail.com/ 4. my diff above Let's please come to a resolution on this. -- Thanks, ~Nick Desaulniers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/7] Rework PWM_POLARITY_* flags
PWM_POLARITY_* flags were defined in include/linux/pwm.h as a enum and in include/dt-bindings/pwm/pwm.h as macros. This patchset fixes duplication and introduces using PWM_POLARITY_NORMAL flag instead of '0' constant in DT files. Oleksandr Suvorov (7): pwm: rename the PWM_POLARITY_INVERSED enum dt-bindings: pwm: document the PWM polarity flag dt-bindings: pwm: add normal PWM polarity flag dt-bindings: pwm: add description of PWM polarity pwm: replace polarity enum with macros arm64: dts: pwm: replace polarity constant with macro arm: dts: pwm: replace polarity constant with macro Documentation/devicetree/bindings/pwm/pwm.txt | 1 + arch/arm/boot/dts/am335x-cm-t335.dts | 2 +- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/boot/dts/am3517-evm.dts | 2 +- arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 2 +- arch/arm/boot/dts/at91-kizbox2-common.dtsi| 6 ++-- arch/arm/boot/dts/at91-kizbox3_common.dtsi| 8 ++--- arch/arm/boot/dts/at91-kizboxmini-common.dtsi | 6 ++-- arch/arm/boot/dts/at91-nattis-2-natte-2.dts | 2 +- arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 2 +- arch/arm/boot/dts/at91sam9n12ek.dts | 2 +- arch/arm/boot/dts/at91sam9x5dm.dtsi | 2 +- .../boot/dts/berlin2cd-google-chromecast.dts | 4 +-- arch/arm/boot/dts/da850-evm.dts | 2 +- arch/arm/boot/dts/da850-lego-ev3.dts | 4 +-- arch/arm/boot/dts/exynos4412-midas.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 +- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +- arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 +- arch/arm/boot/dts/exynos5420-peach-pit.dts| 2 +- arch/arm/boot/dts/exynos5422-odroidhc1.dts| 2 +- .../boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +- arch/arm/boot/dts/exynos5422-odroidxu4.dts| 2 +- .../boot/dts/exynos54xx-odroidxu-leds.dtsi| 4 +-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +- arch/arm/boot/dts/imx53-tx53-x13x.dts | 5 ++-- arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts | 2 +- arch/arm/boot/dts/imx6q-display5.dtsi | 2 +- arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 2 +- arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts | 2 +- arch/arm/boot/dts/imx6qdl-tx6-lvds.dtsi | 4 +-- arch/arm/boot/dts/imx7-colibri.dtsi | 4 ++- arch/arm/boot/dts/imx7d-nitrogen7.dts | 3 +- arch/arm/boot/dts/imx7d-pico.dtsi | 3 +- arch/arm/boot/dts/imx7d-sdb.dts | 3 +- arch/arm/boot/dts/imx7ulp-evk.dts | 3 +- arch/arm/boot/dts/iwg20d-q7-common.dtsi | 2 +- .../boot/dts/logicpd-torpedo-baseboard.dtsi | 2 +- arch/arm/boot/dts/meson8b-ec100.dts | 4 +-- arch/arm/boot/dts/meson8b-mxq.dts | 4 +-- arch/arm/boot/dts/meson8b-odroidc1.dts| 4 +-- .../boot/dts/motorola-mapphone-common.dtsi| 3 +- arch/arm/boot/dts/omap3-gta04.dtsi| 2 +- arch/arm/boot/dts/omap3-n900.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-edp.dtsi | 2 +- arch/arm/boot/dts/rk3288-veyron.dtsi | 2 +- arch/arm/boot/dts/rv1108-evb.dts | 2 +- arch/arm/boot/dts/s3c6410-mini6410.dts| 2 +- arch/arm/boot/dts/s5pv210-aries.dtsi | 2 +- arch/arm/boot/dts/s5pv210-smdkv210.dts| 2 +- arch/arm/boot/dts/sun5i-gr8-evb.dts | 2 +- arch/arm/boot/dts/vf-colibri.dtsi | 4 ++- .../dts/allwinner/sun50i-a64-pinebook.dts | 2 +- .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 2 +- .../arm64/boot/dts/amlogic/meson-axg-s400.dts | 3 +- arch/arm64/boot/dts/amlogic/meson-axg.dtsi| 1 + .../boot/dts/amlogic/meson-g12-common.dtsi| 1 + .../boot/dts/amlogic/meson-g12a-sei510.dts| 5 ++-- .../boot/dts/amlogic/meson-g12a-u200.dts | 2 +- .../boot/dts/amlogic/meson-g12a-x96-max.dts | 5 ++-- .../dts/amlogic/meson-g12b-khadas-vim3.dtsi | 4 +-- .../boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4 +-- .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 7 +++-- .../boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 3 +- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 1 + .../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 3 +- .../dts/amlogic/meson-gxbb-nexbox-a95x.dts| 3 +- .../boot/dts/amlogic/meson-gxbb-p20x.dtsi | 3 +- .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 3 +- .../boot/dts/amlogic/meson-gxbb-wetek.dtsi| 3 +- .../boot/dts/amlogic/meson-gxl-s805x-p241.dts | 3 +- .../meson-gxl-s905x-hwacom-amazetv.dts| 3 +- .../amlogic/meson-gxl-s905x-khadas-vim.dts| 2 +- .../amlogic/meson-gxl-s905x-nexbox-a95x.dts | 3 +- .../dts/amlogic/meson-gxl-s905x-p212.dtsi | 3 +- .../dts/amlogic/meson-gxm-khadas-vim2.dts | 5 ++-- .../boot/dts/amlogic/meson-gxm-rbox-pro.dts | 3 +- .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++- .../dts/amlogic/meson-sm1-khadas-vim3l.dts| 2 +-
Re: [PATCH 1/2] dt-binding: Add DSI/LVDS tc358775 bridge bindings
Hi Vinay.
On Tue, Mar 17, 2020 at 12:25:42PM +0530, Vinay Simha B N wrote:
> sam,
>
> i need some inputs on the below error. I had created this file
> Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
> by using vim editor. Do we have any tool to create yaml file?
I use vim myself, but is careful to follow the right syntax.
>
> i do not get the error when running 'make dt_binding_check' in my
> build environment
> Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
>
> is there any tool available similar to scripts/checkpatch.pl -f
> , for yaml files?
Please read Documentation/devicetree/writing-schema.
Here you can find general info + instruction how to install the tools
required for "make dt_binding_check".
I could reproduce the error reported by Rob.
I gave your binding file a shot - there were a lot of smaller issues:
- do not use tabs in yaml files
- be consistent in indent
- vendor prefixed properties needed some extra care
- example was full of bugs
- "..."
- no need for status = "okay";
- properties spelled wrong
For the example I adjusted it to use indent of 4 spaces, which IMO
is more readable than the two spaces used in the other parts of the
file.
I have attached the updated binding file - please review and fix.
This is just a quick shot, I did not do a proper review.
Please rename the file, other files in same dir are named "toshiba,xxx",
so replace '-' with ','.
And try to introduce bugs in the example - and check that the tooling
catches the bug.
hint:
make DT=.../foo.yaml dt_binding_check
is a qucik way to check only your binding.
And for new bindings the preferred license is: (GPL-2.0-only OR BSD-2-Clause)
Sam
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/toshiba-tc358775.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba TC358775 DSI to LVDS bridge bindings
maintainers:
- Vinay Simha BN
description: |
This binding supports DSI to LVDS bridge TC358775
properties:
compatible:
const: toshiba,tc358775
reg:
maxItems: 1
description: i2c address of the bridge, 0x0f
toshiba,dsi-lanes:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 1
maximum: 4
default: 1
description: bla bla
toshiba,dual-link:
$ref: /schemas/types.yaml#definitions/flag
description: bla bla
vdd-supply:
maxItems: 1
description: 1.2V LVDS Power Supply
vddio-supply:
maxItems: 1
description: 1.8V IO Power Supply
stby-gpios:
maxItems: 1
description: Standby pin, Low active
reset-gpios:
maxItems: 1
description: Hardware reset, Low active
ports:
type: object
properties:
port@0:
type: object
description: |
DSI Input. The remote endpoint phandle should be a
reference to a valid mipi_dsi_host device node.
port@1:
type: object
description: |
Video port for LVDS output (panel or connector).
required:
- port@0
- port@1
required:
- compatible
- reg
- tc,dsi-lanes
- vdd-supply
- vddio-supply
- stby-gpios
- reset-gpios
- ports
examples:
- |+
#include
i2c@78b8000 {
#address-cells = <1>;
#size-cells = <0>;
/* On High speed expansion */
label = "HS-I2C2";
status = "okay";
tc_bridge: bridge@f {
compatible = "toshiba,tc358775";
reg = <0x0f>;
tc,dsi-lanes = <4>;
tc,dual-link = <0>;
vdd-supply = <_l2>;
vddio-supply = <_l6>;
stby-gpios = < 99 GPIO_ACTIVE_LOW>;
reset-gpios = < 72 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
d2l_in: endpoint {
remote-endpoint = <_out>;
};
};
port@1 {
reg = <1>;
d2l_out: endpoint {
remote-endpoint = <_in>;
};
};
};
};
};
panel: auo,b101xtn01 {
status = "okay";
compatible = "auo,b101xtn01", "panel-lvds";
power-supply = <_l14>;
width-mm = <223>;
height-mm = <125>;
data-mapping = "jeida-24";
panel-timing {
/* 1366x768 @60Hz */
clock-frequency = <7200>;
hactive = <1366>;
vactive = <768>;
hsync-len = <70>;
hfront-porch = <20>;
hback-porch = <0>;
vsync-len = <42>;
vfront-porch = <14>;
vback-porch = <0>;
};
port {
panel_in: endpoint {
remote-endpoint = <_out>;
};
};
};
[PATCH 1/2] drm: encoder_slave: fix refcouting error for modules
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_encoder_slave.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index cf804389f5ec..d50a7884e69e 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -84,7 +84,7 @@ int drm_i2c_encoder_init(struct drm_device *dev,
err = encoder_drv->encoder_init(client, dev, encoder);
if (err)
- goto fail_unregister;
+ goto fail_module_put;
if (info->platform_data)
encoder->slave_funcs->set_config(>base,
@@ -92,9 +92,10 @@ int drm_i2c_encoder_init(struct drm_device *dev,
return 0;
+fail_module_put:
+ module_put(module);
fail_unregister:
i2c_unregister_device(client);
- module_put(module);
fail:
return err;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Tue, Mar 17, 2020 at 01:28:13PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote: > > On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote: > > > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a > > > > driver can > > > > look at the struct page but what if a driver needs to fault in a page > > > > from > > > > another device's private memory? Should it call handle_mm_fault()? > > > > > > Isn't that what this series basically does? > > > > > > The dev_private_owner is set to the type of pgmap the device knows how > > > to handle, and everything else is automatically faulted for the > > > device. > > > > > > If the device does not know how to handle device_private then it sets > > > dev_private_owner to NULL and it never gets device_private pfns. > > > > > > Since the device_private pfn cannot be dma mapped, drivers must have > > > explicit support for them. > > > > No, with this series (and all actual callers before this series) > > we never fault in device private pages. > > IFF we want to fault it in we'd need something like this. But I'd > really prefer to see test cases for that first. In general I think hmm_range_fault should have a mode that is the same as get_user_pages in terms of when it returns a hard failure, and generates faults. AFAIK, GUP will fault in this case? I need this for making ODP use this API. ODP is the one that is highly likely to see other driver's device_private pages and must have them always fault to CPU. > diff --git a/mm/hmm.c b/mm/hmm.c > index b75b3750e03d..2884a3d11a1f 100644 > +++ b/mm/hmm.c > @@ -276,7 +276,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, > unsigned long addr, > if (!fault && !write_fault) > return 0; > > - if (!non_swap_entry(entry)) > + if (!non_swap_entry(entry) || is_device_private_entry(entry)) > goto fault; Yes, OK, makes sense. I've been using v7 of Ralph's tester and it is working well - it has DEVICE_PRIVATE support so I think it can test this flow too. Ralph are you able? This hunk seems trivial enough to me, can we include it now? Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-binding: Add DSI/LVDS tc358775 bridge bindings
sam, i need some inputs on the below error. I had created this file Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml by using vim editor. Do we have any tool to create yaml file? i do not get the error when running 'make dt_binding_check' in my build environment Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml is there any tool available similar to scripts/checkpatch.pl -f , for yaml files? On Sun, Mar 15, 2020 at 8:54 PM Vinay Simha B N wrote: > > rob, > > i do not get the error when running 'make dt_binding_check' in my > build environment > Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml > > is there any tool available similar to scripts/checkpatch.pl -f > , for yaml files? > > On Thu, Mar 12, 2020 at 8:47 PM Rob Herring wrote: > > > > On Wed, 11 Mar 2020 15:18:24 +0530, Vinay Simha BN wrote: > > > Add yaml documentation for DSI/LVDS tc358775 bridge > > > > > > Signed-off-by: Vinay Simha BN > > > > > > --- > > > v1: > > > Initial version > > > --- > > > .../bindings/display/bridge/toshiba-tc358775.yaml | 174 > > > + > > > 1 file changed, 174 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml: > > while scanning for the next token > > found character that cannot start any token > > in "", line 11, column 1 > > Documentation/devicetree/bindings/Makefile:12: recipe for target > > 'Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.example.dts' > > failed > > make[1]: *** > > [Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.example.dts] > > Error 1 > > make[1]: *** Waiting for unfinished jobs > > warning: no schema found in file: > > Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml: > > ignoring, error parsing file > > Makefile:1262: recipe for target 'dt_binding_check' failed > > make: *** [dt_binding_check] Error 2 > > > > See https://patchwork.ozlabs.org/patch/1252753 > > Please check and re-submit. > > > > -- > regards, > vinaysimha -- regards, vinaysimha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: encoder_slave: some updates
While converting I2C users to new APIs, I found a refcounting problem in the encoder_slave implementation. This series fixes it and converts to the new API. Based on linux-next and only build tested. Wolfram Sang (2): drm: encoder_slave: fix refcouting error for modules drm: encoder_slave: use new I2C API drivers/gpu/drm/drm_encoder_slave.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote: > The reason for it being backwards is that "normally" a device doesn't want > the device private page to be faulted back to system memory, it wants to > get the device private struct page so it can update its page table to point > to the memory already in the device. The "backwards" is you set the flag on input and never get it on output, clear the flag in input and maybe get it on output. Compare with valid or write which don't work that way. > Also, a device like Nvidia's GPUs may have an alternate path for copying > one GPU's memory to another (nvlink) without going through system memory > so getting a device private struct page/PFN from hmm_range_fault() that isn't > "owned" by the faulting GPU is useful. > I agree that the current code isn't well tested or thought out for multiple > devices > (rdma, NVMe drives, GPUs, etc.) but it also ties in with peer-to-peer access > via PCIe. I think the series here is a big improvement. The GPU driver can set owners that match the hidden cluster interconnect. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling
On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote: > On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote: > > From: Jason Gunthorpe > > > > Currently if a special PTE is encountered hmm_range_fault() immediately > > returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing > > uses). > > > > EFAULT should only be returned after testing with hmm_pte_need_fault(). > > > > Also pte_devmap() and pte_special() are exclusive, and there is no need to > > check IS_ENABLED, pte_special() is stubbed out to return false on > > unsupported architectures. > > I think the right fix is to just kill HMM_PFN_SPECIAL and treat any > fault on special ptes that aren't the zero page as an error. I have another series that is doing that - this change is to make the next series make sense and not introduce new control logic too. Even when this is switched to ERROR it still needs to have the hmm_range_fault() logic this patch introduces. Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] mm: handle multiple owners of device private pages in migrate_vma
On Mon, Mar 16, 2020 at 06:52:58PM +0100, Christoph Hellwig wrote: > Add a new opaque owner field to struct dev_pagemap, which will allow > the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory, > and refuse to work on mappings not owned by the calling entity. Using a pointer seems like a good solution to me. Is this a bug fix? What is the downside for migrate on pages it doesn't work? I'm not up to speed on migrate.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling
On Tue, Mar 17, 2020 at 02:06:08PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:53:17AM -0300, Jason Gunthorpe wrote: > > > Thinking out loud a bit more: > > > > > > - do we really need HMM_PFN_ERROR, or is just a return value from > > >hmm_range_fault enough? > > > > I'm not totally clear on this. The only use for ERROR is to signal to a > > non-faulting hmm_range_fault (ie shapshot) that the page should generate a > > device fault (ie device SIGSEGV). > > > > We can also handle ERROR by having the device take the fault to CPU, > > then fail during a faulting hmm_range_fault and then dropping the > > ERROR indication toward the device. > > > > If we already know the page cannot be faulted when we read it it feels > > natural to return that too. > > True. Of course we could just stick an ERR_PTR into the page array > in this case. If we make the output here struct page *[] then there is also no reason for hmm_range_fault to exist, get_user_pages already works like that. I see nearly the entire point of hmm_range_fault as being able to return the flags.. > > > - because if it is we don't need output flags at all, and the output > > >array could be struct pages, which would make for a much easier > > >to use API > > > > valid and write is required for the non-faulting case, I don't > > think flags can go away. > > Do we have any cases where these aren't simply kept from the input array? > I couldn't find any, but I've not understood some of the subtle details > before. Not today, I think All this stuff becomes interesting when we have a non-faulting caller of hmm_range_fault(). Then the input request flags will all be 0 and the output flags will indicate the current state of the page table. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
> >
> > On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> >> No driver has actually used properly wire up and support this feature.
> >> There is various code related to it in nouveau, but as far as I can tell
> >> it never actually got turned on, and the only changes since the initial
> >> commit are global cleanups.
> >
> > This is not actually true. OpenCL 2.x does support SVM with nouveau and
> > device private memory via clEnqueueSVMMigrateMem().
> > Also, Ben Skeggs has accepted a set of patches to map GPU memory after being
> > migrated and this change would conflict with that.
>
> Can you explain me how we actually invoke this code?
>
> For that we'd need HMM_PFN_DEVICE_PRIVATE NVIF_VMM_PFNMAP_V0_VRAM
> set in ->pfns before calling hmm_range_fault, which isn't happening.
Oh, I got tripped on this too
The logic is backwards from what you'd think.. If you *set*
HMM_PFN_DEVICE_PRIVATE then this triggers:
hmm_pte_need_fault():
if ((cpu_flags & range->flags[HMM_PFN_DEVICE_PRIVATE])) {
/* Do we fault on device memory ? */
if (pfns & range->flags[HMM_PFN_DEVICE_PRIVATE]) {
*write_fault = pfns & range->flags[HMM_PFN_WRITE];
*fault = true;
}
return;
}
Ie if the cpu page is a DEVICE_PRIVATE and the caller sets
HMM_PFN_DEVICE_PRIVATE in the input flags (pfns) then it always faults
it and never sets HMM_PFN_DEVICE_PRIVATE in the output flags.
So setting 0 enabled device_private support, and nouveau is Ok.
AMDGPU is broken because it can't handle device private and can't set
the flag to supress it.
I was going to try and sort this out as part of getting rid of range->flags
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 02/36] dt-bindings: spi: support non-spi bindings as SPI slaves
Hi Sam, On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote: > Independent bindings can be SPI slaves which for example is > the case for several panel bindings. > > Move SPI slave properties to spi-slave.yaml so the independent > SPI slave bindings can include spi-slave.yaml rather than > duplicating the properties. > > Signed-off-by: Sam Ravnborg > Cc: Maxime Ripard > Cc: Rob Herring > Cc: Mark Brown > Cc: linux-...@vger.kernel.org > --- > .../bindings/spi/spi-controller.yaml | 63 +- > .../devicetree/bindings/spi/spi-slave.yaml| 83 +++ > 2 files changed, 86 insertions(+), 60 deletions(-) > create mode 100644 Documentation/devicetree/bindings/spi/spi-slave.yaml > > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml > b/Documentation/devicetree/bindings/spi/spi-controller.yaml > index 1e0ca6ccf64b..99531c8d10dd 100644 > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml > @@ -67,71 +67,14 @@ patternProperties: >"^.*@[0-9a-f]+$": > type: object > > +allOf: > + - $ref: spi-slave.yaml# > + > properties: >compatible: > description: >Compatible of the SPI device. > > - reg: > -minimum: 0 > -maximum: 256 > -description: > - Chip select used by the device. > - > - spi-3wire: > -$ref: /schemas/types.yaml#/definitions/flag > -description: > - The device requires 3-wire mode. > - > - spi-cpha: > -$ref: /schemas/types.yaml#/definitions/flag > -description: > - The device requires shifted clock phase (CPHA) mode. > - > - spi-cpol: > -$ref: /schemas/types.yaml#/definitions/flag > -description: > - The device requires inverse clock polarity (CPOL) mode. > - > - spi-cs-high: > -$ref: /schemas/types.yaml#/definitions/flag > -description: > - The device requires the chip select active high. > - > - spi-lsb-first: > -$ref: /schemas/types.yaml#/definitions/flag > -description: > - The device requires the LSB first mode. > - > - spi-max-frequency: > -$ref: /schemas/types.yaml#/definitions/uint32 > -description: > - Maximum SPI clocking speed of the device in Hz. > - > - spi-rx-bus-width: > -allOf: > - - $ref: /schemas/types.yaml#/definitions/uint32 > - - enum: [ 1, 2, 4, 8 ] > - - default: 1 > -description: > - Bus width to the SPI bus used for MISO. > - > - spi-rx-delay-us: > -description: > - Delay, in microseconds, after a read transfer. > - > - spi-tx-bus-width: > -allOf: > - - $ref: /schemas/types.yaml#/definitions/uint32 > - - enum: [ 1, 2, 4, 8 ] > - - default: 1 > -description: > - Bus width to the SPI bus used for MOSI. > - > - spi-tx-delay-us: > -description: > - Delay, in microseconds, after a write transfer. > - I can see what you're trying to do, but you don't really need to. All the SPI devices will be declared under a spi controller node that will validate its child nodes (and thus the devices) already. Doing it this way would actually make all the checks happen twice, once as part of the SPI controller, once as part of the SPI device binding, without any good reason. Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 12/36] dt-bindings: display: convert jdi,lt070me05000 to DT Schema
sam,
Reviewed-by: Vinay Simha BN
Thanks.
On Sun, Mar 15, 2020 at 7:14 PM Sam Ravnborg wrote:
>
> Signed-off-by: Sam Ravnborg
> Cc: Vinay Simha BN
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> .../display/panel/jdi,lt070me05000.txt| 31 -
> .../display/panel/jdi,lt070me05000.yaml | 69 +++
> 2 files changed, 69 insertions(+), 31 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> deleted file mode 100644
> index 4989c91d505f..
> --- a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -JDI model LT070ME05000 1200x1920 7" DSI Panel
> -
> -Required properties:
> -- compatible: should be "jdi,lt070me05000"
> -- vddp-supply: phandle of the regulator that provides the supply voltage
> - Power IC supply (3-5V)
> -- iovcc-supply: phandle of the regulator that provides the supply voltage
> - IOVCC , power supply for LCM (1.8V)
> -- enable-gpios: phandle of gpio for enable line
> - LED_EN, LED backlight enable, High active
> -- reset-gpios: phandle of gpio for reset line
> - This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> - XRES, Reset, Low active
> -- dcdc-en-gpios: phandle of the gpio for power ic line
> - Power IC supply enable, High active
> -
> -Example:
> -
> - dsi0: qcom,mdss_dsi@470 {
> - panel@0 {
> - compatible = "jdi,lt070me05000";
> - reg = <0>;
> -
> - vddp-supply = <_l17>;
> - iovcc-supply = <_lvs7>;
> -
> - enable-gpios = <_gpio 36 GPIO_ACTIVE_HIGH>;
> - reset-gpios = <_pinmux 54 GPIO_ACTIVE_LOW>;
> - dcdc-en-gpios = <_gpio 23 GPIO_ACTIVE_HIGH>;
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
> new file mode 100644
> index ..e0abf68ecb19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/jdi,lt070me05000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: JDI model LT070ME05000 1200x1920 7" DSI Panel
> +
> +maintainers:
> + - Vinay Simha BN
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: jdi,lt070me05000
> +
> + enable-gpios: true
> + reg: true
> + reset-gpios: true
> +
> + vddp-supply:
> +description: |
> + The regulator that provides the supply voltage Power IC supply (3-5V)
> +
> + iovcc-supply:
> +description: |
> + The regulator that provides the supply voltage IOVCC,
> + power supply for LCM (1.8V)
> +
> + dcdc-en-gpios:
> +description: |
> + phandle of the gpio for power ic line
> + Power IC supply enable, High active
> +
> +required:
> + - compatible
> + - reg
> + - vddp-supply
> + - iovcc-supply
> + - enable-gpios
> + - reset-gpios
> + - dcdc-en-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi: qcom,mdss_dsi@470 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "jdi,lt070me05000";
> +reg = <0>;
> +
> +vddp-supply = <_l17>;
> +iovcc-supply = <_lvs7>;
> +
> +enable-gpios = <_gpio 36 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <_pinmux 54 GPIO_ACTIVE_LOW>;
> +dcdc-en-gpios = <_gpio 23 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +
> +...
> --
> 2.20.1
>
--
regards,
vinaysimha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: vmalloc-out-of-bounds Write in bitfill_aligned
syzbot has found a reproducer for the following crash on: HEAD commit:fb33c651 Linux 5.6-rc6 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17dacd55e0 kernel config: https://syzkaller.appspot.com/x/.config?x=9f894bd92023de02 dashboard link: https://syzkaller.appspot.com/bug?extid=e5fd3e65515b48c02a30 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11b8ca75e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=114800e5e0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e5fd3e65515b48c02...@syzkaller.appspotmail.com == BUG: KASAN: vmalloc-out-of-bounds in bitfill_aligned drivers/video/fbdev/core/sysfillrect.c:54 [inline] BUG: KASAN: vmalloc-out-of-bounds in bitfill_aligned+0x34b/0x410 drivers/video/fbdev/core/sysfillrect.c:25 Write of size 8 at addr c90009621000 by task syz-executor767/9337 CPU: 3 PID: 9337 Comm: syz-executor767 Not tainted 5.6.0-rc6-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x315 mm/kasan/report.c:374 __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:506 kasan_report+0xe/0x20 mm/kasan/common.c:641 bitfill_aligned drivers/video/fbdev/core/sysfillrect.c:54 [inline] bitfill_aligned+0x34b/0x410 drivers/video/fbdev/core/sysfillrect.c:25 sys_fillrect+0x415/0x7a0 drivers/video/fbdev/core/sysfillrect.c:291 drm_fb_helper_sys_fillrect+0x1c/0x190 drivers/gpu/drm/drm_fb_helper.c:719 bit_clear_margins+0x2d5/0x4a0 drivers/video/fbdev/core/bitblit.c:232 fbcon_clear_margins+0x1de/0x240 drivers/video/fbdev/core/fbcon.c:1379 fbcon_switch+0xd1b/0x1740 drivers/video/fbdev/core/fbcon.c:2361 redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 fbcon_modechanged+0x5bd/0x780 drivers/video/fbdev/core/fbcon.c:2998 fbcon_update_vcs+0x3a/0x50 drivers/video/fbdev/core/fbcon.c:3045 fb_set_var+0xad0/0xd40 drivers/video/fbdev/core/fbmem.c:1056 do_fb_ioctl+0x390/0x7d0 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl+0x11a/0x180 fs/ioctl.c:763 __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl fs/ioctl.c:770 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x433d29 Code: c4 18 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb da fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff33d61508 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004002e0 RCX: 00433d29 RDX: 21c0 RSI: 4601 RDI: 0003 RBP: 006b2018 R08: R09: 004002e0 R10: R11: 0246 R12: 00401bc0 R13: 00401c50 R14: R15: Memory state around the buggy address: c90009620f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90009620f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c90009621000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ^ c90009621080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 c90009621100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 == ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
> vkAcquireNextImageKHR() [...] it's the application's decision whether it > wants a fence, a semaphore, both or none Correction: "or none" is not allowed ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
On Mon, Mar 16, 2020 at 08:32:15PM +0100, Christoph Hellwig wrote:
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 180e398170b0..cfad65f6a67b 100644
> +++ b/mm/hmm.c
> @@ -118,15 +118,6 @@ static inline void hmm_pte_need_fault(const struct
> hmm_vma_walk *hmm_vma_walk,
> /* We aren't ask to do anything ... */
> if (!(pfns & range->flags[HMM_PFN_VALID]))
> return;
> - /* If this is device memory then only fault if explicitly requested */
> - if ((cpu_flags & range->flags[HMM_PFN_DEVICE_PRIVATE])) {
> - /* Do we fault on device memory ? */
> - if (pfns & range->flags[HMM_PFN_DEVICE_PRIVATE]) {
> - *write_fault = pfns & range->flags[HMM_PFN_WRITE];
> - *fault = true;
> - }
> - return;
> - }
Yes, this is an elegant solution to the input flags.
However, between patch 3 and 4 doesn't this break amd gpu as it will
return device_private pages now if not requested? Squash the two?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling
On Mon, Mar 16, 2020 at 01:49:53PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 09:10:53AM -0300, Jason Gunthorpe wrote: > > On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote: > > > On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote: > > > > From: Jason Gunthorpe > > > > > > > > Currently if a special PTE is encountered hmm_range_fault() immediately > > > > returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing > > > > uses). > > > > > > > > EFAULT should only be returned after testing with hmm_pte_need_fault(). > > > > > > > > Also pte_devmap() and pte_special() are exclusive, and there is no need > > > > to > > > > check IS_ENABLED, pte_special() is stubbed out to return false on > > > > unsupported architectures. > > > > > > I think the right fix is to just kill HMM_PFN_SPECIAL and treat any > > > fault on special ptes that aren't the zero page as an error. > > > > I have another series that is doing that - this change is to make the > > next series make sense and not introduce new control logic too. > > Ok. I had some cleanups like this based of older trees, but if you are > active in this area I think I'll let you handle it. You once said you wanted to loose the weird pfn flags scheme, so before putting hmm_range_fault in ODP I planned to do that. If you have your series someplace send me a URL and I'll look on it Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] docs: fix broken references to text files
On Tue, Mar 17, 2020 at 02:10:47PM +0100, Mauro Carvalho Chehab wrote: > Several references got broken due to txt to ReST conversion. > > Several of them can be automatically fixed with: > > scripts/documentation-file-ref-check --fix > > Signed-off-by: Mauro Carvalho Chehab > Documentation/admin-guide/kernel-parameters.txt | 2 +- > Documentation/memory-barriers.txt| 2 +- > Documentation/process/submit-checklist.rst | 2 +- > .../translations/it_IT/process/submit-checklist.rst | 2 +- > Documentation/translations/ko_KR/memory-barriers.txt | 2 +- > .../translations/zh_CN/filesystems/sysfs.txt | 2 +- > .../translations/zh_CN/process/submit-checklist.rst | 2 +- > Documentation/virt/kvm/arm/pvtime.rst| 2 +- > Documentation/virt/kvm/devices/vcpu.rst | 2 +- > Documentation/virt/kvm/hypercalls.rst| 4 ++-- > arch/powerpc/include/uapi/asm/kvm_para.h | 2 +- > drivers/gpu/drm/Kconfig | 2 +- > drivers/gpu/drm/drm_ioctl.c | 2 +- > drivers/hwtracing/coresight/Kconfig | 2 +- > fs/fat/Kconfig | 8 > fs/fuse/Kconfig | 2 +- > fs/fuse/dev.c| 2 +- > fs/overlayfs/Kconfig | 6 +++--- > include/linux/mm.h | 4 ++-- > include/uapi/linux/ethtool_netlink.h | 2 +- > include/uapi/rdma/rdma_user_ioctl_cmds.h | 2 +- For the rdma files Acked-by: Jason Gunthorpe Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 02/36] dt-bindings: spi: support non-spi bindings as SPI slaves
Hi,
On Mon, Mar 16, 2020 at 10:43:46PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 16, 2020 at 09:48:50PM +0100, Maxime Ripard wrote:
> > Hi Sam,
> >
> > On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> > > Independent bindings can be SPI slaves which for example is
> > > the case for several panel bindings.
> > >
> > > Move SPI slave properties to spi-slave.yaml so the independent
> > > SPI slave bindings can include spi-slave.yaml rather than
> > > duplicating the properties.
> > >
> > > Signed-off-by: Sam Ravnborg
> > > Cc: Maxime Ripard
> > > Cc: Rob Herring
> > > Cc: Mark Brown
> > > Cc: linux-...@vger.kernel.org
> > > ---
> > > .../bindings/spi/spi-controller.yaml | 63 +-
> > > .../devicetree/bindings/spi/spi-slave.yaml| 83 +++
> > > 2 files changed, 86 insertions(+), 60 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/spi/spi-slave.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > > b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > > index 1e0ca6ccf64b..99531c8d10dd 100644
> > > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> > > @@ -67,71 +67,14 @@ patternProperties:
> > >"^.*@[0-9a-f]+$":
> > > type: object
> > >
> > > +allOf:
> > > + - $ref: spi-slave.yaml#
> > > +
> > > properties:
> > >compatible:
> > > description:
> > >Compatible of the SPI device.
> > >
> > > - reg:
> > > -minimum: 0
> > > -maximum: 256
> > > -description:
> > > - Chip select used by the device.
> > > -
> > > - spi-3wire:
> > > -$ref: /schemas/types.yaml#/definitions/flag
> > > -description:
> > > - The device requires 3-wire mode.
> > > -
> > > - spi-cpha:
> > > -$ref: /schemas/types.yaml#/definitions/flag
> > > -description:
> > > - The device requires shifted clock phase (CPHA) mode.
> > > -
> > > - spi-cpol:
> > > -$ref: /schemas/types.yaml#/definitions/flag
> > > -description:
> > > - The device requires inverse clock polarity (CPOL) mode.
> > > -
> > > - spi-cs-high:
> > > -$ref: /schemas/types.yaml#/definitions/flag
> > > -description:
> > > - The device requires the chip select active high.
> > > -
> > > - spi-lsb-first:
> > > -$ref: /schemas/types.yaml#/definitions/flag
> > > -description:
> > > - The device requires the LSB first mode.
> > > -
> > > - spi-max-frequency:
> > > -$ref: /schemas/types.yaml#/definitions/uint32
> > > -description:
> > > - Maximum SPI clocking speed of the device in Hz.
> > > -
> > > - spi-rx-bus-width:
> > > -allOf:
> > > - - $ref: /schemas/types.yaml#/definitions/uint32
> > > - - enum: [ 1, 2, 4, 8 ]
> > > - - default: 1
> > > -description:
> > > - Bus width to the SPI bus used for MISO.
> > > -
> > > - spi-rx-delay-us:
> > > -description:
> > > - Delay, in microseconds, after a read transfer.
> > > -
> > > - spi-tx-bus-width:
> > > -allOf:
> > > - - $ref: /schemas/types.yaml#/definitions/uint32
> > > - - enum: [ 1, 2, 4, 8 ]
> > > - - default: 1
> > > -description:
> > > - Bus width to the SPI bus used for MOSI.
> > > -
> > > - spi-tx-delay-us:
> > > -description:
> > > - Delay, in microseconds, after a write transfer.
> > > -
> >
> > I can see what you're trying to do, but you don't really need to.
> >
> > All the SPI devices will be declared under a spi controller node that
> > will validate its child nodes (and thus the devices) already.
>
> This was the missing piece - thanks.
> And as Mark put it "why is this suddenly an issue"?
> Turns out this is already properly handled and I made up an issue.
> Maybe Mark tried to explian it to me already...
Yeah, the schemas multi-layering thing is pretty difficult to get used
to :)
> >
> > Doing it this way would actually make all the checks happen twice,
> > once as part of the SPI controller, once as part of the SPI device
> > binding, without any good reason.
>
> I had focus on validating the example in the binding
> file and not the full picture.
>
> One thing I do not see properly addressed, but maybe I just miss it.
> What triggers that we catch properties that are not supposed to be
> present?
>
> If we see a unsupported property "foobar":
>
> spi {
> ...
> panel {
>
>foobar = <1>;
> };
> };
>
> somewhere in a SPI slave binding we should catch this.
> If for no other reasons that it could be a simple spelling mistake
> that otherwise could go undetected for a long time.
> But maybe this is really not feasible to do?
So you have multiple things here you
[PATCH libdrm] modetest: set_gamma only if CRTC supports gamma property
Current implementation shows error as "failed to set gamma: Function
no implemented" if platform specific drm has no gamma property implemented
Signed-off-by: Rohit Visavalia
---
tests/modetest/modetest.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index b907ab3..23ee73d 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1328,14 +1328,24 @@ static int set_plane(struct device *dev, struct
plane_arg *p)
static void atomic_set_planes(struct device *dev, struct plane_arg *p,
unsigned int count, bool update)
{
- unsigned int i, pattern = primary_fill;
+ unsigned int i, j, pattern = primary_fill;
+ struct crtc *crtc = NULL;
/* set up planes */
for (i = 0; i < count; i++) {
- if (i > 0)
+ if (i > 0) {
pattern = secondary_fill;
- else
- set_gamma(dev, p[i].crtc_id, p[i].fourcc);
+ } else {
+ for (j = 0; j < dev->resources->res->count_crtcs; j++) {
+ if (p[i].crtc_id ==
+ dev->resources->res->crtcs[j]) {
+ crtc = >resources->crtcs[j];
+ break;
+ }
+ }
+ if (crtc->crtc->gamma_size)
+ set_gamma(dev, p[i].crtc_id, p[i].fourcc);
+ }
if (atomic_set_plane(dev, [i], pattern, update))
return;
@@ -1522,7 +1532,8 @@ static void set_mode(struct device *dev, struct pipe_arg
*pipes, unsigned int co
return;
}
- set_gamma(dev, pipe->crtc->crtc->crtc_id, pipe->fourcc);
+ if (pipe->crtc->crtc->gamma_size)
+ set_gamma(dev, pipe->crtc->crtc->crtc_id, pipe->fourcc);
}
}
--
2.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 13/36] dt-bindings: display: convert kingdisplay,kd035g6-54nt to DT Schema
Hi Sam,
Le dim. 15 mars 2020 à 14:43, Sam Ravnborg a écrit
:
Signed-off-by: Sam Ravnborg
Reviewed-by: Paul Cercueil
Cheers,
-Paul
Cc: Paul Cercueil
Cc: Thierry Reding
Cc: Sam Ravnborg
---
.../panel/kingdisplay,kd035g6-54nt.txt| 42 -
.../panel/kingdisplay,kd035g6-54nt.yaml | 60
+++
2 files changed, 60 insertions(+), 42 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
deleted file mode 100644
index fa9596082e44..
---
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
-
-Required properties:
-- compatible: should be "kingdisplay,kd035g6-54nt"
-- power-supply: See panel-common.txt
-- reset-gpios: See panel-common.txt
-
-Optional properties:
-- backlight: see panel-common.txt
-
-The generic bindings for the SPI slaves documented in [1] also apply.
-
-The device node can contain one 'port' child node with one child
-'endpoint' node, according to the bindings defined in [2]. This
-node should describe panel's video bus.
-
-[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
-[2]: Documentation/devicetree/bindings/graph.txt
-
-Example:
-
- {
- panel@0 {
- compatible = "kingdisplay,kd035g6-54nt";
- reg = <0>;
-
- spi-max-frequency = <3125000>;
- spi-3wire;
- spi-cs-high;
-
- reset-gpios = < 2 GPIO_ACTIVE_LOW>;
-
- backlight = <>;
- power-supply = <>;
-
- port {
- panel_input: endpoint {
- remote-endpoint = <_output>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
new file mode 100644
index ..31fc63294a9f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/kingdisplay,kd035g6-54nt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT
LCD panel
+
+maintainers:
+ - Paul Cercueil
+
+allOf:
+ - $ref: ../../spi/spi-slave.yaml#
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: kingdisplay,kd035g6-54nt
+
+ backlight: true
+ port: true
+ power-supply: true
+ reg: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - power-supply
+ - reset-gpios
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "kingdisplay,kd035g6-54nt";
+reg = <0>;
+
+spi-max-frequency = <3125000>;
+spi-3wire;
+spi-cs-high;
+
+reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+backlight = <>;
+power-supply = <>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <_output>;
+};
+};
+};
+};
+
+...
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <_dldo2>;
+ vcc-supply = <_ldo_io0>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -188,6 +221,10 @@ _pio {
*/
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/3] dt-bindings: display: drop data-mapping from panel-dpi
Hi Sam,
On Sat, Mar 14, 2020 at 04:30:45PM +0100, Sam Ravnborg wrote:
> data-mapping may not be the best way to describe the
> data format used between panels and display interface.
>
> Drop it from the panel-dpi binding so we do not start to rely on it.
> We can then work out how to best describe this mapping and when
> we know it, we can add it to this binding.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Rob Herring
I can't say whether it's the right decision or not, but if you want to
go forward with this, you should maintain the backward compatibility,
so leave the code to deal with this as a fallback solution...
> ---
> .../devicetree/bindings/display/panel/panel-dpi.yaml | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> index f63870384c00..0cd74c8dab42 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> @@ -21,15 +21,6 @@ properties:
>- {}
>- const: panel-dpi
>
> - data-mapping:
> -enum:
> - - rgb24
> - - rgb565
> - - bgr666
> -description: |
> - Describes the media format, how the display panel is connected
> - to the display interface.
> -
And keep that DT property documented too.
You can express that it's only here for compatibility using the
deprecated keyword though.
It doesn't do anything at the moment, but the next spec of the schema
language uses it, so as soon as the library implements it we'll report
it.
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] Fix broken references for Documentation/*
This patch series is against next-20200317. It fixes all references to files under Documentation/* that were moved, renamed or removed. After this patch series, this script: ./scripts/documentation-file-ref-check Doesn't complain about any broken reference. Mauro Carvalho Chehab (12): MAINTAINERS: dt: update display/allwinner file entry MAINTAINERS: dt: update etnaviv file reference MAINTAINERS: drop an old reference to stm32 pwm timers doc docs: dt: fix references to m_can.txt file docs: dt: fix references to ap806-system-controller.txt docs: dt: fix a broken reference to input.yaml docs: dt: fix broken reference to phy-cadence-torrent.yaml docs: fix broken references to text files docs: fix broken references for ReST files that moved around docs: dt: display/ti: fix typos at the devicetree/ directory name docs: filesystems: fix renamed references docs: kernel-parameters.txt: remove reference for removed Intel MPX Documentation/ABI/stable/sysfs-devices-node | 2 +- Documentation/ABI/testing/procfs-smaps_rollup | 2 +- Documentation/admin-guide/cpu-load.rst| 2 +- .../admin-guide/kernel-parameters.txt | 11 ++-- Documentation/admin-guide/nfs/nfsroot.rst | 2 +- .../bindings/arm/freescale/fsl,scu.txt| 2 +- .../bindings/display/ti/ti,am65x-dss.yaml | 2 +- .../bindings/display/ti/ti,j721e-dss.yaml | 2 +- .../bindings/display/ti/ti,k2g-dss.yaml | 2 +- .../devicetree/bindings/gpio/gpio-mvebu.txt | 2 +- .../devicetree/bindings/net/can/tcan4x5x.txt | 2 +- .../bindings/phy/ti,phy-j721e-wiz.yaml| 2 +- .../bindings/thermal/armada-thermal.txt | 2 +- .../doc-guide/maintainer-profile.rst | 2 +- .../driver-api/driver-model/device.rst| 4 +- .../driver-api/driver-model/overview.rst | 2 +- Documentation/filesystems/dax.txt | 2 +- Documentation/filesystems/dnotify.txt | 2 +- .../filesystems/ramfs-rootfs-initramfs.rst| 2 +- Documentation/filesystems/sysfs.rst | 2 +- Documentation/memory-barriers.txt | 2 +- .../powerpc/firmware-assisted-dump.rst| 2 +- Documentation/process/adding-syscalls.rst | 2 +- Documentation/process/submit-checklist.rst| 2 +- .../it_IT/process/adding-syscalls.rst | 2 +- .../it_IT/process/submit-checklist.rst| 2 +- .../translations/ko_KR/memory-barriers.txt| 2 +- .../translations/zh_CN/filesystems/sysfs.txt | 8 +-- .../zh_CN/process/submit-checklist.rst| 2 +- Documentation/virt/kvm/arm/pvtime.rst | 2 +- Documentation/virt/kvm/devices/vcpu.rst | 2 +- Documentation/virt/kvm/hypercalls.rst | 4 +- Documentation/virt/kvm/mmu.rst| 2 +- Documentation/virt/kvm/review-checklist.rst | 2 +- MAINTAINERS | 61 +-- Next/merge.log| 12 ++-- arch/powerpc/include/uapi/asm/kvm_para.h | 2 +- arch/x86/kvm/mmu/mmu.c| 2 +- drivers/base/core.c | 2 +- .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 2 +- .../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 2 +- .../allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +- .../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 2 +- drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_ioctl.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- drivers/hwtracing/coresight/Kconfig | 2 +- drivers/media/v4l2-core/v4l2-fwnode.c | 2 +- fs/Kconfig| 2 +- fs/Kconfig.binfmt | 2 +- fs/adfs/Kconfig | 2 +- fs/affs/Kconfig | 2 +- fs/afs/Kconfig| 6 +- fs/bfs/Kconfig| 2 +- fs/cramfs/Kconfig | 2 +- fs/ecryptfs/Kconfig | 2 +- fs/fat/Kconfig| 8 +-- fs/fuse/Kconfig | 2 +- fs/fuse/dev.c | 2 +- fs/hfs/Kconfig| 2 +- fs/hpfs/Kconfig | 2 +- fs/isofs/Kconfig | 2 +- fs/namespace.c| 2 +- fs/notify/inotify/Kconfig | 2 +- fs/ntfs/Kconfig | 2 +- fs/ocfs2/Kconfig | 2 +- fs/overlayfs/Kconfig | 6 +- fs/proc/Kconfig | 4 +- fs/romfs/Kconfig | 2 +- fs/sysfs/dir.c| 2 +- fs/sysfs/file.c | 2 +- fs/sysfs/mount.c | 2 +- fs/sysfs/symlink.c
[PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++
3 files changed, 376 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..cf0c59015a44 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -433,6 +433,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..c84ed5215984 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..8d56b6579111
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x00, 0x37);
+
Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment
Ccing dri-devel and linux-kernel. -- Forwarded message - From: Igor Matheus Andrade Torrente Date: Mon, Mar 16, 2020 at 6:04 PM Subject: [PATCH] Staging: drm_gem: Fix a typo in a function comment To: , , , , , < sumit.sem...@linaro.org> Cc: Igor Matheus Andrade Torrente , < rodrigo.sique...@amd.com>, , < andrealm...@collabora.com> Replace "pionter" with "pointer" in the drm_gem_handle_create description. Signed-off-by: Igor Matheus Andrade Torrente --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 6e960d57371e..c356379f5e97 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -432,7 +432,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, * drm_gem_handle_create - create a gem handle for an object * @file_priv: drm file-private structure to register the handle for * @obj: object to register - * @handlep: pionter to return the created handle to the caller + * @handlep: pointer to return the created handle to the caller * * Create a handle for this object. This adds a handle reference to the object, * which includes a regular reference count. Callers will likely want to -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 2/8] mm/hmm: don't free the cached pgmap while scanning
On Mon, Mar 16, 2020 at 07:13:24PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 03:07:13PM -0300, Jason Gunthorpe wrote: > > I chose this to be simple without having to goto unwind it. > > > > So, instead like this: > > As ѕaid, and per the previous discussion: I think just removing the > pgmap lookup is the right thing to do here. Something like this patch: OK. I think I get it now. We don't even signal that the pfn is a pgmap to the caller, so the caller must assume the pfn is CPU memory and can be dma mapped. At that point it doesn't matter what kind of pgmap it is. Races here are resolved by notifiers as we can't destroy the pgmap without triggering invalidation of the pte So removing is the right thing to do, and the fixing for the device_private case is closer to the hunk I just sent. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Staging: drm_gem: Fix a misaligned comment block
Fix a checkpatch warning caused by a misaligned comment block.
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 000fa4a1899f..6e960d57371e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -222,10 +222,10 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object
*obj)
return;
/*
- * Must bump handle count first as this may be the last
- * ref, in which case the object would disappear before we
- * checked for a name
- */
+* Must bump handle count first as this may be the last
+* ref, in which case the object would disappear before we
+* checked for a name
+*/
mutex_lock(>object_name_lock);
if (--obj->handle_count == 0) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote: > > On 3/16/20 10:52 AM, Christoph Hellwig wrote: > > No driver has actually used properly wire up and support this feature. > > There is various code related to it in nouveau, but as far as I can tell > > it never actually got turned on, and the only changes since the initial > > commit are global cleanups. > > This is not actually true. OpenCL 2.x does support SVM with nouveau and > device private memory via clEnqueueSVMMigrateMem(). > Also, Ben Skeggs has accepted a set of patches to map GPU memory after being > migrated and this change would conflict with that. Other than the page_to_dmem() possibly doing container_of on the wrong type pgmap, are there other bugs here to fix? Something like this is probably close to the right thing to fix that and work with Christoph's 1/2 patch - Ralph can you check, test, etc? diff --git a/mm/hmm.c b/mm/hmm.c index 9e8f68eb83287a..9fa4748da1b779 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -300,6 +300,20 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr, range->flags[HMM_PFN_DEVICE_PRIVATE]; cpu_flags |= is_write_device_private_entry(entry) ? range->flags[HMM_PFN_WRITE] : 0; + + /* +* If the caller understands this kind of device_private +* page, then leave it as is, otherwise fault it. +*/ + hmm_vma_walk->pgmap = get_dev_pagemap( + device_private_entry_to_pfn(entry), + hmm_vma_walk->pgmap); + if (!unlikely(!pgmap)) + return -EBUSY; + if (hmm_vma_walk->pgmap->owner != + hmm_vma_walk->dev_private_owner) + cpu_flags = 0; + hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags, , _fault); if (fault || write_fault) Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function
On Mon, Mar 16, 2020 at 02:52:13AM -0700, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote: > > Well I would prefer if the drivers can somehow express their requirements > > and get IOVA structures already in the form they need. > > > > Converting the IOVA data from one form to another is sometimes quite costly. > > Especially when it is only temporarily needed. > > We basically have two ways to generate the IOVA: > > - a linear translation for the direct mapping case or some dumb IOMMU > drivers - in that case case there is a 1:1 mapping between input > segments and output segments in DMA mapping > - a non-trivial IOMMU where all aligned segments are merged into > a single IOVA range > > So I don't really see how the dma layer could help much with any > limitation beyond existing max size and dma boundary ones. Christian are you thinking of something like the controllable address scheme in hmm_range_fault() so that the dma_map process can write DMA address pages directly to some HW formatted structure? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi, Here is what should be the final drm-misc-next PR for 5.7. Maxime drm-misc-next-2020-03-17: drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: - dp-mst: Remove register_connector callback, add drm_dp_destroy_connector - Changes to scnprintf on multiple instances Driver Changes: - meson: Support for YUV420 - panel: Support Ortustech COM37H3M, idk-1110wr and idk-2121wr, multiple dotclock fixes The following changes since commit bc1a4130fc0309cc2f43b9cc616ebbc295e886ff: drm/virtio: add case for shmem objects in virtio_gpu_cleanup_object(..) (2020-03-09 10:44:34 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-03-17 for you to fetch changes up to 6afe6929964bca6847986d0507a555a041f07753: drm: Mark up racy check of drm_gem_object.handle_count (2020-03-16 10:31:35 +) drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: - dp-mst: Remove register_connector callback, add drm_dp_destroy_connector - Changes to scnprintf on multiple instances Driver Changes: - meson: Support for YUV420 - panel: Support Ortustech COM37H3M, idk-1110wr and idk-2121wr, multiple dotclock fixes Akeem G Abodunrin (1): drm/mm: Remove redundant assignment in drm_mm_reserve_node Benjamin Gaignard (4): drm: context: Clean up documentation drm: vm: Clean up documentation drm: bufs: Clean up documentation drm: lock: Clean up documentation Chris Wilson (2): drm/mm: Allow drm_mm_initialized() to be used outside of the locks drm: Mark up racy check of drm_gem_object.handle_count Christian König (1): drm/ttm: fix false positive assert Fabrizio Castro (2): dt-bindings: display: Add idk-2121wr binding dt-bindings: display: Add idk-1110wr binding H. Nikolaus Schaller (1): drm/panel-simple: Fix dotclock for Ortustech COM37H3M Heiko Stuebner (1): drm/rockchip: rgb: don't count non-existent devices when determining subdrivers Jonas Karlman (2): drm/bridge: dw-hdmi: set mtmdsclock for deep color drm/bridge: dw-hdmi: add max bpc connector property Kamlesh Gurudasani (1): drm/tiny: fix sparse warning: incorrect type in assignment (different base types) Kees Cook (1): drm/edid: Distribute switch variables for initialization Laurent Pinchart (1): drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel Lyude Paul (3): drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write() drm/dp_mst: Fix drm_dp_check_mstb_guid() return code drm/dp_mst: Convert drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield Manasi Navare (2): drm/edid: Name the detailed monitor range flags drm/edid: Add function to parse EDID descriptors for monitor range Neil Armstrong (9): drm/bridge: dw-hdmi: Plug atomic state hooks to the default implementation drm/bridge: synopsys: dw-hdmi: add bus format negociation drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200a drm/meson: venc: make drm_display_mode const drm/meson: meson_dw_hdmi: add bridge and switch to drm_bridge_funcs drm/meson: dw-hdmi: stop enforcing input_bus_format drm/meson: venc: add support for YUV420 setup drm/meson: vclk: add support for YUV420 setup drm/meson: Add YUV420 output support Pankaj Bharadiya (5): drm: Register connector instead of calling register_connector callback drm: Remove dp mst register connector callbacks drm/dp_mst: Remove register_connector callback drm: Add drm_dp_destroy_connector helper and use it drm: Remove drm dp mst destroy_connector callbacks Sam Ravnborg (1): dt-bindings: display: fix panel warnings Takashi Iwai (2): drm/ttm: Use scnprintf() for avoiding potential buffer overflow drm: sysfs: Use scnprintf() for avoiding potential buffer overflow Ville Syrjälä (5): drm/panel-novatek-nt35510: Fix dotclock drm/panel-ilitek-ili9322: Fix dotclocks drm/panel-lg-lg4573: Fix dotclock drm/panel-sony-acx424akp: Fix dotclocks drm/panel-simple: Fix dotclock for Logic PD Type 28 .../display/panel/advantech,idk-1110wr.yaml| 69 + .../display/panel/advantech,idk-2121wr.yaml| 122 .../bindings/display/panel/elida,kd35t133.yaml | 2 +- .../display/panel/leadtek,ltk500hd1829.yaml| 2 +- .../bindings/display/panel/novatek,nt35510.yaml| 4 +- .../bindings/display/panel/orisetech,otm8009a.yaml | 2 +- .../bindings/display/panel/panel-dpi.yaml | 2 +- .../bindings/display/panel/panel-simple-dsi.yaml | 2 +- .../bindings/display/panel/raydium,rm68200.yaml| 2 +-
Re: Plumbing explicit synchronization through the Linux ecosystem
Hi Jason, I've been wrestling with the sync problems in Wayland some time ago, but only with regards to 3D drivers. The guarantee given by the GL/GLES spec is limited to a single graphics context. If the same buffer is accessed by 2 contexts the outcome is unspecified. The cross-context and cross-process synchronisation is not guaranteed. It happens to work on Mesa, because the read/write locking is implemented in the kernel space, but it didn't work on Broadcom driver, which has read-write interlocks in user space. A Vulkan client makes it even worse because of conflicting requirements: Vulkan's vkQueuePresentKHR() passes in a number of semaphores but disallows waiting. Wayland WSI requires wl_surface_commit() to be called from vkQueuePresentKHR() which does require a wait, unless a synchronisation primitive representing Vulkan samaphores is passed between Vulkan client and the compositor. The most troublesome part was Wayland buffer release mechanism, as it only involves a CPU signalling over Wayland IPC, without any 3D driver involvement. The choices were: explicit synchronisation extension or a buffer copy in the compositor (i.e. compositor textures from the copy, so the client can re-write the original), or some implicit synchronisation in kernel space (but that wasn't an option in Broadcom driver). With regards to V4L2, I believe it could easily work the same way as 3D drivers, i.e. pass a buffer+fence pair to the next stage. The encode always succeeds, but for capture or decode, the main problem is the uncertain outcome, I believe? If we're fine with rendering or displaying an occasional broken frame, then buffer+fence pair would work too. The broken frame will go into the pipeline, but application can drain the pipeline and start over once the capture works again. To answer some points raised by Laurent (although I'm unfamiliar with the camera drivers): > you don't know until capture complete in which buffer the frame has been captured Surely you do, you only don't know in advance if the capture will be successful > but if an error occurs during capture, they can be recycled internally and put to the back of the queue. That would have to change in order to use explicit synchronisation. Every started capture becomes immediately available as a buffer+fence pair. Fence is signalled once the capture is finished (successfully or otherwise). The buffer must not be reused until it's released, possibly with another fence - in that case the buffer must not be reused until the release fence is signalled. Cheers, Tomek On Mon, 16 Mar 2020 at 10:20, Laurent Pinchart < laurent.pinch...@ideasonboard.com> wrote: > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote: > > (I know I'm going to be spammed by so many mailing list ...) > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > wrote: > > > > All, > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most > people > > > > who reply will get at least one mailing list rejection. However, > this > > > > is an issue that affects a LOT of components and that's why it's > > > > thorny to begin with. Please pardon the length of this e-mail as > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. At > > > > least, that seems to be the consensus among all the graphics people > > > > I've talked to. I had a chat with one of the lead Android graphics > > > > engineers recently who told me that doing explicit sync from the > start > > > > was one of the best engineering decisions Android ever made. It's > > > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > For those that aren't familiar with this space, GPUs, media encoders, > > > > etc. are massively parallel and synchronization of some form is > > > > required to ensure that everything happens in the right order and > > > > avoid data races. Implicit synchronization is when bits of work (3D, > > > > compute, video encode, etc.) are implicitly based on the absolute > > > > CPU-time order in which API calls occur. Explicit synchronization is > > > > when the client (whatever that means in any given context) provides > > > > the dependency graph explicitly via some sort of synchronization > > > > primitives. If you're still confused, consider the following > > > > examples: > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say you > have > > > > two OpenGL contexts sharing an image where one writes to it and the > > > > other textures from it. The way the OpenGL spec works, the client > has > > > > to make the API calls to render to the image before (in CPU time) it > > > > makes the API calls which texture from the image. As long as it does > > > > this
Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling
On Tue, Mar 17, 2020 at 01:32:10PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 02:12:01PM +0100, Christoph Hellwig wrote: > > On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote: > > > > Ok. I had some cleanups like this based of older trees, but if you are > > > > active in this area I think I'll let you handle it. > > > > > > You once said you wanted to loose the weird pfn flags scheme, so > > > before putting hmm_range_fault in ODP I planned to do that. > > > > > > If you have your series someplace send me a URL and I'll look on it > > > > I have a local branch I just started hacking on, but it is rather broken > > based on various discussions we had. But for a basic one I'd suggest > > something like: > > > > - kill HMM_PFN_SPECIAL as it serves no purpose > > - split the ->pfns array into an input flags (optional) and an output > >pfn (mandtory) one, using new flags for the input side > > - replace the output flags/values indirection with a bunch of values > >encoded in the high bits of a u64, with the rest used for the pfn > > Thinking out loud a bit more: > > - do we really need HMM_PFN_ERROR, or is just a return value from >hmm_range_fault enough? I'm not totally clear on this. The only use for ERROR is to signal to a non-faulting hmm_range_fault (ie shapshot) that the page should generate a device fault (ie device SIGSEGV). We can also handle ERROR by having the device take the fault to CPU, then fail during a faulting hmm_range_fault and then dropping the ERROR indication toward the device. If we already know the page cannot be faulted when we read it it feels natural to return that too. I have a patch, that now needs rebasing, which removes the PFN_ERROR from the faulting cases. So only non-faulting hmm_range_fault users will see it. faulting users will always see an errno return. > - because if it is we don't need output flags at all, and the output >array could be struct pages, which would make for a much easier >to use API valid and write is required for the non-faulting case, I don't think flags can go away. Being able to do a non-faulting hmm_range_fault is going to be a big performance win for ODP, this is my interest here. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
> GL and GLES are not relevant. What is relevant is EGL, which defines > interfaces to make things work on the native platform. Yes and no. This is what EGL spec says about sharing a texture between contexts: "OpenGL and OpenGL ES makes no attempt to synchronize access to texture objects. If a texture object is bound to more than one context, then it is up to the programmer to ensure that the contents of the object are not being changed via one context while another context is using the texture object for rendering. The results of changing a texture object while another context is using it are undefined." There are similar statements with regards to the lack of synchronisation guarantees for EGL images or between GL and native rendering, etc. But the main thing here is that EGL and Vulkan differ significantly. The eglSwapBuffers() is expected to post an unspecified "back buffer" to the display system using some internal driver magic. EGL driver is then expected to obtain another back buffer at some unspecified point in the future. Vulkan on the other hand is very specific and explicit. The vkQueuePresentKHR() is expected to post a specific vkImage with an explicit set of set of semaphores. Another image is obtained through vkAcquireNextImageKHR() and it's the application's decision whether it wants a fence, a semaphore, both or none with the acquired buffer. The implicit synchronisation doesn't mix well with Vulkan drivers and requires a lot of extra plumbing in the WSI code. > If you are using EGL_WL_bind_wayland_display, then one of the things > it is explicitly allowed/expected to do is to create a Wayland > protocol interface between client and compositor, which can be used to > pass buffer handles and metadata in a platform-specific way. Adding > synchronisation is also possible. Only one-way synchronisation is possible with this mechanism. There's a standard protocol for recycling buffers - wl_buffer_release() so buffer hand-over from the compositor to client remains unsynchronised - see below. > > The most troublesome part was Wayland buffer release mechanism, as it only > > involves a CPU signalling over Wayland IPC, without any 3D driver > > involvement. The choices were: explicit synchronisation extension or a > > buffer copy in the compositor (i.e. compositor textures from the copy, so > > the client can re-write the original), or some implicit synchronisation in > > kernel space (but that wasn't an option in Broadcom driver). > > You can add your own explicit synchronisation extension. I could but that requires implementing in in the driver and in a number of compositors, therefore a standard extension zwp_linux_explicit_synchronization_v1 is much better choice here than a custom one. > In every cross-process and cross-subsystem usecase, synchronisation is > obviously required. The two options for this are to implement kernel > support for implicit synchronisation (as everyone else has done), That would require major changes in driver architecture or a 2nd mechanisms doing the same thing but in kernel space - both are non-starters. > or implement generic support for explicit synchronisation (as we have > been working on with implementations inside Weston and Exosphere at > least), The zwp_linux_explicit_synchronization_v1 is a good step forward. I'm using this extension as a main synchronisation mechanism in EGL and Vulkan driver whenever available. I remember that Gustavo Padovan was working on explicit sync support in the display system some time ago. I hope it got merged into kernel by now, but I don't know to what extend it's actually being used. > or implement private support for explicit synchronisation, If everything else fails, that would be the last resort scenario, but far from ideal and very costly in terms of implementation and maintenance as it would require maintaining custom patches for various 3rd party components or littering them with multiple custom explicit synchronisation schemes. > or do nothing and then be surprised at the lack of synchronisation. Thank you, but no, thank you :) Cheers, Tomek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 86/89] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
Hi Maxime,
On Mon, 2020-02-24 at 10:07 +0100, Maxime Ripard wrote:
> @@ -1460,6 +1456,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> }
>
> struct vc4_hdmi_variant bcm2835_variant = {
> + .max_pixel_clock= 14850,
Just a reminder this might change in the close future:
https://www.spinics.net/lists/arm-kernel/msg793013.html
Regards,
Nicolas
j
> .audio_available= true,
> .cec_available = true,
> .registers = vc4_hdmi_fields,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index cbb1d3ab85d7..ee9753255b68 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -38,6 +38,9 @@ struct vc4_hdmi_variant {
> /* Set to true when the CEC support is available */
> bool cec_available;
>
> + /* Maximum pixel clock supported by the controller (in Hz) */
> + unsigned long long max_pixel_clock;
> +
> /* List of the registers available on that variant */
> const struct vc4_hdmi_register *registers;
>
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
