Re: [PATCH] Add virtio gpu driver.
On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: From: Dave Airlie airl...@gmail.com This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga framebuffer, the later is a pure virtio device. The only concern for this driver is that in the virtio-vga case we have to kick out the firmware framebuffer. Initial revision has only 2d support, 3d (virgl) support requires some more work on the qemu side and will be added later. Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com Standard request from my side for new drm drivers (especially if they're this simple): Can you please update the drivers to latest drm internal interfaces, i.e. using universal planes and atomic? Thanks, Daniel --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/virtio/Kconfig | 11 + drivers/gpu/drm/virtio/Makefile | 9 + drivers/gpu/drm/virtio/virtgpu_debugfs.c | 64 drivers/gpu/drm/virtio/virtgpu_display.c | 527 ++ drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 68 drivers/gpu/drm/virtio/virtgpu_drv.c | 132 drivers/gpu/drm/virtio/virtgpu_drv.h | 326 +++ drivers/gpu/drm/virtio/virtgpu_fb.c | 415 drivers/gpu/drm/virtio/virtgpu_fence.c | 95 ++ drivers/gpu/drm/virtio/virtgpu_gem.c | 120 +++ drivers/gpu/drm/virtio/virtgpu_kms.c | 125 +++ drivers/gpu/drm/virtio/virtgpu_object.c | 174 ++ drivers/gpu/drm/virtio/virtgpu_ttm.c | 451 ++ drivers/gpu/drm/virtio/virtgpu_vq.c | 540 +++ drivers/virtio/virtio_pci_common.c | 2 +- include/drm/drmP.h | 1 + include/uapi/linux/Kbuild| 1 + include/uapi/linux/virtio_gpu.h | 203 include/uapi/linux/virtio_ids.h | 2 +- 21 files changed, 3267 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/virtio/Kconfig create mode 100644 drivers/gpu/drm/virtio/Makefile create mode 100644 drivers/gpu/drm/virtio/virtgpu_debugfs.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_display.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_drm_bus.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_drv.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_drv.h create mode 100644 drivers/gpu/drm/virtio/virtgpu_fb.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_fence.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_gem.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_kms.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_object.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_ttm.c create mode 100644 drivers/gpu/drm/virtio/virtgpu_vq.c create mode 100644 include/uapi/linux/virtio_gpu.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..f2388ea 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -197,6 +197,8 @@ source drivers/gpu/drm/qxl/Kconfig source drivers/gpu/drm/bochs/Kconfig +source drivers/gpu/drm/virtio/Kconfig + source drivers/gpu/drm/msm/Kconfig source drivers/gpu/drm/tegra/Kconfig diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..083d443 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ +obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/ obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_STI) += sti/ diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig new file mode 100644 index 000..55868e2 --- /dev/null +++ b/drivers/gpu/drm/virtio/Kconfig @@ -0,0 +1,11 @@ +config DRM_VIRTIO_GPU + tristate QEMU Virtio GPU + depends on DRM VIRTIO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT +select DRM_KMS_HELPER +select DRM_KMS_FB_HELPER +select DRM_TTM + help +QEMU based virtio GPU. diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile new file mode 100644 index 000..57d59ee --- /dev/null +++ b/drivers/gpu/drm/virtio/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the drm device driver. This driver provides support for the +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. + +ccflags-y := -Iinclude/drm +
Re: [PATCH] Add virtio gpu driver.
On Wed, Mar 25, 2015 at 03:53:09PM +0100, Gerd Hoffmann wrote: Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com Standard request from my side for new drm drivers (especially if they're this simple): Can you please update the drivers to latest drm internal interfaces, i.e. using universal planes and atomic? Have a docs / sample code pointer for me? Picking any of the recently converted drivers or recently merged atomic drivers should be fairly informative. Overall conversion procedure is detailed in http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html And ofc there's the kerneldoc stuff in the drm docbook. If you have questions probably best to ask them in #dri-devel irc, most of the people who've done atomic conversions hang out there and can help out. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote: Hi, Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com Standard request from my side for new drm drivers (especially if they're this simple): Can you please update the drivers to latest drm internal interfaces, i.e. using universal planes and atomic? Up'n'running. Incremental patch: https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpu-2did=b8edf4f38a1ec5a50f6ac8948521a12f862d3d5a v2 coming, but I'll go over the other reviews first. Looking good. Wrt pageflip the current MO is to handroll it in your driver, common approach is to use the msm async commit implementation msm_atomic_commit. The issue is simply that right now there's still no useable generic vblank callback support (drm_irq.c is a mess) hence why the core helpers don't support async flips yet. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] enable migration of driver pages
On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote: On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote: My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. The primary motivation of this series is to reduce fragmentation by allowing more kernel pages to be moved. Conceptually that is a worthwhile goal but there should be at least one major in-kernel user and while balloon pages were a good starting point, I think we really need to see what the zram changes look like at the same time. I think gpu drivers really would be the perfect candidate for compacting kernel page allocations. And this also seems the primary motivation for this patch series, so I think that's really what we should use to judge these patches. Of course then there's the seemingly eternal chicken/egg problem of upstream gpu drivers for SoCs :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] enable migration of driver pages
On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote: On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote: On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote: My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. The primary motivation of this series is to reduce fragmentation by allowing more kernel pages to be moved. Conceptually that is a worthwhile goal but there should be at least one major in-kernel user and while balloon pages were a good starting point, I think we really need to see what the zram changes look like at the same time. I think gpu drivers really would be the perfect candidate for compacting kernel page allocations. And this also seems the primary motivation for this patch series, so I think that's really what we should use to judge these patches. Of course then there's the seemingly eternal chicken/egg problem of upstream gpu drivers for SoCs :( I recognised that the driver he had modified was not an in-tree user so it did not really help the review or the design. I did not think it was very fair to ask that an in-tree GPU driver be converted when it would not help the embedded platform of interest. Converting zram is both a useful illustration of the aops requirements and is expected to be beneficial on the embedded platform. Now, if a GPU driver author was willing to convert theirs as an example then that would be useful! Well my concern is more with merging infrastructure to upstream for drivers which aren't upstream and with no plan to make that happen anytime soon. Seems like just offload a bit to me ... but in the end core mm isn't my thing so not my decision. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFCv3 0/5] enable migration of driver pages
On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote: 2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글: Can the various in-kernel GPU drivers benefit from this? If so, wiring up one or more of those would be helpful? I'm sure that other in-kernel GPU drivers can have benefit. It must be helpful. If I was familiar with other in-kernel GPU drivers code, I tried to patch them. It's too bad. I'll bring dri-devel into the loop here. ARM GPU developers please take a look at this stuff, Laurent, Rob, Eric I suppose. I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion about compaction to ARM GPU developers via Korea ARM branch. I got a reply that they had no time to review it. I hope they're interested to this patch. i915 gpus would support 64kb and 2mb pages, but we never implemented this. I don't think this would fit for gem based drivers since our backing storage is shmemfs. So if we want to implement page migration (which we'd probably want to make large pages work well) we'd need to pimp shmem to a) hand large pages to us b) forward the migrate calls. Probably that means we need to build our own gemfs reusing shmemfs code. I guess something similar would apply for ttm-based drivers (which use shmemfs just for swap-in/out but otherwise have their own page allocator, at least sometimes). Given all that I'd expect anything implementing migrate to just create a gpufs thing for the backing storage, no need for more hooks. There's also other areas for better code sharing among gpu drivers (e.g. mmu notifiers to get off userspace pages slurped inpinned with gup or shrinker callbacks to get the gpu off it's memory binge). But that would all be helper libraries in drm, not sure we need anything new from the core vm. Also there's a bit a lack of gpu drivers from the arm world in upstream, which is probabyl why this patch series doesn't come with a user. Might be better to first upstream the driver before talking about additional infrastructure that it needs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 5/6] virtio-gpu: add basic prime support
On Tue, Sep 22, 2015 at 05:24:29PM +0200, Gerd Hoffmann wrote:
> > > +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> > > +struct vm_area_struct *area)
> > > +{
> > > + WARN_ONCE(1, "not implemented");
> > > + return ENOSYS;
> >
> > This can get called by userspace, so please don't WARN here. Also missing
> > negate sign:
> >
> > return -ENOSYS;
>
> Hmm now checkpatch throws a warning at me:
>
>
>WARNING: ENOSYS means 'invalid syscall nr' and nothing else
>#12: FILE: drivers/gpu/drm/virtio/virtgpu_prime.c:70:
>+ return -ENOSYS;
>
>
> I guess I should use something else then (here and elsewhere in the
> file)? Maybe -EINVAL? Other suggestions?
-ENODEV is what we occasionally pick. drm is fairly creative at errno
abuse, e.g. we already use -ENOENT to signal any kind of lookup failure in
ioctls (even if the fd itself is obviously there so not possible that the
fd isn't there).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 5/6] virtio-gpu: add basic prime support
The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Andreas Pokorny
> + */
> +
> +#include "virtgpu_drv.h"
> +
> +/* Empty Implementations as there should not be any other driver for a
> virtual
> + * device that might share buffers with virtgpu */
> +
> +int virtgpu_gem_prime_pin(struct drm_gem_object *obj)
> +{
> + WARN_ONCE(1, "not implemented");
> + return -ENOSYS;
> +}
> +
> +void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
> +{
> + WARN_ONCE(1, "not implemented");
> +}
> +
> +
> +struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
> +{
> + WARN_ONCE(1, "not implemented");
> + return ERR_PTR(-ENOSYS);
> +}
> +
> +struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> + struct drm_device *dev, struct dma_buf_attachment *attach,
> + struct sg_table *table)
> +{
> + WARN_ONCE(1, "not implemented");
> + return ERR_PTR(-ENOSYS);
> +}
> +
> +void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
> +{
> + WARN_ONCE(1, "not implemented");
> + return ERR_PTR(-ENOSYS);
> +}
> +
> +void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> +{
> + WARN_ONCE(1, "not implemented");
> +}
> +
> +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> +struct vm_area_struct *area)
> +{
> + WARN_ONCE(1, "not implemented");
> + return ENOSYS;
This can get called by userspace, so please don't WARN here. Also missing
negate sign:
return -ENOSYS;
Cheers, Daniel
> +}
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote:
>> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
>> drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
>> that DRM drivers can leave this hook unassigned if they know they want
>> to use drm_atomic_helper_best_encoder().
>
> Could you please update include/drm/drm_modeset_helper_vtables.h to document
> this new behaviour ?
Thanks for reminding me. Please update hooks for both
atomic_best_encoder and best_encoder. Also mention that it's only
optional for atomic drivers. There's lots of examples in that file for
the wording usually used.
> The only drawback I see in this patch is the additional object lookup
> performed by drm_atomic_helper_best_encoder() at runtime. I wonder if we could
> somehow cache the information, as the assignment can't change when there's a
> 1:1 correspondence between encoders and connectors.
drm_encoder_find is an idr lookup. That should be plenty fast,
especially for modeset code. Usually what's too expensive even for
modeset code is linear list walks. But Chris just submitted patches to
convert most of them into simple lookups.
-Daniel
>>> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
>> drivers/gpu/drm/drm_fb_helper.c | 13 -
>> 2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c index f6a3350..849d029 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state
>> *state, if (funcs->atomic_best_encoder)
>> new_encoder = funcs->atomic_best_encoder(connector,
>>connector_state);
>> - else
>> + else if (funcs->best_encoder)
>> new_encoder = funcs->best_encoder(connector);
>> + else
>> + new_encoder = drm_atomic_helper_best_encoder(connector);
>>
>> if (!new_encoder) {
>> DRM_DEBUG_ATOMIC("No suitable encoder found for
>> [CONNECTOR:%d:%s]\n",
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c index 7c2eb75..d44389a 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
>> *fb_helper, my_score++;
>>
>> connector_funcs = connector->helper_private;
>> - encoder = connector_funcs->best_encoder(connector);
>> +
>> + /*
>> + * If the DRM device implements atomic hooks and ->best_encoder() is
>> + * NULL we fallback to the default drm_atomic_helper_best_encoder()
>> + * helper.
>> + */
>> + if (fb_helper->dev->mode_config.funcs->atomic_commit &&
>> + !connector_funcs->best_encoder)
>> + encoder = drm_atomic_helper_best_encoder(connector);
>> + else
>> + encoder = connector_funcs->best_encoder(connector);
>> +
>> if (!encoder)
>> goto out;
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
On Fri, Jun 03, 2016 at 09:37:43AM +0200, Boris Brezillon wrote:
> On Thu, 2 Jun 2016 23:57:02 +0200
> Daniel Vetter <dan...@ffwll.ch> wrote:
>
> > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> > <laurent.pinch...@ideasonboard.com> wrote:
> > > Hi Boris,
> > >
> > > Thank you for the patch.
> > >
> > > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote:
> > >> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
> > >> drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
> > >> that DRM drivers can leave this hook unassigned if they know they want
> > >> to use drm_atomic_helper_best_encoder().
> > >
> > > Could you please update include/drm/drm_modeset_helper_vtables.h to
> > > document
> > > this new behaviour ?
> >
> > Thanks for reminding me. Please update hooks for both
> > atomic_best_encoder and best_encoder. Also mention that it's only
> > optional for atomic drivers. There's lots of examples in that file for
> > the wording usually used.
>
> Hm, I haven't changed anything for the ->atomic_best_encoder() hook, or
> am I missing something?
Before you needed atomic_best_encoder or best_encoder (well that's the
idea at least), now both are optional. Kerneldoc needs to be adjusted in
both places to match new reality after your patch.
-Daniel
>
> >
> > > The only drawback I see in this patch is the additional object lookup
> > > performed by drm_atomic_helper_best_encoder() at runtime. I wonder if we
> > > could
> > > somehow cache the information, as the assignment can't change when
> > > there's a
> > > 1:1 correspondence between encoders and connectors.
> >
> > drm_encoder_find is an idr lookup. That should be plenty fast,
> > especially for modeset code. Usually what's too expensive even for
> > modeset code is linear list walks. But Chris just submitted patches to
> > convert most of them into simple lookups.
> > -Daniel
> >
> > >>> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > >> ---
> > >> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> > >> drivers/gpu/drm/drm_fb_helper.c | 13 -
> > >> 2 files changed, 15 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > >> b/drivers/gpu/drm/drm_atomic_helper.c index f6a3350..849d029 100644
> > >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >> @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state
> > >> *state, if (funcs->atomic_best_encoder)
> > >> new_encoder = funcs->atomic_best_encoder(connector,
> > >>connector_state);
> > >> - else
> > >> + else if (funcs->best_encoder)
> > >> new_encoder = funcs->best_encoder(connector);
> > >> + else
> > >> + new_encoder = drm_atomic_helper_best_encoder(connector);
> > >>
> > >> if (!new_encoder) {
> > >> DRM_DEBUG_ATOMIC("No suitable encoder found for
> > >> [CONNECTOR:%d:%s]\n",
> > >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > >> b/drivers/gpu/drm/drm_fb_helper.c index 7c2eb75..d44389a 100644
> > >> --- a/drivers/gpu/drm/drm_fb_helper.c
> > >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> > >> @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
> > >> *fb_helper, my_score++;
> > >>
> > >> connector_funcs = connector->helper_private;
> > >> - encoder = connector_funcs->best_encoder(connector);
> > >> +
> > >> + /*
> > >> + * If the DRM device implements atomic hooks and ->best_encoder()
> > >> is
> > >> + * NULL we fallback to the default drm_atomic_helper_best_encoder()
> > >> + * helper.
> > >> + */
> > >> + if (fb_helper->dev->mode_config.funcs->atomic_commit &&
> > >> + !connector_funcs->best_encoder)
> > >> + encoder = drm_atomic_helper_best_encoder(connector);
> > >> + else
> > >> + encoder = connector_funcs->best_encoder(connector);
> > >> +
> > >> if (!encoder)
> > >> goto out;
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> > >
> >
> >
> >
>
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid
On Tue, Jun 07, 2016 at 01:47:56PM +0200, Boris Brezillon wrote:
> Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
> drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
> that DRM drivers can leave this hook unassigned if they know they want
> to use drm_atomic_helper_best_encoder().
>
> Update the vtables documentation accordingly.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Applied to drm-misc, thanks. I think I'll wait with the driver patches
until next week or so.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> drivers/gpu/drm/drm_fb_helper.c | 13 -
> include/drm/drm_modeset_helper_vtables.h | 10 --
> 3 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f6a3350..849d029 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -300,8 +300,10 @@ update_connector_routing(struct drm_atomic_state *state,
> if (funcs->atomic_best_encoder)
> new_encoder = funcs->atomic_best_encoder(connector,
>connector_state);
> - else
> + else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> + else
> + new_encoder = drm_atomic_helper_best_encoder(connector);
>
> if (!new_encoder) {
> DRM_DEBUG_ATOMIC("No suitable encoder found for
> [CONNECTOR:%d:%s]\n",
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 7c2eb75..d44389a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2000,7 +2000,18 @@ static int drm_pick_crtcs(struct drm_fb_helper
> *fb_helper,
> my_score++;
>
> connector_funcs = connector->helper_private;
> - encoder = connector_funcs->best_encoder(connector);
> +
> + /*
> + * If the DRM device implements atomic hooks and ->best_encoder() is
> + * NULL we fallback to the default drm_atomic_helper_best_encoder()
> + * helper.
> + */
> + if (fb_helper->dev->mode_config.funcs->atomic_commit &&
> + !connector_funcs->best_encoder)
> + encoder = drm_atomic_helper_best_encoder(connector);
> + else
> + encoder = connector_funcs->best_encoder(connector);
> +
> if (!encoder)
> goto out;
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index d4619dc..4e7a53b 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -736,6 +736,11 @@ struct drm_connector_helper_funcs {
>* inspect dynamic configuration state should instead use
>* @atomic_best_encoder.
>*
> + * You can leave this function to NULL if the connector is only
> + * attached to a single encoder and you are using the atomic helpers.
> + * In this case, the core will call drm_atomic_helper_best_encoder()
> + * for you.
> + *
>* RETURNS:
>*
>* Encoder that should be used for the given connector and connector
> @@ -752,8 +757,9 @@ struct drm_connector_helper_funcs {
>* need to select the best encoder depending upon the desired
>* configuration and can't select it statically.
>*
> - * This function is used by drm_atomic_helper_check_modeset() and either
> - * this or @best_encoder is required.
> + * This function is used by drm_atomic_helper_check_modeset().
> + * If it is not implemented, the core will fallback to @best_encoder
> + * (or drm_atomic_helper_best_encoder() if @best_encoder is NULL).
>*
>* NOTE:
>*
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 06/20] drm: i915: Rely on the default ->best_encoder() behavior where appropriate
On Fri, Jun 10, 2016 at 05:24:12PM +0200, Daniel Vetter wrote: > On Tue, Jun 07, 2016 at 01:48:01PM +0200, Boris Brezillon wrote: > > For all outputs except dp_mst, we have a 1:1 relationship between > > connectors and encoders and the driver is relying on the atomic helpers: > > we can drop the custom ->best_encoder() implementation and let the core > > call drm_atomic_helper_best_encoder() for us. > > > > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com> > > You can also drop the best_encoder from intel_dp_mst, we only need the > atomic_best_encoder. The best_encoder there was needed to help out the > fbdev emulation. Care to respin? Boris pointed out on irc that this won't work for the fbdev stuff since that has a WARN_ON if theres more than 1 possible encoder. Applied this one here instead. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/20] drm/atomic: Provide default ->best_encoder() behavior
| 9 - > drivers/gpu/drm/msm/edp/edp_connector.c| 10 -- > drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8 > drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c | 9 - > drivers/gpu/drm/omapdrm/omap_connector.c | 10 -- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 3 --- > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 3 --- > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 - > drivers/gpu/drm/rockchip/inno_hdmi.c | 9 - > drivers/gpu/drm/sti/sti_dvo.c | 10 -- > drivers/gpu/drm/sti/sti_hda.c | 10 -- > drivers/gpu/drm/sti/sti_hdmi.c | 10 -- > drivers/gpu/drm/sun4i/sun4i_rgb.c | 10 -- > drivers/gpu/drm/sun4i/sun4i_tv.c | 9 - > drivers/gpu/drm/tegra/drm.h| 2 -- > drivers/gpu/drm/tegra/dsi.c| 1 - > drivers/gpu/drm/tegra/hdmi.c | 1 - > drivers/gpu/drm/tegra/output.c | 8 > drivers/gpu/drm/tegra/rgb.c| 1 - > drivers/gpu/drm/tegra/sor.c | 1 - > drivers/gpu/drm/vc4/vc4_dpi.c | 9 - > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 - > drivers/gpu/drm/virtio/virtgpu_display.c | 10 -- > include/drm/drm_modeset_helper_vtables.h | 10 -- > 50 files changed, 24 insertions(+), 305 deletions(-) > > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Fri, May 27, 2016 at 09:50:27AM +0200, Daniel Vetter wrote: > On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote: > > On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote: > > > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > > > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > > > > > So I entirely missed this, but this isn't really how to implement > > > page_flip for an atomic driver. Working on some stuff and will hack up > > > a likely totally broken patch, but should be enough as guideline. > > > -Daniel > > > > Hmm, no patch in my inbox yet. Care to send it over or give some hints > > what is wrong with this? > > You should use drm_atomic_helper_page_flip as .page_flip hook instead of > rolling your own, when you have a brand-new atomic driver. If that helper > doesn't work that means you have a bug in your driver somewhere. > > And indeed virtio just plugs in drm_atomic_helper_commit, which thus far > doesnt' do nonblocking commits, which means the page flip stuff won't > work. I'm working on generic nonblocking atomic to fix this up. Currently > still wip and buggy though, hence no patches. > > But I'll take you up on the implied offer to help out and test ;-) Ok, patches are now on the list and also in my fdo repo at: https://cgit.freedesktop.org/~danvet/drm/log/ git://people.freedesktop.org/~danvet/drm stuff Would be really awesome if you could test this on virtio. Note that the new nonblocking helpers require that your atomic backend gets the drm event handling right. So if there's a bug in that logic then you'll see lots of dmesg noise about waits timing out (after 10s of waiting). From a quick inspection it should work though. Upshot is that once you get normal modeset to work with those new helpers, then nonblocking should Just Work, and there's no need anymore for additional testing. Or at least shouldn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Mon, May 30, 2016 at 02:06:50PM +0200, Gerd Hoffmann wrote: > Hi, > > > > But I'll take you up on the implied offer to help out and test ;-) > > > > git://people.freedesktop.org/~danvet/drm stuff > > Tried that branch. > > > Would be really awesome if you could test this on virtio. Note that the > > new nonblocking helpers require that your atomic backend gets the drm > > event handling right. So if there's a bug in that logic then you'll see > > lots of dmesg noise about waits timing out (after 10s of waiting). From a > > quick inspection it should work though. > > No timeouts. Yay! > > But it seems crtcs can be (temporarely) disabled now, so we might have > to pick up the crtc from old_state in virtio_gpu_plane_atomic_update to > figure which virtual output needs to be turned off. Ran into this last > week already. Happened with multihead setups only, but the same patch > fixes this one too ;) > > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html Hm, smells more like virtio isn't too happy with the default ordering of the commit operation. The default is: - Disable any crtc/encoders that need to be disabled/change. - Bash new plane setup into hw. - Enable all crtcs/encoders that need to be enabled/have changed. There's two problems: - some hw gets real grumpy if you bash in plane state without the crtc state yet matching. - if you do runtime pm nothing is enabled and the writes get lost at best, or hang your interconnect at worst. That's why you can overwrite atomic_commit_tail, and use something more sensible. See for example what it looks like for rockchip. I have a gut feeling that should also take care of your troubles. Using the old crtc is definitely not what you want. Another option is that virtio isn't happy about bashing in plane state for disabled crtc. Again helpers have you covered, look at the active_only parameter for drm_atomic_helper_commit_planes(). Aside, if you wonder why these defaults: They match what the crtc helpers are doing, but they are a bit surprising indeed. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio-gpu: fix output lookup
On Mon, May 30, 2016 at 02:03:26PM +0200, Gerd Hoffmann wrote:
> Needed for multihead setups where we can have disabled
> outputs and therefore plane->crtc can be NULL.
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
See my reply in the other thread, but I think you have a more fundamental
issue here. I dropped two suggestions worth trying, both need your own
atomic_commit_tail (on top of my branch at least):
- set active_only to true in commit_planes()
- move commit_planes after commit_modeset_enables().
Cheers, Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index 70b44a2..e50674b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -63,11 +63,17 @@ static void virtio_gpu_plane_atomic_update(struct
> drm_plane *plane,
> {
> struct drm_device *dev = plane->dev;
> struct virtio_gpu_device *vgdev = dev->dev_private;
> - struct virtio_gpu_output *output =
> drm_crtc_to_virtio_gpu_output(plane->crtc);
> + struct virtio_gpu_output *output = NULL;
> struct virtio_gpu_framebuffer *vgfb;
> struct virtio_gpu_object *bo;
> uint32_t handle;
>
> + if (plane->state->crtc)
> + output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
> + if (old_state->crtc)
> + output = drm_crtc_to_virtio_gpu_output(old_state->crtc);
> + WARN_ON(!output);
> +
> if (plane->state->fb) {
> vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
> bo = gem_to_virtio_gpu_obj(vgfb->obj);
> --
> 1.8.3.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Tue, May 31, 2016 at 9:34 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > Hi, > >> > Right now the virtual outputs are linked to drm_crtc. To apply any >> > changes I need to lookup the crtc to figure which virtual output should >> > be updated. > >> > So, setting active_only should make sure I have a valid crtc pointer on >> > plane updates, right? It probably also skips the disable + enable crtc >> > steps on commit? What happens when outputs are disabled? > >> Nah, I just misunderstood your patch. If it's all about finding the >> corresponding crtc, then you're all good. > > Yes, it's all about finding the crtc. > >> I thought there was some >> other reason (like the virtual hw getting upset about certain things). > > virtio wouldn't be upset. > > It's a pointless exercise though to first disable the output, just to > re-enable it the next moment with the new page-flipped framebuffer. So > I guess I should look at the active_only thing nevertheless. It's still possible that the plane can get disabled without it getting enabled. Userspace is allowed to do this. But since this suprises a lot of driver writers there's a special atomic_plane_disable hook you can use for the disable path. Instead of hand-rolling that check in your own code. >> btw can you pls drop an ack or r-b >> onto my virtio conversion? I already added your tested-by. > > Grr, mail is not in my dri-devel folder. Guess that is the > "avoid-duplicates" mailman option at work. > > Feel free to just add the r-b too. Or I'll send it for the next version > of the series. Added your r-b locally so it won't get lost on the next round. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann <kra...@redhat.com> wrote: >> but it also means that >> atomic userspace can't use hotspots before we add properties to fbs. And >> doing that is a bit tricky since drm_framebuffer objects are meant to be >> invariant - this assumption is deeply in-grained into the code all over >> the place, everything just compares pointers when semantically it means to >> compare the entire fb (including backing storage pointer/offsets and >> everything). > > Hmm, the hotspot location for a given cursor image is invariant too, so > I don't think that would be a big issue. > > I'd expect userspace define a bunch of cursors, then switch between them > (instead of defining a single cursor, then constantly updating it). Agreed, conceptually it would be a really nice fit to put the hotspot into the invariant drm_framebuffer. I just meant to say that you need to add a bit of new uapi to make it happen, since we can't reuse our existing get/set_prop functions (since those only change props after the object is created). And we also can't use our existing ioctls to enumerate properties of an object (since chicken-egg: you want the list of properties before creating a new framebuffer, so can't use that framebuffer to enumerate them). But really not a big concern. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio-gpu: fix output lookup
On Mon, May 30, 2016 at 02:03:26PM +0200, Gerd Hoffmann wrote:
> Needed for multihead setups where we can have disabled
> outputs and therefore plane->crtc can be NULL.
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index 70b44a2..e50674b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -63,11 +63,17 @@ static void virtio_gpu_plane_atomic_update(struct
> drm_plane *plane,
> {
> struct drm_device *dev = plane->dev;
> struct virtio_gpu_device *vgdev = dev->dev_private;
> - struct virtio_gpu_output *output =
> drm_crtc_to_virtio_gpu_output(plane->crtc);
> + struct virtio_gpu_output *output = NULL;
> struct virtio_gpu_framebuffer *vgfb;
> struct virtio_gpu_object *bo;
> uint32_t handle;
>
> + if (plane->state->crtc)
> + output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
> + if (old_state->crtc)
> + output = drm_crtc_to_virtio_gpu_output(old_state->crtc);
> + WARN_ON(!output);
> +
> if (plane->state->fb) {
> vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
> bo = gem_to_virtio_gpu_obj(vgfb->obj);
> --
> 1.8.3.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
gt; +
> + if (plane->state->fb != old_state->fb) {
> + DRM_DEBUG("cursor update, handle %d, +%d+%d\n", handle,
> + plane->state->crtc_x,
> + plane->state->crtc_y);
> + output->cursor.hdr.type =
> + cpu_to_le32(VIRTIO_GPU_CMD_UPDATE_CURSOR);
> + output->cursor.resource_id = cpu_to_le32(handle);
> +#if 0
> + output->cursor.hot_x = cpu_to_le32(hot_x);
> + output->cursor.hot_y = cpu_to_le32(hot_y);
> +#endif
> + } else {
> + DRM_DEBUG("cursor move +%d+%d\n",
> + plane->state->crtc_x,
> + plane->state->crtc_y);
> + output->cursor.hdr.type =
> + cpu_to_le32(VIRTIO_GPU_CMD_MOVE_CURSOR);
> + }
> + output->cursor.pos.x = cpu_to_le32(plane->state->crtc_x);
> + output->cursor.pos.y = cpu_to_le32(plane->state->crtc_y);
> + virtio_gpu_cursor_ping(vgdev, output);
> + break;
> +
> + case DRM_PLANE_TYPE_PRIMARY:
> + DRM_DEBUG("primary, handle 0x%x, crtc %dx%d+%d+%d\n", handle,
> + plane->state->crtc_w, plane->state->crtc_h,
> + plane->state->crtc_x, plane->state->crtc_y);
> + if (bo && bo->dumb) {
> + virtio_gpu_cmd_transfer_to_host_2d
> + (vgdev, handle, 0,
> + cpu_to_le32(plane->state->crtc_w),
> + cpu_to_le32(plane->state->crtc_h),
> + plane->state->crtc_x, plane->state->crtc_y,
> + );
> + }
> + virtio_gpu_cmd_set_scanout(vgdev, output->index, handle,
> +plane->state->crtc_w,
> +plane->state->crtc_h,
> +plane->state->crtc_x,
> +plane->state->crtc_y);
> + virtio_gpu_cmd_resource_flush(vgdev, handle,
> + plane->state->crtc_x,
> + plane->state->crtc_y,
> + plane->state->crtc_w,
> + plane->state->crtc_h);
> + break;
> +
> + default:
> + WARN_ON(true);
> + }
> }
>
>
> @@ -105,21 +167,29 @@ static const struct drm_plane_helper_funcs
> virtio_gpu_plane_helper_funcs = {
> };
>
> struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev,
> + enum drm_plane_type type,
> int index)
> {
> struct drm_device *dev = vgdev->ddev;
> struct drm_plane *plane;
> - int ret;
> + const uint32_t *formats;
> + int ret, nformats;
>
> plane = kzalloc(sizeof(*plane), GFP_KERNEL);
> if (!plane)
> return ERR_PTR(-ENOMEM);
>
> + if (type == DRM_PLANE_TYPE_CURSOR) {
> + formats = virtio_gpu_cursor_formats;
> + nformats = ARRAY_SIZE(virtio_gpu_cursor_formats);
> + } else {
> + formats = virtio_gpu_formats;
> + nformats = ARRAY_SIZE(virtio_gpu_formats);
> + }
> ret = drm_universal_plane_init(dev, plane, 1 << index,
> _gpu_plane_funcs,
> -virtio_gpu_formats,
> -ARRAY_SIZE(virtio_gpu_formats),
> -DRM_PLANE_TYPE_PRIMARY, NULL);
> +formats, nformats,
> +type, NULL);
> if (ret)
> goto err_plane_init;
>
> --
> 1.8.3.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote: > On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote: > > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > > > So I entirely missed this, but this isn't really how to implement > > page_flip for an atomic driver. Working on some stuff and will hack up > > a likely totally broken patch, but should be enough as guideline. > > -Daniel > > Hmm, no patch in my inbox yet. Care to send it over or give some hints > what is wrong with this? You should use drm_atomic_helper_page_flip as .page_flip hook instead of rolling your own, when you have a brand-new atomic driver. If that helper doesn't work that means you have a bug in your driver somewhere. And indeed virtio just plugs in drm_atomic_helper_commit, which thus far doesnt' do nonblocking commits, which means the page flip stuff won't work. I'm working on generic nonblocking atomic to fix this up. Currently still wip and buggy though, hence no patches. But I'll take you up on the implied offer to help out and test ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v7 00/12] Support non-lru page migration
On Wed, Jun 01, 2016 at 02:41:51PM -0700, Andrew Morton wrote: > On Wed, 1 Jun 2016 08:21:09 +0900 Minchan Kim <minc...@kernel.org> wrote: > > > Recently, I got many reports about perfermance degradation in embedded > > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > > > The problem was fragmentation caused by zram and GPU driver mainly. > > With memory pressure, their pages were spread out all of pageblock and > > it cannot be migrated with current compaction algorithm which supports > > only LRU pages. In the end, compaction cannot work well so reclaimer > > shrinks all of working set pages. It made system very slow and even to > > fail to fork easily which requires order-[2 or 3] allocations. > > > > Other pain point is that they cannot use CMA memory space so when OOM > > kill happens, I can see many free pages in CMA area, which is not > > memory efficient. In our product which has big CMA memory, it reclaims > > zones too exccessively to allocate GPU and zram page although there are > > lots of free space in CMA so system becomes very slow easily. > > But this isn't presently implemented for GPU drivers or for CMA, yes? > > What's the story there? Broken (out-of-tree) drivers that don't allocate their gpu stuff correctly. There's piles of drivers that get_user_page all over the place but then fail to timely get off these pages again. The fix is to get off those pages again (either by unpinning timely, or registering an mmu_notifier if the driver wants to keep the pages pinned indefinitely, as a caching optimization). At least that's my guess, and iirc it was confirmed first time around this series showed up. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Tue, May 31, 2016 at 8:18 AM, Gerd Hoffmann <kra...@redhat.com> wrote: >> > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html >> >> Hm, smells more like virtio isn't too happy with the default ordering of >> the commit operation. The default is: >> >> - Disable any crtc/encoders that need to be disabled/change. >> - Bash new plane setup into hw. >> - Enable all crtcs/encoders that need to be enabled/have changed. >> >> There's two problems: >> - some hw gets real grumpy if you bash in plane state without the crtc >> state yet matching. >> - if you do runtime pm nothing is enabled and the writes get lost at best, >> or hang your interconnect at worst. >> >> That's why you can overwrite atomic_commit_tail, and use something more >> sensible. See for example what it looks like for rockchip. I have a gut >> feeling that should also take care of your troubles. Using the old crtc is >> definitely not what you want. > >> Another option is that virtio isn't happy about bashing in plane state for >> disabled crtc. Again helpers have you covered, look at the active_only >> parameter for drm_atomic_helper_commit_planes(). > > virtio-gpu is a bit simplified compared to real hardware, so there isn't > really separate plane/crtc state. > > Right now the virtual outputs are linked to drm_crtc. To apply any > changes I need to lookup the crtc to figure which virtual output should > be updated. > > So, setting active_only should make sure I have a valid crtc pointer on > plane updates, right? It probably also skips the disable + enable crtc > steps on commit? What happens when outputs are disabled? > > Maybe it makes sense to link our virtual outputs to (primary) planes not > crtcs? Nah, I just misunderstood your patch. If it's all about finding the corresponding crtc, then you're all good. I thought there was some other reason (like the virtual hw getting upset about certain things). I'll pick up your patch into my nonblocking atomic branch to make sure virtio isn't accidentally broken. btw can you pls drop an ack or r-b onto my virtio conversion? I already added your tested-by. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 03/17] drm/exynos: removed optional dummy encoder mode_fixup function.
On Mon, Feb 15, 2016 at 02:49:09PM +0100, Patrik Jakobsson wrote:
> Hi Carlos
>
> Any particular reason why this patch isn't squashed with patch 8/17?
I've squashed them while applying.
-Daniel
>
> Thanks
> Patrik
>
>
> On Mon, Feb 15, 2016 at 1:58 PM, Carlos Palminha
> <carlos.palmi...@synopsys.com> wrote:
> > mode_fixup function for encoder drivers became optional with patch
> > http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palmi...@synopsys.com
> >
> > This patch set nukes all the dummy mode_fixup implementations.
> >
> > (made on top of Daniel topic/drm-misc branch)
> >
> > Signed-off-by: Carlos Palminha <palmi...@synopsys.com>
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index e977a81..736115c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct
> > drm_encoder *encoder)
> > return 0;
> > }
> >
> > -static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
> > - const struct drm_display_mode *mode,
> > - struct drm_display_mode *adjusted_mode)
> > -{
> > - return true;
> > -}
> > -
> > static void exynos_dsi_mode_set(struct drm_encoder *encoder,
> > struct drm_display_mode *mode,
> > struct drm_display_mode *adjusted_mode)
> > @@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder
> > *encoder,
> > }
> >
> > static const struct drm_encoder_helper_funcs
> > exynos_dsi_encoder_helper_funcs = {
> > - .mode_fixup = exynos_dsi_mode_fixup,
> > .mode_set = exynos_dsi_mode_set,
> > .enable = exynos_dsi_enable,
> > .disable = exynos_dsi_disable,
> > --
> > 2.5.0
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
On Tue, Feb 16, 2016 at 02:10:03PM +, Carlos Palminha wrote:
> This patch set nukes all the dummy crtc mode_fixup implementations.
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha <palmi...@synopsys.com>
Applied this one to drm-misc. I'll let the others hang out there for a bit
more to collect acks.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index e70d064..7539eea 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> }
> }
>
> - if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
> - DRM_DEBUG_KMS("CRTC fixup failed\n");
> - goto done;
> + if (crtc_funcs->mode_fixup) {
> + if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
> + adjusted_mode))) {
> + DRM_DEBUG_KMS("CRTC fixup failed\n");
> + goto done;
> + }
> }
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/17] drm encoders cleanup: nuke optional dummy encoder mode_fixup function.
On Mon, Feb 15, 2016 at 12:57:04PM +, Carlos Palminha wrote: > mode_fixup function for encoder drivers became optional with patch > http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palmi...@synopsys.com > > This patch set nukes all the dummy mode_fixup implementations. > > (made on top of Daniel topic/drm-misc branch) > > Changes v1->v2: incorporated Daniel comments > * added signed-off-by line to all patches > * threading enabled due to e-mail server constraints > * common blurb lines to all patches > * add reviewed by Alex, to patches 4 and 14 I've thrown them all into a topic branch for soaking, and plan to merge into drm-misc in the next few days. Thanks, Daniel > > Carlos Palminha (17): > drm/virtio: removed optional dummy encoder mode_fixup function. > drm/udl: removed optional dummy encoder mode_fixup function. > drm/exynos: removed optional dummy encoder mode_fixup function. > drm/amdgpu: removed optional dummy encoder mode_fixup function. > drm/ast: removed optional dummy encoder mode_fixup function. > drm/bochs: removed optional dummy encoder mode_fixup function. > drm/cirrus: removed optional dummy encoder mode_fixup function. > drm/exynos: removed optional dummy encoder mode_fixup function. > drm/gma500: removed optional dummy encoder mode_fixup function. > drm/imx: removed optional dummy encoder mode_fixup function. > drm/msm/mdp: removed optional dummy encoder mode_fixup function. > drm/mgag200: removed optional dummy encoder mode_fixup function. > drm/qxl: removed optional dummy encoder mode_fixup function. > drm/radeon: removed optional dummy encoder mode_fixup function. > drm/rockchip: removed optional dummy encoder mode_fixup function. > drm/sti: removed optional dummy encoder mode_fixup function. > drm/tilcdc: removed optional dummy encoder mode_fixup function. > > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 8 > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 8 > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 8 > drivers/gpu/drm/ast/ast_mode.c | 8 > drivers/gpu/drm/bochs/bochs_kms.c| 8 > drivers/gpu/drm/cirrus/cirrus_mode.c | 9 - > drivers/gpu/drm/exynos/exynos_dp_core.c | 8 > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 > drivers/gpu/drm/gma500/cdv_intel_crt.c | 1 - > drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 1 - > drivers/gpu/drm/gma500/gma_display.c | 7 --- > drivers/gpu/drm/gma500/gma_display.h | 3 --- > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 1 - > drivers/gpu/drm/imx/dw_hdmi-imx.c| 8 > drivers/gpu/drm/imx/imx-ldb.c| 8 > drivers/gpu/drm/imx/imx-tve.c| 8 > drivers/gpu/drm/imx/parallel-display.c | 8 > drivers/gpu/drm/mgag200/mgag200_mode.c | 8 > drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c | 8 > drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c | 8 > drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c | 8 > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 9 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 8 > drivers/gpu/drm/qxl/qxl_display.c| 9 - > drivers/gpu/drm/radeon/atombios_encoders.c | 8 > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 > drivers/gpu/drm/sti/sti_tvout.c | 10 -- > drivers/gpu/drm/tilcdc/tilcdc_panel.c| 9 - > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 9 - > drivers/gpu/drm/udl/udl_encoder.c| 8 > drivers/gpu/drm/virtio/virtgpu_display.c | 8 > 33 files changed, 244 deletions(-) > > -- > 2.5.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 11/16] drm/atmel-hldcd: removed optional dummy crtc mode_fixup function.
On Wed, Feb 17, 2016 at 09:02:44AM +, Carlos Palminha wrote:
> Thanks Boris.
>
> @Daniel, do you want me to resend this patch or will you fix it directly in
> mode-fixup git branch?
I can fix the typos, but I'm meh on the whitespace change ;-) Imo that
doesn't need a resend.
-Daniel
>
> On 16-02-2016 16:58, Boris Brezillon wrote:
> > On Tue, 16 Feb 2016 14:19:06 +
> > Carlos Palminha <carlos.palmi...@synopsys.com> wrote:
> >
> >> This patch set nukes all the dummy crtc mode_fixup implementations.
> >> (made on top of Daniel topic/drm-misc branch)
> >
> > There's 2 typos in the subject line (s/hldcd/hlcdc/ and
> > s/removed/remove/), and you're removing an empty line after
> > atmel_hlcdc_crtc_create() definition (which is correct, but I'm not
> > sure it should be part of the same patch).
> > Otherwise it looks good to me.
> > Once you've fixed those 2 things, you can add my
> >
> > Acked-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> >
> >>
> >> Signed-off-by: Carlos Palminha <palmi...@synopsys.com>
> >> ---
> >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 -
> >> 1 file changed, 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> index 9863291..58c4f78 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> @@ -121,13 +121,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
> >> drm_crtc *c)
> >> cfg);
> >> }
> >>
> >> -static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *crtc,
> >> - const struct drm_display_mode *mode,
> >> - struct drm_display_mode *adjusted_mode)
> >> -{
> >> - return true;
> >> -}
> >> -
> >> static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
> >> {
> >>struct drm_device *dev = c->dev;
> >> @@ -261,7 +254,6 @@ static void atmel_hlcdc_crtc_atomic_flush(struct
> >> drm_crtc *crtc,
> >> }
> >>
> >> static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
> >> - .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
> >>.mode_set = drm_helper_crtc_mode_set,
> >>.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
> >>.mode_set_base = drm_helper_crtc_mode_set_base,
> >> @@ -349,4 +341,3 @@ fail:
> >>atmel_hlcdc_crtc_destroy(>base);
> >>return ret;
> >> }
> >> -
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/17] drm/virtio: removed optional dummy encoder mode_fixup function.
On Fri, Feb 12, 2016 at 01:50:53PM +, Carlos Palminha wrote:
Sob-line from you is missing on all patches, I can't merge them. Also
please copypaste a default blurb to all patches that this is only recently
no longer needed. And dunno what happened to your patch series, the
threading is somehow broken. In case your mail server doesn't accept a big
patch series you can first format .patch files using git format-patch with
threading enabled (should be the default) and then send them out in
chunks.
When resending please also add the r-b tag from Alex for amdgpu/radoen.
Thanks, Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index a165f03..429aa31 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs
> virtio_gpu_crtc_helper_funcs = {
> .atomic_check = virtio_gpu_crtc_atomic_check,
> };
>
> -static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
> static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
> struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
> }
>
> static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
> - .mode_fixup = virtio_gpu_enc_mode_fixup,
> .mode_set = virtio_gpu_enc_mode_set,
> .enable = virtio_gpu_enc_enable,
> .disable= virtio_gpu_enc_disable,
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/16] drm crtc cleanup: nuke optional dummy crtc mode_fixup function.
On Tue, Feb 16, 2016 at 02:09:44PM +, Carlos Palminha wrote: > This patch set nukes all the dummy crtc mode_fixup implementations. > (made on top of Daniel topic/drm-misc branch) > > Carlos Palminha (16): > drm: fixes crct set_mode when crtc mode_fixup is null. > drm/cirrus: removed optional dummy crtc mode_fixup function. > drm/mgag200: removed optional dummy crtc mode_fixup function. > drm/udl: removed optional dummy crtc mode_fixup function. > drm/gma: removed optional dummy crtc mode_fixup function. > drm/rcar-du: removed optional dummy crtc mode_fixup function. > drm/omapdrm: removed optional dummy crtc mode_fixup function. > drm/msm/mdp: removed optional dummy crtc mode_fixup function. > drm/shmobile: removed optional dummy crtc mode_fixup function. > drm/sti: removed optional dummy crtc mode_fixup function. > drm/atmel-hldcd: removed optional dummy crtc mode_fixup function. > drm/nouveau/dispnv04: removed optional dummy crtc mode_fixup function. > drm/virtio: removed optional dummy crtc mode_fixup function. > drm/fsl-dcu: removed optional dummy crtc mode_fixup function. > drm/bochs: removed optional dummy crtc mode_fixup function. > drm/ast: removed optional dummy crtc mode_fixup function. Pulled remaining ones into drm-misc, will send off in a pull request to Dave in a few days if it all checks out. -Daniel > > drivers/gpu/drm/ast/ast_mode.c | 8 > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 - > drivers/gpu/drm/bochs/bochs_kms.c | 8 > drivers/gpu/drm/cirrus/cirrus_mode.c | 13 - > drivers/gpu/drm/drm_crtc_helper.c | 9 ++--- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8 > drivers/gpu/drm/gma500/cdv_intel_display.c | 13 ++--- > drivers/gpu/drm/gma500/gma_display.c | 7 --- > drivers/gpu/drm/gma500/gma_display.h | 3 --- > drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 -- > drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 - > drivers/gpu/drm/gma500/psb_intel_display.c | 1 - > drivers/gpu/drm/mgag200/mgag200_mode.c | 13 - > drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 8 > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 8 > drivers/gpu/drm/nouveau/dispnv04/crtc.c| 8 > drivers/gpu/drm/omapdrm/omap_crtc.c| 8 > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 - > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 8 > drivers/gpu/drm/sti/sti_crtc.c | 9 - > drivers/gpu/drm/udl/udl_modeset.c | 9 - > drivers/gpu/drm/virtio/virtgpu_display.c | 8 > 22 files changed, 12 insertions(+), 158 deletions(-) > > -- > 2.5.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann <kra...@redhat.com> wrote:
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
So I entirely missed this, but this isn't really how to implement
page_flip for an atomic driver. Working on some stuff and will hack up
a likely totally broken patch, but should be enough as guideline.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 49
> ++--
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index c9c1427..f545913 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -125,6 +125,51 @@ static int virtio_gpu_crtc_cursor_move(struct drm_crtc
> *crtc,
> return 0;
> }
>
> +static int virtio_gpu_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> +{
> + struct virtio_gpu_device *vgdev = crtc->dev->dev_private;
> + struct virtio_gpu_output *output =
> + container_of(crtc, struct virtio_gpu_output, crtc);
> + struct drm_plane *plane = crtc->primary;
> + struct virtio_gpu_framebuffer *vgfb;
> + struct virtio_gpu_object *bo;
> + unsigned long irqflags;
> + uint32_t handle;
> +
> + plane->fb = fb;
> + vgfb = to_virtio_gpu_framebuffer(plane->fb);
> + bo = gem_to_virtio_gpu_obj(vgfb->obj);
> + handle = bo->hw_res_handle;
> +
> + DRM_DEBUG("handle 0x%x%s, crtc %dx%d\n", handle,
> + bo->dumb ? ", dumb" : "",
> + crtc->mode.hdisplay, crtc->mode.vdisplay);
> + if (bo->dumb) {
> + virtio_gpu_cmd_transfer_to_host_2d
> + (vgdev, handle, 0,
> +cpu_to_le32(crtc->mode.hdisplay),
> +cpu_to_le32(crtc->mode.vdisplay),
> +0, 0, NULL);
> + }
> + virtio_gpu_cmd_set_scanout(vgdev, output->index, handle,
> + crtc->mode.hdisplay,
> + crtc->mode.vdisplay, 0, 0);
> + virtio_gpu_cmd_resource_flush(vgdev, handle, 0, 0,
> + crtc->mode.hdisplay,
> + crtc->mode.vdisplay);
> +
> + if (event) {
> + spin_lock_irqsave(>dev->event_lock, irqflags);
> + drm_send_vblank_event(crtc->dev, -1, event);
> + spin_unlock_irqrestore(>dev->event_lock, irqflags);
> + }
> +
> + return 0;
> +}
> +
> static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
> .cursor_set2= virtio_gpu_crtc_cursor_set,
> .cursor_move= virtio_gpu_crtc_cursor_move,
> @@ -132,9 +177,7 @@ static const struct drm_crtc_funcs virtio_gpu_crtc_funcs
> = {
> .set_config = drm_atomic_helper_set_config,
> .destroy= drm_crtc_cleanup,
>
> -#if 0 /* not (yet) working without vblank support according to docs */
> - .page_flip = drm_atomic_helper_page_flip,
> -#endif
> + .page_flip = virtio_gpu_page_flip,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote: >> > > Signed-off-by: Dave Airlie <airl...@redhat.com> >> > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> >> > >> > Standard request from my side for new drm drivers (especially if they're >> > this simple): Can you please update the drivers to latest drm internal >> > interfaces, i.e. using universal planes and atomic? >> >> Up'n'running. Incremental patch: >> >> https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpu-2d=b8edf4f38a1ec5a50f6ac8948521a12f862d3d5a >> >> v2 coming, but I'll go over the other reviews first. > > Looking good. Wrt pageflip the current MO is to handroll it in your > driver, common approach is to use the msm async commit implementation > msm_atomic_commit. The issue is simply that right now there's still no > useable generic vblank callback support (drm_irq.c is a mess) hence why > the core helpers don't support async flips yet. I guess I didn't do a good job at looking at your v2: Cursor is still using legacy interfaces and not a proper plane. Would be awesome if you could fix that up. Atomic drivers really shouldn't use the legacy cursor interfaces any more at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/virtio: fix building without CONFIG_FBDEV
On Tue, Aug 02, 2016 at 12:09:15PM +0200, Arnd Bergmann wrote:
> Removing the build-time dependency on DRM_KMS_FB_HELPER means
> we can now build with CONFIG_FB disabled or as a loadable module,
> leading to a link error:
>
> ERROR: "remove_conflicting_framebuffers"
> [drivers/gpu/drm/virtio/virtio-gpu.ko] undefined!
>
> There is no need to call remove_conflicting_framebuffers() if
> CONFIG_FB is disabled, or if the virtio-gpu driver is built-in
> and CONFIG_FB=m, as there won't be any prior consoles that
> are registered at that point.
>
> This adds a compile-time check in the driver to ensure we only
> attempt to call that function if either CONFIG_FB=y or
> both subsystems are configured as loadable modules.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: 0b6320dfdfea ("drm/virtio: make fbdev support really optional")
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Dave, can you pls pick this one up directly?
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> index 7f0e93f87a55..2087569ae8d7 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -65,7 +65,7 @@ int drm_virtio_init(struct drm_driver *driver, struct
> virtio_device *vdev)
> DRM_INFO("pci: %s detected\n",
>vga ? "virtio-vga" : "virtio-gpu-pci");
> dev->pdev = pdev;
> - if (vga)
> + if (IS_REACHABLE(CONFIG_FB) && vga)
> virtio_pci_kick_out_firmware_fb(pdev);
> }
>
> --
> 2.9.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/2] drm: virtio: add virtio_gpu_translate_format
On Mon, Apr 03, 2017 at 09:08:44AM +0200, Gerd Hoffmann wrote:
> Factors out code, no functional change.
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Ugh on the big endian define, I guess we'll never managed to figure this
aspect of drm pixel formats out correctly - they're supposed to encode
endinaness.
But the copy-paste looks correct :-)
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_fb.c| 58 +
> drivers/gpu/drm/virtio/virtgpu_plane.c | 68
> ++
> 3 files changed, 71 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 93900a8..1328185 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -334,6 +334,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device
> *vgdev);
> void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
>
> /* virtio_gpu_plane.c */
> +uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc);
> struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev,
> enum drm_plane_type type,
> int index);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
> b/drivers/gpu/drm/virtio/virtgpu_fb.c
> index 9bfaef3..33df067 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fb.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
> @@ -231,63 +231,9 @@ static int virtio_gpufb_create(struct drm_fb_helper
> *helper,
> mode_cmd.pitches[0] = mode_cmd.width * 4;
> mode_cmd.pixel_format = drm_mode_legacy_fb_format(32, 24);
>
> - switch (mode_cmd.pixel_format) {
> -#ifdef __BIG_ENDIAN
> - case DRM_FORMAT_XRGB:
> - format = VIRTIO_GPU_FORMAT_X8R8G8B8_UNORM;
> - break;
> - case DRM_FORMAT_ARGB:
> - format = VIRTIO_GPU_FORMAT_A8R8G8B8_UNORM;
> - break;
> - case DRM_FORMAT_BGRX:
> - format = VIRTIO_GPU_FORMAT_B8G8R8X8_UNORM;
> - break;
> - case DRM_FORMAT_BGRA:
> - format = VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM;
> - break;
> - case DRM_FORMAT_RGBX:
> - format = VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM;
> - break;
> - case DRM_FORMAT_RGBA:
> - format = VIRTIO_GPU_FORMAT_R8G8B8A8_UNORM;
> - break;
> - case DRM_FORMAT_XBGR:
> - format = VIRTIO_GPU_FORMAT_X8B8G8R8_UNORM;
> - break;
> - case DRM_FORMAT_ABGR:
> - format = VIRTIO_GPU_FORMAT_A8B8G8R8_UNORM;
> - break;
> -#else
> - case DRM_FORMAT_XRGB:
> - format = VIRTIO_GPU_FORMAT_B8G8R8X8_UNORM;
> - break;
> - case DRM_FORMAT_ARGB:
> - format = VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM;
> - break;
> - case DRM_FORMAT_BGRX:
> - format = VIRTIO_GPU_FORMAT_X8R8G8B8_UNORM;
> - break;
> - case DRM_FORMAT_BGRA:
> - format = VIRTIO_GPU_FORMAT_A8R8G8B8_UNORM;
> - break;
> - case DRM_FORMAT_RGBX:
> - format = VIRTIO_GPU_FORMAT_X8B8G8R8_UNORM;
> - break;
> - case DRM_FORMAT_RGBA:
> - format = VIRTIO_GPU_FORMAT_A8B8G8R8_UNORM;
> - break;
> - case DRM_FORMAT_XBGR:
> - format = VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM;
> - break;
> - case DRM_FORMAT_ABGR:
> - format = VIRTIO_GPU_FORMAT_R8G8B8A8_UNORM;
> - break;
> -#endif
> - default:
> - DRM_ERROR("failed to find virtio gpu format for %d\n",
> - mode_cmd.pixel_format);
> + format = virtio_gpu_translate_format(mode_cmd.pixel_format);
> + if (format == 0)
> return -EINVAL;
> - }
>
> size = mode_cmd.pitches[0] * mode_cmd.height;
> obj = virtio_gpu_alloc_object(dev, size, false, true);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index 1ff9c64..372c91c 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -42,6 +42,74 @@ static const uint32_t virtio_gpu_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> +uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
> +{
> + uint32_t format;
> +
> + switch (drm_fourcc) {
> +#ifdef __BIG_ENDIAN
> + case DRM_FORMAT_XRGB:
> +
Re: [PATCH 2/2] drm: virtio: fix virtio_gpu_mode_dumb_create
On Mon, Apr 03, 2017 at 09:08:45AM +0200, Gerd Hoffmann wrote: > Lookup format using virtio_gpu_translate_format() > instead of hardcoding it. Fixes xorg display on > bigendian guests (i.e. ppc64). > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> ow ... :( With what kind of client have you tested this? fbdev? kms native? Should we patch drm_fourcc.h and essentially state that _all_ drm_fourcc are in native endian, don't dare mixing things up? Would be good to send out an rfc and discuss it with radeon/amd maintainers. Afaik they are the only ones who also care about some big endian platforms. On the patch itself, once you've added more details about what/how it falls over: Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> -Daniel > --- > drivers/gpu/drm/virtio/virtgpu_gem.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c > b/drivers/gpu/drm/virtio/virtgpu_gem.c > index 336a57f..cc025d8 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_gem.c > +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c > @@ -88,6 +88,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, > int ret; > uint32_t pitch; > uint32_t resid; > + uint32_t format; > > pitch = args->width * ((args->bpp + 1) / 8); > args->size = pitch * args->height; > @@ -98,9 +99,10 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, > if (ret) > goto fail; > > + format = virtio_gpu_translate_format(DRM_FORMAT_XRGB); > virtio_gpu_resource_id_get(vgdev, ); > - virtio_gpu_cmd_create_resource(vgdev, resid, > -2, args->width, args->height); > + virtio_gpu_cmd_create_resource(vgdev, resid, format, > +args->width, args->height); > > /* attach the object to the resource */ > obj = gem_to_virtio_gpu_obj(gobj); > -- > 2.9.3 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats
On Wed, Apr 05, 2017 at 08:11:25PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 05, 2017 at 10:09:15AM +0200, Laurent Vivier wrote:
> > When we use virtio-vga with a big-endian guest,
> > the mouse pointer disappears.
> >
> > To fix that, on big-endian use DRM_FORMAT_BGRA
> > instead of DRM_FORMAT_ARGB.
> >
> > Signed-off-by: Laurent Vivier <lviv...@redhat.com>
> > ---
> > drivers/gpu/drm/virtio/virtgpu_plane.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> > b/drivers/gpu/drm/virtio/virtgpu_plane.c
> > index 11288ff..3ed7174 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> > @@ -39,7 +39,11 @@ static const uint32_t virtio_gpu_formats[] = {
> > };
> >
> > static const uint32_t virtio_gpu_cursor_formats[] = {
> > +#ifdef __BIG_ENDIAN
> > + DRM_FORMAT_BGRA,
> > +#else
> > DRM_FORMAT_ARGB,
> > +#endif
>
> DRM formats are supposed to be little endian, so this isn't really
> correct.
Reality says they're native endian, and I asked Gerd Hoffman to do a
documentation update and get that reviewed by amd folks (the only other
ones who care).
-Daniel
>
> > };
> >
> > static void virtio_gpu_plane_destroy(struct drm_plane *plane)
> > --
> > 2.9.3
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: virtio: fix kmem_cache_alloc error check
On Mon, Mar 13, 2017 at 09:22:26AM +0100, Gerd Hoffmann wrote: > kmem_cache_alloc returns NULL on error, not ERR_PTR. > > Fixes: f5985bf9cadd4e3ed8d5d9a9cbbb2e39cdb81cd9 > Reported-by: Jiri Slaby <jsl...@suse.cz> > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> I guess we should have smatch integrated into 0day to catch these ... Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> > --- > drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c > b/drivers/gpu/drm/virtio/virtgpu_vq.c > index 472e349..9eb96fb2 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > @@ -97,8 +97,8 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev) > struct virtio_gpu_vbuffer *vbuf; > > vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL); > - if (IS_ERR(vbuf)) > - return ERR_CAST(vbuf); > + if (!vbuf) > + return ERR_PTR(-ENOMEM); > memset(vbuf, 0, VBUFFER_SIZE); > > BUG_ON(size > MAX_INLINE_CMD_SIZE); > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: virtio: use kmem_cache
On Wed, Mar 01, 2017 at 03:09:08PM +0100, Gerd Hoffmann wrote:
> Just use kmem_cache instead of rolling
> our own, limited implementation.
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Looks very reasonable.
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +--
> drivers/gpu/drm/virtio/virtgpu_vq.c | 57
> +++-
> 2 files changed, 11 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 2f76673..4e66e35 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -178,9 +178,7 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_queue ctrlq;
> struct virtio_gpu_queue cursorq;
> - struct list_head free_vbufs;
> - spinlock_t free_vbufs_lock;
> - void *vbufs;
> + struct kmem_cache *vbufs;
> bool vqs_ready;
>
> struct idr resource_idr;
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 43ea0dc..472e349 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -74,51 +74,19 @@ void virtio_gpu_cursor_ack(struct virtqueue *vq)
>
> int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
> {
> - struct virtio_gpu_vbuffer *vbuf;
> - int i, size, count = 16;
> - void *ptr;
> -
> - INIT_LIST_HEAD(>free_vbufs);
> - spin_lock_init(>free_vbufs_lock);
> - count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
> - count += virtqueue_get_vring_size(vgdev->cursorq.vq);
> - size = count * VBUFFER_SIZE;
> - DRM_INFO("virtio vbuffers: %d bufs, %zdB each, %dkB total.\n",
> - count, VBUFFER_SIZE, size / 1024);
> -
> - vgdev->vbufs = kzalloc(size, GFP_KERNEL);
> + vgdev->vbufs = kmem_cache_create("virtio-gpu-vbufs",
> + VBUFFER_SIZE,
> + __alignof__(struct virtio_gpu_vbuffer),
> + 0, NULL);
> if (!vgdev->vbufs)
> return -ENOMEM;
> -
> - for (i = 0, ptr = vgdev->vbufs;
> - i < count;
> - i++, ptr += VBUFFER_SIZE) {
> - vbuf = ptr;
> - list_add(>list, >free_vbufs);
> - }
> return 0;
> }
>
> void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
> {
> - struct virtio_gpu_vbuffer *vbuf;
> - int i, count = 0;
> -
> - count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
> - count += virtqueue_get_vring_size(vgdev->cursorq.vq);
> -
> - spin_lock(>free_vbufs_lock);
> - for (i = 0; i < count; i++) {
> - if (WARN_ON(list_empty(>free_vbufs))) {
> - spin_unlock(>free_vbufs_lock);
> - return;
> - }
> - vbuf = list_first_entry(>free_vbufs,
> - struct virtio_gpu_vbuffer, list);
> - list_del(>list);
> - }
> - spin_unlock(>free_vbufs_lock);
> - kfree(vgdev->vbufs);
> + kmem_cache_destroy(vgdev->vbufs);
> + vgdev->vbufs = NULL;
> }
>
> static struct virtio_gpu_vbuffer*
> @@ -128,12 +96,9 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device
> *vgdev)
> {
> struct virtio_gpu_vbuffer *vbuf;
>
> - spin_lock(>free_vbufs_lock);
> - BUG_ON(list_empty(>free_vbufs));
> - vbuf = list_first_entry(>free_vbufs,
> - struct virtio_gpu_vbuffer, list);
> - list_del(>list);
> - spin_unlock(>free_vbufs_lock);
> + vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL);
> + if (IS_ERR(vbuf))
> + return ERR_CAST(vbuf);
> memset(vbuf, 0, VBUFFER_SIZE);
>
> BUG_ON(size > MAX_INLINE_CMD_SIZE);
> @@ -208,9 +173,7 @@ static void free_vbuf(struct virtio_gpu_device *vgdev,
> if (vbuf->resp_size > MAX_INLINE_RESP_SIZE)
> kfree(vbuf->resp_buf);
> kfree(vbuf->data_buf);
> - spin_lock(>free_vbufs_lock);
> - list_add(>list, >free_vbufs);
> - spin_unlock(>free_vbufs_lock);
> + kmem_cache_free(vgdev->vbufs, vbuf);
> }
>
> static void reclaim_vbufs(struct virtqueue *vq, struct list_head
> *reclaim_list)
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
On Wed, Aug 09, 2017 at 04:13:05PM -0700, Joe Kniss wrote:
> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <nor...@tronnes.org> wrote:
> >
> > Den 09.08.2017 01.42, skrev Joe Kniss:
> >>
> >> Because all drivers currently use gem objects for framebuffer planes,
> >> the virtual create_handle() is not required. This change adds a
> >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> >> create_handle() function pointer from drm_framebuffer_funcs. The
> >> corresponding *_create_handle() function is removed from each driver.
> >>
> >> In many cases this change eliminates a struct *_framebuffer object,
> >> as the only need for the derived struct is the addition of the gem
> >> object pointer.
> >>
> >> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
> >>
> >> Signed-off-by: Joe Kniss <d...@google.com>
> >> ---
> >
> >
> > Hi Joe,
> >
> > I'm also looking into adding gem objs to drm_framebuffer in this patch:
> > [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> > https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
> >
>
> Great. There's only minimal overlap here. I'll rebase this change on yours
> once it's in.
Even better than waiting: Reviewing each another's patches. Noralf has
commit rights and knows how driver-wide refactoring works, so you're all
covered to get this landed, if you provide a bit of review for the review
market :-)
Cheers, Daniel
>
> > [...]
> >
> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> index ade319d10e70..f5f011b910b1 100644
> >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> @@ -31,14 +31,9 @@
> >> #define DEFAULT_FBDEFIO_DELAY_MS 50
> >> -struct drm_fb_cma {
> >> - struct drm_framebuffer fb;
> >> - struct drm_gem_cma_object *obj[4];
> >> -};
> >> -
> >> struct drm_fbdev_cma {
> >> struct drm_fb_helperfb_helper;
> >> - struct drm_fb_cma *fb;
> >> + struct drm_framebuffer *fb;
> >
> >
> > This fb pointer isn't necessary, since fb_helper already has one.
> >
>
> I'll remove it... but I am sure when I look deeper there will be more
> of these in the various drivers too.
>
> > Noralf.
> >
> >
>
> -joe
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 3/4] drm/qxl: Drop fbdev hwaccel flags
On Thu, Jul 06, 2017 at 02:57:34PM +0200, Daniel Vetter wrote: > It's not accelarated, just system memory. Note we don't even need to > set the default flag since that's now always 0. > > Cc: Dave Airlie <airl...@redhat.com> > Cc: Gerd Hoffmann <kra...@redhat.com> > Cc: virtualization@lists.linux-foundation.org > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Merged with Dave's irc-ack + commit message amended that qxl once had accel, but that was removed in 2015. -Daniel > --- > drivers/gpu/drm/qxl/qxl_fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c > index 573e7e9a5f98..69e7359b562a 100644 > --- a/drivers/gpu/drm/qxl/qxl_fb.c > +++ b/drivers/gpu/drm/qxl/qxl_fb.c > @@ -275,7 +275,7 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev, > > drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth); > > - info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA | > FBINFO_HWACCEL_FILLRECT; > + info->flags = FBINFO_DEFAULT; > info->fbops = _ops; > > /* > -- > 2.13.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms
It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Cc: Archit Taneja <arch...@codeaurora.org> Cc: Andrzej Hajda <a.ha...@samsung.com> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Cc: Peter Senna Tschudin <peter.se...@collabora.com> Cc: Martin Donnelly <martin.donne...@ge.com> Cc: Martyn Welch <martyn.we...@collabora.co.uk> Cc: Daniel Vetter <daniel.vet...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Sean Paul <seanp...@chromium.org> Cc: David Airlie <airl...@linux.ie> Cc: Inki Dae <inki@samsung.com> Cc: Joonyoung Shim <jy0922.s...@samsung.com> Cc: Seung-Woo Kim <sw0312@samsung.com> Cc: Kyungmin Park <kyungmin.p...@samsung.com> Cc: Kukjin Kim <kg...@kernel.org> Cc: Krzysztof Kozlowski <k...@kernel.org> Cc: Stefan Agner <ste...@agner.ch> Cc: Alison Wang <alison.w...@freescale.com> Cc: Russell King <li...@armlinux.org.uk> Cc: Philipp Zabel <p.za...@pengutronix.de> Cc: CK Hu <ck...@mediatek.com> Cc: Matthias Brugger <matthias@gmail.com> Cc: Neil Armstrong <narmstr...@baylibre.com> Cc: Carlo Caione <ca...@caione.org> Cc: Kevin Hilman <khil...@baylibre.com> Cc: Marek Vasut <ma...@denx.de> Cc: Ben Skeggs <bske...@redhat.com> Cc: Tomi Valkeinen <tomi.valkei...@ti.com> Cc: Eric Anholt <e...@anholt.net> Cc: Mark Yao <mark@rock-chips.com> Cc: Heiko Stuebner <he...@sntech.de> Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org> Cc: Vincent Abriou <vincent.abr...@st.com> Cc: Yannick Fertre <yannick.fer...@st.com> Cc: Philippe Cornu <philippe.co...@st.com> Cc: Maxime Ripard <maxime.rip...@free-electrons.com> Cc: Chen-Yu Tsai <w...@csie.org> Cc: Thierry Reding <thierry.red...@gmail.com> Cc: Jonathan Hunter <jonath...@nvidia.com> Cc: Jyri Sarha <jsa...@ti.com> Cc: Gerd Hoffmann <kra...@redhat.com> Cc: Shawn Guo <shawn...@kernel.org> Cc: John Stultz <john.stu...@linaro.org> Cc: Lars-Peter Clausen <l...@metafoo.de> Cc: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> Cc: Jeffy Chen <jeffy.c...@rock-chips.com> Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> Cc: Yakir Yang <kuankua...@gmail.com> Cc: Marek Szyprowski <m.szyprow...@samsung.com> Cc: Jose Abreu <jose.ab...@synopsys.com> Cc: Romain Perier <romain.per...@collabora.com> Cc: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> Cc: Xinliang Liu <z.liuxinli...@hisilicon.com> Cc: Alexey Brodkin <abrod...@synopsys.com> Cc: Alex Deucher <alexander.deuc...@amd.com> Cc: Rongrong Zou <zourongr...@gmail.com> Cc: Rob Clark <robdcl...@gmail.com> Cc: Hai Li <h...@codeaurora.org> Cc: "Noralf Trønnes" <nor...@tronnes.org> Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: nouv...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-te...@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: zain wang <w...@rock-chips.com> Cc: Baoyou Xie <baoyou@linaro.org> Cc: Boris Brezillon <boris.brezil...@free-electrons.com> --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 - drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 - drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 - drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 - .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 1 - drivers/gpu/drm/bridge/nxp-ptn3460.c | 1 - drivers/gpu/drm/bridge/panel.c | 1 - drivers/gpu/drm/bridge/parade-ps8622.c | 1 - drivers/gpu/drm/bridge/sii902x.c | 1 - drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 - drivers/gpu/drm/bridge/tc358767.c | 1 - drivers/gpu/drm/bridge/ti-tfp410.c | 1 - drivers/gpu/drm/drm_atomic_helper.c| 79 -- drivers/gpu/drm/exynos/exynos_drm_dpi.c| 1 - drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1 - drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 - drivers/gpu/drm/exynos/exynos_hdmi.c | 1 - drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 1 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 1 - drivers/gpu/drm/i2c/tda998x_drv.c | 10 +-- drivers/gpu/drm/i915/intel_crt.c
Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper
rv.h | 1 - > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_fbdev.c | 31 - > drivers/gpu/drm/mgag200/mgag200_drv.h | 5 - > drivers/gpu/drm/mgag200/mgag200_fb.c| 2 - > drivers/gpu/drm/mgag200/mgag200_mode.c | 64 +++-- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28 ++-- > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 22 > drivers/gpu/drm/nouveau/nv50_display.c | 42 ++ > drivers/gpu/drm/radeon/atombios_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_connectors.c | 7 +- > drivers/gpu/drm/radeon/radeon_display.c | 73 +-- > drivers/gpu/drm/radeon/radeon_fb.c | 2 - > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_mode.h| 4 - > drivers/gpu/drm/stm/ltdc.c | 12 -- > drivers/gpu/drm/stm/ltdc.h | 1 - > drivers/gpu/drm/vc4/vc4_crtc.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +- > include/drm/drm_atomic_helper.h | 2 +- > include/drm/drm_crtc.h | 11 +- > include/drm/drm_fb_helper.h | 32 - > include/drm/drm_modeset_helper_vtables.h| 16 --- > 48 files changed, 301 insertions(+), 702 deletions(-) > > -- > 2.1.4 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 3/4] drm/qxl: Drop fbdev hwaccel flags
It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Cc: Dave Airlie <airl...@redhat.com> Cc: Gerd Hoffmann <kra...@redhat.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index 573e7e9a5f98..69e7359b562a 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -275,7 +275,7 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev, drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth); - info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT; + info->flags = FBINFO_DEFAULT; info->fbops = _ops; /* -- 2.13.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper
On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote: > On 2017-07-05 08:08, Daniel Vetter wrote: > > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: > >> Hi! > >> > >> While trying to get CLUT support for the atmel_hlcdc driver, and > >> specifically for the emulated fbdev interface, I received some > >> push-back that my feeble in-driver attempts should be solved > >> by the core. This is my attempt to do it right. > >> > >> I have obviously not tested all of this with more than a compile, > >> but patches 1 through 5 are enough to make the atmel-hlcdc driver > >> do what I need. The rest is just lots of removals and cleanup made > >> possible by the improved core. > >> > >> Please test, I would not be surprised if I have fouled up some > >> bit-manipulation somewhere, or if I have misunderstood something > >> about atomics... > >> > >> Changes since v2: > >> - Added patch 1/16 which factors out pseudo-palette handling. > >> - Removed the if (cmap->start + cmap->len < cmap->start) > >> sanity check on the assumption that the fbdev core handles it. > >> - Added patch 4/16 which factors out atomic state and commit > >> handling from drm_atomic_helper_legacy_gamma_set to > >> drm_mode_gamma_set_ioctl. > >> - Do one atomic commit for all affected crtc. > >> - Removed a now obsolete note in include/drm/drm_crtc.h (ammended > >> the last patch). > >> - Cc list is getting long, so I have redused the list for the > >> individual patches. If you would like to get the full series > >> (or nothing at all) for the next round (if that is needed) just > >> say so. > > > > Is this still on top of my locking rework? I tried to apply patches 1-3, > > but there's minor conflicts ... > > -Daniel > > v3 has the same base as v2. I collected your locking rework sometime > after june 21, you have perhaps changed things since? I saw an update > of that dpms patch you Cc me, but figured there were no significant > changes that I needed to handle since I didn't get the full set > this time either. A bad assumption it seems... There's a difference between my own private patches, and the maintainer repo where stuff gets applied. But that explains why there was a conflict. I plan to merge my locking changes tomorrow (they're reviewed and ready now), I'll apply your patches after that. That should take care of the conflicts. Thanks, Daniel > > Anyway, the base I have for v3 (and v2) is linux next-20170621 plus > the following locking rework commits (in reverse order): > > Author: Thierry Reding <tred...@nvidia.com> > Date: Wed Jun 21 20:28:15 2017 +0200 > Subject: drm/hisilicon: Remove custom FB helper deferred setup > > Author: Thierry Reding <tred...@nvidia.com> > Date: Wed Jun 21 20:28:14 2017 +0200 > Subject: drm/exynos: Remove custom FB helper deferred setup > > Author: Thierry Reding <tred...@nvidia.com> > Date: Wed Jun 21 20:28:13 2017 +0200 > Subject: drm/fb-helper: Support deferred setup > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:12 2017 +0200 > Subject: drm/fb-helper: Split dpms handling into legacy and atomic paths > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:11 2017 +0200 > Subject: drm/fb-helper: Stop using mode_config.mutex for internals > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:10 2017 +0200 > Subject: drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:09 2017 +0200 > Subject: drm/fb-helper: Push locking into pan_display_atomic|legacy > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:08 2017 +0200 > Subject: drm/fb-helper: Drop locking from the vsync wait ioctl code > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:07 2017 +0200 > Subject: drm/fb-helper: Push locking in fb_is_bound > > Author: Thierry Reding <tred...@nvidia.com> > Date: Wed Jun 21 20:28:06 2017 +0200 > Subject: drm/fb-helper: Add top-level lock > > Author: Daniel Vetter <daniel.vet...@ffwll.ch> > Date: Wed Jun 21 20:28:05 2017 +0200 > Subject: drm/i915: Drop FBDEV #ifdev in mst code > > Author: Thierry Reding <tred...@nvidia.com> > Date: Wed Jun 21 20:28:04 2017 +0200 > Subject: drm/fb-helper: Push down modeset lock into FB helpers > > Cheers, > peda > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/virtio: make drm_fb_helper_funcs const
On Tue, Aug 08, 2017 at 08:44:05PM +0530, Bhumika Goyal wrote:
> Make these structures const as they are only passed to the function
> drm_fb_helper_prepare and the corresponding argument is of type const.
> Done using Coccinelle
>
> @match disable optional_qualifier@
> identifier s;
> @@
> static struct drm_fb_helper_funcs s = {...};
>
> @ref@
> position p;
> identifier match.s;
> @@
> s@p
>
> @good1@
> identifier match.s;
> expression e1,e2;
> position ref.p;
> @@
> drm_fb_helper_prepare(e1,e2,@p,...)
>
> @bad depends on !good1@
> position ref.p;
> identifier match.s;
> @@
> s@p
>
> @depends on forall !bad disable optional_qualifier@
> identifier match.s;
> @@
> static
> + const
> struct drm_fb_helper_funcs s;
>
> Signed-off-by: Bhumika Goyal <bhumi...@gmail.com>
This and the previous one merged too.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
> b/drivers/gpu/drm/virtio/virtgpu_fb.c
> index 046e28b..15d18fd 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fb.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
> @@ -308,7 +308,7 @@ static int virtio_gpu_fbdev_destroy(struct drm_device
> *dev,
>
> return 0;
> }
> -static struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
> .fb_probe = virtio_gpufb_create,
> };
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 02/37] drm: Remove drm_device->virtdev
This is a leftover from the drm_bus days, where we've had a
bus-specific device type for every bus type in drm_device. Except for
pci (which we can't remove because dri1 drivers) this is all gone. And
the virt driver also doesn't really need it, dev_to_virtio works
perfectly fine.
Cc: David Airlie <airl...@linux.ie>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 1 -
drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++--
include/drm/drmP.h | 2 --
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
index 43e1d5916c6c..7df8d0c9026a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
@@ -56,7 +56,6 @@ int drm_virtio_init(struct drm_driver *driver, struct
virtio_device *vdev)
dev = drm_dev_alloc(driver, >dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
- dev->virtdev = vdev;
vdev->priv = dev;
if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 1e1c90b30d4a..6400506a06b0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -138,7 +138,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned
long flags)
u32 num_scanouts, num_capsets;
int ret;
- if (!virtio_has_feature(dev->virtdev, VIRTIO_F_VERSION_1))
+ if (!virtio_has_feature(dev_to_virtio(dev->dev), VIRTIO_F_VERSION_1))
return -ENODEV;
vgdev = kzalloc(sizeof(struct virtio_gpu_device), GFP_KERNEL);
@@ -147,7 +147,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned
long flags)
vgdev->ddev = dev;
dev->dev_private = vgdev;
- vgdev->vdev = dev->virtdev;
+ vgdev->vdev = dev_to_virtio(dev->dev);
vgdev->dev = dev->dev;
spin_lock_init(>display_info_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 575b29b47811..c363f2fdff31 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -412,8 +412,6 @@ struct drm_device {
struct pci_controller *hose;
#endif
- struct virtio_device *virtdev;
-
struct drm_sg_mem *sg; /**< Scatter gather memory */
unsigned int num_crtcs; /**< Number of CRTCs on this
device */
--
2.11.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/11] improve the fb_setcmap helper
On Tue, Jun 20, 2017 at 09:25:24PM +0200, Peter Rosin wrote: > Hi! > > While trying to get CLUT support for the atmel_hlcdc driver, and > specifically for the emulated fbdev interface, I received some > push-back that my feeble in-driver attempts should be solved > by the core. This is my attempt to do it right. > > Boris and Daniel, was this approximately what you had in mind? Yeah, this is awesome. I tried to do it a few times myself, but always failed (also due to lack of real use-case on my side). > I have obviously not tested all of this with more than a compile, > but the first patch is enough to make the atmel-hlcdc driver > do what I need. The rest is just lots of removals and cleanup > made possible by the improved core. If it works for you it's imo good enough. Not sure anyone else really cares about fbdev lut support at all. I have a few comments on the first patch, but once that's sorted, and once we have given driver maintainers enough time to ack I think I'll merge the entire pile into drm-misc. Nice work, thanks for doing it. Cheers, Daniel > Please test, I would not be surprised if I have fouled up some > bit-manipulation somewhere in this mostly mechanical change... > > Cheers, > peda > > Peter Rosin (11): > drm/fb-helper: do a generic fb_setcmap helper in terms of crtc > .gamma_set > drm: amd: remove dead code and pointless local lut storage > drm: ast: remove dead code and pointless local lut storage > drm: cirrus: remove dead code and pointless local lut storage > dmr: gma500: remove dead code and pointless local lut storage > drm: i915: remove dead code and pointless local lut storage > drm: mgag200: remove dead code and pointless local lut storage > drm: nouveau: remove dead code and pointless local lut storage > drm: radeon: remove dead code and pointless local lut storage > drm: stm: remove dead code and pointless local lut storage > drm: remove unused and redundant callbacks > > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24 - > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 - > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_virtual.c| 23 - > drivers/gpu/drm/ast/ast_drv.h | 1 - > drivers/gpu/drm/ast/ast_fb.c| 20 - > drivers/gpu/drm/ast/ast_mode.c | 26 ++ > drivers/gpu/drm/cirrus/cirrus_drv.h | 8 -- > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 - > drivers/gpu/drm/cirrus/cirrus_mode.c| 71 --- > drivers/gpu/drm/drm_fb_helper.c | 131 > +--- > drivers/gpu/drm/gma500/framebuffer.c| 22 - > drivers/gpu/drm/gma500/gma_display.c| 32 +++ > drivers/gpu/drm/gma500/psb_intel_display.c | 7 +- > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 - > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_fbdev.c | 31 --- > drivers/gpu/drm/mgag200/mgag200_drv.h | 5 -- > drivers/gpu/drm/mgag200/mgag200_fb.c| 2 - > drivers/gpu/drm/mgag200/mgag200_mode.c | 62 - > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++ > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 22 - > drivers/gpu/drm/nouveau/nv50_display.c | 39 +++-- > drivers/gpu/drm/radeon/atombios_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_connectors.c | 7 +- > drivers/gpu/drm/radeon/radeon_display.c | 71 ++- > drivers/gpu/drm/radeon/radeon_fb.c | 2 - > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 - > drivers/gpu/drm/stm/ltdc.c | 12 --- > drivers/gpu/drm/stm/ltdc.h | 1 - > include/drm/drm_fb_helper.h | 32 --- > include/drm/drm_modeset_helper_vtables.h| 16 > 36 files changed, 171 insertions(+), 640 deletions(-) > > -- > 2.1.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
rm_fb_helper_setcmap - implementation for _ops.fb_setcmap
> * @cmap: cmap to set
> @@ -1220,51 +1159,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
> struct fb_info *info)
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> + struct drm_modeset_acquire_ctx ctx;
> struct drm_crtc *crtc;
> - int i, j, rc = 0;
> - int start;
> + u16 *r, *g, *b;
> + int i, ret;
>
> if (oops_in_progress)
> return -EBUSY;
>
> - drm_modeset_lock_all(dev);
> + if (cmap->start + cmap->len < cmap->start)
> + return -EINVAL;
> +
> + drm_modeset_acquire_init(, 0);
> +retry:
> + ret = drm_modeset_lock_all_ctx(dev, );
> + if (ret)
> + goto out;
> if (!drm_fb_helper_is_bound(fb_helper)) {
> - drm_modeset_unlock_all(dev);
> - return -EBUSY;
> + ret = -EBUSY;
> + goto out;
> }
>
> for (i = 0; i < fb_helper->crtc_count; i++) {
> crtc = fb_helper->crtc_info[i].mode_set.crtc;
> - crtc_funcs = crtc->helper_private;
> -
> - red = cmap->red;
> - green = cmap->green;
> - blue = cmap->blue;
> - transp = cmap->transp;
> - start = cmap->start;
> + if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> - for (j = 0; j < cmap->len; j++) {
> - u16 hred, hgreen, hblue, htransp = 0x;
> + if (cmap->start + cmap->len > crtc->gamma_size) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> - hred = *red++;
> - hgreen = *green++;
> - hblue = *blue++;
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
>
> - if (transp)
> - htransp = *transp++;
> + memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(u16));
> + memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(u16));
> + memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(u16));
>
> - rc = setcolreg(crtc, hred, hgreen, hblue, start++,
> info);
> - if (rc)
> - goto out;
> - }
> - if (crtc_funcs->load_lut)
> - crtc_funcs->load_lut(crtc);
> + ret = crtc->funcs->gamma_set(crtc, r, g, b,
> + crtc->gamma_size, );
> + if (ret)
> + break;
> }
> - out:
> - drm_modeset_unlock_all(dev);
> - return rc;
> +out:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + }
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
It's a pre-existing bug, but should we also try to restore the fbdev lut
in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
but might be relevant for your use-case. Just try to run both an fbdev
application and some kms-native thing, and then SIGKILL the native kms
app.
But since pre-existing not really required, and probably too much effort.
Thanks, Daniel
> }
> EXPORT_SYMBOL(drm_fb_helper_setcmap);
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
> On 21/06/17 04:38 PM, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obsolete.
> >>
> >> I think the gamma_store can end up invalid on error. But the way I read
> >> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> >> this pesky legacy fbdev stuff be any better?
> >>
> >> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
> >> it saves it to the gamma_store which should already be up to date with what
> >> .gamma_get would return and is thus a nop. So, zap it.
> >
> > Removing drm_fb_helper_save_lut_atomic should be a separate patch I
> > think.
> >
> >> Signed-off-by: Peter Rosin <p...@axentia.se>
>
> [...]
>
> >> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
> >> drm_fb_helper *fb_helper,
> >> }
> >> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
> >>
> >> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> >> - u16 blue, u16 regno, struct fb_info *info)
> >> -{
> >> - struct drm_fb_helper *fb_helper = info->par;
> >> - struct drm_framebuffer *fb = fb_helper->fb;
> >> -
> >> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> >
> > This case here seems gone, and it was also the pièce de résistance when I
> > tried tackling fbdev lut support. As far as I understand this stuff we do
> > not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
> > pointless. But I'm honestly not really clear.
> >
> > I think removing this case should also be a separate patch, and I'd very
> > much prefer that someone with some fbdev-clue would ack it.
>
> No need for anyone with fbdev-clue, just run fbset -i. :) fbcon uses a
> TRUECOLOR visual at depths > 8.
Then I understand even less what exactly this code does ... Should we keep
it? Is it just pure cargo-cult? Only needed when we'd change the color
depth of the fbdev buffer, which we never do at runtime?
> > It's a pre-existing bug, but should we also try to restore the fbdev lut
> > in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
> > but might be relevant for your use-case. Just try to run both an fbdev
> > application and some kms-native thing, and then SIGKILL the native kms
> > app.
> >
> > But since pre-existing not really required, and probably too much effort.
>
> I suspect something like that indeed needs to be done though. E.g.
> killing Xorg results in fbcon continuing to use the LUT set by Xorg.
Ok, the only trouble with that is atomic kms locking, which requires that
we can only do 1 commit per lock-holding time, and also
drm_modeset_lock_all is an evil hack and needs to be phased out. Two
solutions:
- We just update the lut after we've dropped the locks again in
restore_fbdev_mode.
- We need both a legacy path, in restore_fbdev_mode_legacy, and an atomic
path in restore_fbdev_mode_atomic. The latter cannot use the gamme_set
callback, since that would call drm_atomic_helper_legacy_gamma_set for
atomic drivers, which would result in two calls to drm_atomic_commit in
one critical sections. Instead that needs to open-code the logic in
drm_atomic_helper_legacy_gamma_set and integrate it into the overall
fbdev restore commit.
The 2nd option is a bit more typing, but much cleaner. It also fits better
into some of the refactoring plans I have (I want to get rid of
drm_modeset_lock_all in the fbdev emulation). And has the benefit of
giving drivers a bit more complex fbdev emulation atomic commits, which
would be good for testing I think.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote: > On 2017-06-21 09:38, Daniel Vetter wrote: > > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: > >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get > >> totally obsolete. > >> > >> I think the gamma_store can end up invalid on error. But the way I read > >> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should > >> this pesky legacy fbdev stuff be any better? > >> > >> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However, > >> it saves it to the gamma_store which should already be up to date with what > >> .gamma_get would return and is thus a nop. So, zap it. > > > > Removing drm_fb_helper_save_lut_atomic should be a separate patch I > > think. > > Then 3 patches would be needed, first some hybrid thing that does it the > old way, but also stores the lut in .gamma_store, then the split-out that > removes drm_fb_helper_save_lut_atomic, then whatever is needed to get > to the desired code. I can certainly do that, but do you want me to? Explain that in the commit message and it's fine. > > It's a pre-existing bug, but should we also try to restore the fbdev lut > > in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug, > > but might be relevant for your use-case. Just try to run both an fbdev > > application and some kms-native thing, and then SIGKILL the native kms > > app. > > > > But since pre-existing not really required, and probably too much effort. > > Good thing too, because I don't really know my way around this code... Btw I cc'ed you on one of my patches in the fbdev locking series, we might need to do the same legacy vs. atomic split for the new lut code as I did for dpms. The rule with atomic is that you can't do multiple commits under drm_modeset_lock_all, you either have to do one overall atomic commit (preferred) or drop locks again. This matters for LUT since you're updating the LUT on all CRTCs, which when using the gamma_set atomic helper would be multiple commits :-/ Using the dpms patch as template it shouldn't be too hard to address that for your patch here too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 11/11] drm: remove unused and redundant callbacks
On Thu, Jun 22, 2017 at 12:34:36AM +0800, kbuild test robot wrote:
> Hi Peter,
>
> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on next-20170621]
> [cannot apply to v4.12-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Peter-Rosin/improve-the-fb_setcmap-helper/20170621-205441
> base: git://people.freedesktop.org/~airlied/linux.git drm-next
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
> >> drivers/gpu//drm/armada/armada_fbdev.c:121:2: error: unknown field
> >> 'gamma_set' specified in initializer
> .gamma_set = armada_drm_crtc_gamma_set,
Looks like you've missed at least the armada driver in your conversion?
-Daniel
> ^
> >> drivers/gpu//drm/armada/armada_fbdev.c:121:15: error: initialization from
> >> incompatible pointer type [-Werror=incompatible-pointer-types]
> .gamma_set = armada_drm_crtc_gamma_set,
> ^
>drivers/gpu//drm/armada/armada_fbdev.c:121:15: note: (near initialization
> for 'armada_fb_helper_funcs.fb_probe')
> >> drivers/gpu//drm/armada/armada_fbdev.c:122:2: error: unknown field
> >> 'gamma_get' specified in initializer
> .gamma_get = armada_drm_crtc_gamma_get,
> ^
>drivers/gpu//drm/armada/armada_fbdev.c:122:15: error: initialization from
> incompatible pointer type [-Werror=incompatible-pointer-types]
> .gamma_get = armada_drm_crtc_gamma_get,
> ^
>drivers/gpu//drm/armada/armada_fbdev.c:122:15: note: (near initialization
> for 'armada_fb_helper_funcs.initial_config')
>cc1: some warnings being treated as errors
>
> vim +/gamma_set +121 drivers/gpu//drm/armada/armada_fbdev.c
>
> 96f60e37 Russell King 2012-08-15 115 ret = 1;
> 96f60e37 Russell King 2012-08-15 116 }
> 96f60e37 Russell King 2012-08-15 117 return ret;
> 96f60e37 Russell King 2012-08-15 118 }
> 96f60e37 Russell King 2012-08-15 119
> 3a493879 Thierry Reding 2014-06-27 120 static const struct
> drm_fb_helper_funcs armada_fb_helper_funcs = {
> 96f60e37 Russell King 2012-08-15 @121 .gamma_set =
> armada_drm_crtc_gamma_set,
> 96f60e37 Russell King 2012-08-15 @122 .gamma_get =
> armada_drm_crtc_gamma_get,
> 96f60e37 Russell King 2012-08-15 123 .fb_probe =
> armada_fb_probe,
> 96f60e37 Russell King 2012-08-15 124 };
> 96f60e37 Russell King 2012-08-15 125
>
> :: The code at line 121 was first introduced by commit
> :: 96f60e37dc66091bde8d5de136ff6fda09f2d799 DRM: Armada: Add Armada DRM
> driver
>
> :: TO: Russell King <rmk+ker...@arm.linux.org.uk>
> :: CC: Russell King <rmk+ker...@arm.linux.org.uk>
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 02/14] drm/fb-helper: remove drm_fb_helper_save_lut_atomic
On Thu, Jun 22, 2017 at 08:06:25AM +0200, Peter Rosin wrote:
> drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
> now always kept up to date by drm_fb_helper_setcmap.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
Also note that this is for kgdb support only and so likely very buggy
(since no one cried when we started to break kgdb support when switching
drivers to atomic).
-Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 25315fb..7ade384 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -229,22 +229,6 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
> }
> EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
>
> -static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct
> drm_fb_helper *helper)
> -{
> - uint16_t *r_base, *g_base, *b_base;
> - int i;
> -
> - if (helper->funcs->gamma_get == NULL)
> - return;
> -
> - r_base = crtc->gamma_store;
> - g_base = r_base + crtc->gamma_size;
> - b_base = g_base + crtc->gamma_size;
> -
> - for (i = 0; i < crtc->gamma_size; i++)
> - helper->funcs->gamma_get(crtc, _base[i], _base[i],
> _base[i], i);
> -}
> -
> static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
> {
> uint16_t *r_base, *g_base, *b_base;
> @@ -285,7 +269,6 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
> if (drm_drv_uses_atomic_modeset(mode_set->crtc->dev))
> continue;
>
> - drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
> funcs->mode_set_base_atomic(mode_set->crtc,
> mode_set->fb,
> mode_set->x,
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
- rc = -EINVAL;
> - goto out;
> + palette = (u32 *)info->pseudo_palette;
> + for (j = 0; j < cmap->len; ++j) {
> + u16 red = cmap->red[j];
> + u16 green = cmap->green[j];
> + u16 blue = cmap->blue[j];
> + u32 value;
> +
> + red >>= 16 - info->var.red.length;
> + green >>= 16 - info->var.green.length;
> + blue >>= 16 - info->var.blue.length;
> + value = (red << info->var.red.offset) |
> + (green << info->var.green.offset) |
> + (blue << info->var.blue.offset);
> + if (info->var.transp.length > 0) {
> + u32 mask = (1 <<
> info->var.transp.length) - 1;
> +
> + mask <<= info->var.transp.offset;
> + value |= mask;
> + }
> + palette[cmap->start + j] = value;
> }
> + continue;
I think it'd be much cleaner if we handle the TRUECOLOR case as an early
return, before the crtc loop. Per-crtc is only needed when we have to
update the hw table (i.e. PSEUDOCOLOR stuff).
> + }
>
> - r = crtc->gamma_store;
> - g = r + crtc->gamma_size;
> - b = g + crtc->gamma_size;
> -
> - memcpy(r + cmap->start, cmap->red,
> -cmap->len * sizeof(u16));
> - memcpy(g + cmap->start, cmap->green,
> -cmap->len * sizeof(u16));
> - memcpy(b + cmap->start, cmap->blue,
> -cmap->len * sizeof(u16));
> + crtc = fb_helper->crtc_info[i].mode_set.crtc;
> + if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
> + ret = -EINVAL;
> + goto out;
> }
>
> - for (j = 0; j < cmap->len; j++) {
> - u16 hred, hgreen, hblue, htransp = 0x;
> + if (cmap->start + cmap->len > crtc->gamma_size) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> - hred = *red++;
> - hgreen = *green++;
> - hblue = *blue++;
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
>
> - if (transp)
> - htransp = *transp++;
> + memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(u16));
> + memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(u16));
> + memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(u16));
>
> - rc = setcolreg(crtc, hred, hgreen, hblue, start++,
> info);
> - if (rc)
> - goto out;
> - }
> - if (crtc_funcs->load_lut)
> - crtc_funcs->load_lut(crtc);
> + ret = crtc->funcs->gamma_set(crtc, r, g, b,
> + crtc->gamma_size, );
As discussed on earlier threads, I think the cleanest version here would
be 2 functions, one which does the crtc-loop like in your code here for
legacy drivers, and the 2nd one which does 1 atomic commit over all crtcs,
open-coding the gamma_set helper. For the legacy one you can also keep
using drm_modeset_lock_all if you want too.
And this will be all a bit easier on top of my branch, since then you can
untangle fbdev locking from the kms side better.
-Daniel
> + if (ret)
> + break;
> }
> - out:
> - drm_modeset_unlock_all(dev);
> - return rc;
> +out:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + }
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_fb_helper_setcmap);
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 01/14] drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap
On Thu, Jun 22, 2017 at 08:06:24AM +0200, Peter Rosin wrote:
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> this pesky legacy fbdev stuff be any better?
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
> ---
> drivers/gpu/drm/drm_fb_helper.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01..25315fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1223,12 +1223,16 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
> struct fb_info *info)
> const struct drm_crtc_helper_funcs *crtc_funcs;
> u16 *red, *green, *blue, *transp;
> struct drm_crtc *crtc;
> + u16 *r, *g, *b;
> int i, j, rc = 0;
> int start;
>
> if (oops_in_progress)
> return -EBUSY;
>
> + if (cmap->start + cmap->len < cmap->start)
> + return -EINVAL;
Doesn't the fbdev core check this for us?
> +
> drm_modeset_lock_all(dev);
> if (!drm_fb_helper_is_bound(fb_helper)) {
> drm_modeset_unlock_all(dev);
> @@ -1245,6 +1249,29 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
> fb_info *info)
> transp = cmap->transp;
> start = cmap->start;
>
> + if (info->fix.visual != FB_VISUAL_TRUECOLOR) {
I think switching to a positive check of visual == PSEUDOCOLOR is a bit
clearer. Also this makes more sense once we move over to the main
gamma_set function, since as-is it's unclear that setcolreg only does
something for PSEUDOCOLOR. But interim I guess that's ok.
-Daniel
> + if (!crtc->gamma_size) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + if (cmap->start + cmap->len > crtc->gamma_size) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
> +
> + memcpy(r + cmap->start, cmap->red,
> +cmap->len * sizeof(u16));
> + memcpy(g + cmap->start, cmap->green,
> +cmap->len * sizeof(u16));
> + memcpy(b + cmap->start, cmap->blue,
> +cmap->len * sizeof(u16));
> + }
> +
> for (j = 0; j < cmap->len; j++) {
> u16 hred, hgreen, hblue, htransp = 0x;
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/14] improve the fb_setcmap helper
/gpu/drm/radeon/radeon_connectors.c | 7 +- > drivers/gpu/drm/radeon/radeon_display.c | 71 +--- > drivers/gpu/drm/radeon/radeon_fb.c | 2 - > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_mode.h| 4 - > drivers/gpu/drm/stm/ltdc.c | 12 -- > drivers/gpu/drm/stm/ltdc.h | 1 - > include/drm/drm_fb_helper.h | 32 -- > include/drm/drm_modeset_helper_vtables.h| 16 --- > 40 files changed, 205 insertions(+), 658 deletions(-) > > -- > 2.1.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
gt;start + cmap->len > 16) {
> + ret = -EINVAL;
> + break;
> }
>
> - if (cmap->start + cmap->len > crtc->gamma_size) {
> - rc = -EINVAL;
> - goto out;
> + palette = (u32 *)info->pseudo_palette;
> + for (j = 0; j < cmap->len; ++j) {
> + u16 red = cmap->red[j];
> + u16 green = cmap->green[j];
> + u16 blue = cmap->blue[j];
> + u32 value;
> +
> + red >>= 16 - info->var.red.length;
> + green >>= 16 - info->var.green.length;
> + blue >>= 16 - info->var.blue.length;
> + value = (red << info->var.red.offset) |
> + (green << info->var.green.offset) |
> + (blue << info->var.blue.offset);
> + if (info->var.transp.length > 0) {
> + u32 mask = (1 <<
> info->var.transp.length) - 1;
> +
> + mask <<= info->var.transp.offset;
> + value |= mask;
> + }
> + palette[cmap->start + j] = value;
> }
> + continue;
> + }
>
> - r = crtc->gamma_store;
> - g = r + crtc->gamma_size;
> - b = g + crtc->gamma_size;
> +retry:
> + ret = drm_modeset_lock_all_ctx(dev, );
> + if (ret)
> + break;
>
> - memcpy(r + cmap->start, cmap->red,
> -cmap->len * sizeof(u16));
> - memcpy(g + cmap->start, cmap->green,
> -cmap->len * sizeof(u16));
> - memcpy(b + cmap->start, cmap->blue,
> -cmap->len * sizeof(u16));
> + crtc = fb_helper->crtc_info[i].mode_set.crtc;
> + if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
> + ret = -EINVAL;
> + goto drop_locks;
> }
>
> - for (j = 0; j < cmap->len; j++) {
> - u16 hred, hgreen, hblue, htransp = 0x;
> + if (cmap->start + cmap->len > crtc->gamma_size) {
> + ret = -EINVAL;
> + goto drop_locks;
> + }
>
> - hred = *red++;
> - hgreen = *green++;
> - hblue = *blue++;
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
>
> - if (transp)
> - htransp = *transp++;
> + memcpy(r + cmap->start, cmap->red, cmap->len * sizeof(u16));
> + memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(u16));
> + memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(u16));
>
> - rc = setcolreg(crtc, hred, hgreen, hblue, start++,
> info);
> - if (rc)
> - goto out;
> + ret = crtc->funcs->gamma_set(crtc, r, g, b,
> + crtc->gamma_size, );
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> }
> - if (crtc_funcs->load_lut)
> - crtc_funcs->load_lut(crtc);
> +drop_locks:
> + drm_modeset_drop_locks();
This doesn't work, you can't reuse the acquire_ctx (that's the bit where
the locking machinery gets mad at you). Simplest way really is 2 paths,
one legacy (using drm_modeset_lock_all), the other atomic (with the
gamma_set helper logic inlined, but as one global atomic commit).
I guess updating the gamma_store could be done with common code again, on
success only (another reason for atomic, that way you get all or nothing,
makes error handling easier).
-Daniel
> + if (ret)
> + break;
> }
> - out:
> - drm_modeset_unlock_all(dev);
> +
> + drm_modeset_acquire_fini();
> mutex_unlock(_helper->lock);
> - return rc;
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_fb_helper_setcmap);
>
> --
> 2.1.4
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage
On Thu, Jun 22, 2017 at 11:49:34AM +, Philippe CORNU wrote:
>
>
> On 06/22/2017 08:06 AM, Peter Rosin wrote:
> > The redundant fb helper .load_lut is no longer used, and can not
> > work right without also providing the fb helpers .gamma_set and
> > .gamma_get thus rendering the code in this driver suspect.
> >
>
> Hi Peter,
> STM32 chipsets supports 8-bit CLUT mode but this driver version does not
> support it "yet" (final patch has not been upstreamed because it was a
> too big fbdev patch for simply adding CLUT...).
>
> Regarding your patch below, if it helps you to ease the drm framework
> update then I am agree to "acknowledge it" asap, else if you are not in
> a hurry, I would prefer a better and definitive patch handling 8-bit
> CLUT properly and I am ok to help or/and to do it : )
I'll take your ack, since your 8bit lut support will be massively simpler
with Peter's series here :-)
> Extra questions:
> - any plan to update modetest with the DRM_FORMAT_C8 support + gamma
> get/set?
We have gamma igts, well for the fancy new atomic color manager stuff.
Testing drivers with modetest is kinda not that awesome :-)
-Daniel
> - do you have a simple way to test clut with fbdev, last year we where
> using an old version of the SDL but I am still looking for a small piece
> of code to do it (else I will do it myself but C8 on fbdev is not really
> a priority ;-)
>
> best regards,
> Philippe
>
> > Just remove the dead code.
> >
> > Signed-off-by: Peter Rosin <p...@axentia.se>
> > ---
> > drivers/gpu/drm/stm/ltdc.c | 12
> > drivers/gpu/drm/stm/ltdc.h | 1 -
> > 2 files changed, 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> > index 1b9483d..87829b9 100644
> > --- a/drivers/gpu/drm/stm/ltdc.c
> > +++ b/drivers/gpu/drm/stm/ltdc.c
> > @@ -375,17 +375,6 @@ static irqreturn_t ltdc_irq(int irq, void *arg)
> >* DRM_CRTC
> >*/
> >
> > -static void ltdc_crtc_load_lut(struct drm_crtc *crtc)
> > -{
> > - struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > - unsigned int i, lay;
> > -
> > - for (lay = 0; lay < ldev->caps.nb_layers; lay++)
> > - for (i = 0; i < 256; i++)
> > - reg_write(ldev->regs, LTDC_L1CLUTWR + lay * LAY_OFS,
> > - ldev->clut[i]);
> > -}
> > -
> > static void ltdc_crtc_enable(struct drm_crtc *crtc)
> > {
> > struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > @@ -523,7 +512,6 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > }
> >
> > static struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> > - .load_lut = ltdc_crtc_load_lut,
> > .enable = ltdc_crtc_enable,
> > .disable = ltdc_crtc_disable,
> > .mode_set_nofb = ltdc_crtc_mode_set_nofb,
> > diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> > index d7a9c73..620ca55 100644
> > --- a/drivers/gpu/drm/stm/ltdc.h
> > +++ b/drivers/gpu/drm/stm/ltdc.h
> > @@ -27,7 +27,6 @@ struct ltdc_device {
> > struct drm_panel *panel;
> > struct mutex err_lock; /* protecting error_status */
> > struct ltdc_caps caps;
> > - u32 clut[256]; /* color look up table */
> > u32 error_status;
> > u32 irq_status;
> > };
> >
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On Thu, Jun 22, 2017 at 10:48:10AM +0200, Peter Rosin wrote: > On 2017-06-22 08:36, Daniel Vetter wrote: > > On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote: > >> On 2017-06-21 09:38, Daniel Vetter wrote: > >>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: > >>>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get > >>>> totally obsolete. > >>>> > >>>> I think the gamma_store can end up invalid on error. But the way I read > >>>> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should > >>>> this pesky legacy fbdev stuff be any better? > >>>> > >>>> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. > >>>> However, > >>>> it saves it to the gamma_store which should already be up to date with > >>>> what > >>>> .gamma_get would return and is thus a nop. So, zap it. > >>> > >>> Removing drm_fb_helper_save_lut_atomic should be a separate patch I > >>> think. > >> > >> Then 3 patches would be needed, first some hybrid thing that does it the > >> old way, but also stores the lut in .gamma_store, then the split-out that > >> removes drm_fb_helper_save_lut_atomic, then whatever is needed to get > >> to the desired code. I can certainly do that, but do you want me to? > > > > Explain that in the commit message and it's fine. > > I did the split in v2, I assume that's ok too. Better in case anyone ever > needs to run a bisect on this... > > >>> It's a pre-existing bug, but should we also try to restore the fbdev lut > >>> in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug, > >>> but might be relevant for your use-case. Just try to run both an fbdev > >>> application and some kms-native thing, and then SIGKILL the native kms > >>> app. > >>> > >>> But since pre-existing not really required, and probably too much effort. > >> > >> Good thing too, because I don't really know my way around this code... > > > > Btw I cc'ed you on one of my patches in the fbdev locking series, we might > > need to do the same legacy vs. atomic split for the new lut code as I did > > for dpms. The rule with atomic is that you can't do multiple commits under > > drm_modeset_lock_all, you either have to do one overall atomic commit > > (preferred) or drop locks again. This matters for LUT since > > you're updating the LUT on all CRTCs, which when using the gamma_set > > atomic helper would be multiple commits :-/ > > Ahh, ok, I see the problem. > > > Using the dpms patch as template it shouldn't be too hard to address that > > for your patch here too. > > Hmm, in that patch you handle the legacy case in a separate function, and > doing that for the lut case looks difficult when the atomic commit happens > inside the helper (typically drm_atomic_helper_legacy_gamma_set which > could perhaps be handled, but a real drag to handle for drivers that have > a custom crtc .gamma_set). Yeah, that's essentially why you need 2 functions. Legacy one calls the legacy interfaces, the atomic one calls the new fancy atomic property stuff directly (i.e. it open-codes the property setting dance from the helper, but with one atomic commit across all crtc). The reason that the legacy callback functions are helpers and not just default behavior is that I expected some drivers to need special hacks to keep their existing legacy kms userspace working. Atomic helpers unified behaviour a lot that beforehand was slightly inconsistent. I somewhat expect that long-term we'll unexport all the compat helpers and just make them the default for all atomic drivers. > So, I'm aiming for the drop approach... Hm, I prefer the open-coding, that's at least what we do everywhere else. Has the benefit that it's more atomic (one commit for everything). > However, I don't have all of that series, and I suspect that is why I do > not have any fb_helper->lock. Oh sorry, entire series is on dri-devel. I can do a git branch too if you need one, atm it's in my general pile: https://cgit.freedesktop.org/~danvet/drm/log/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Nouveau] [PATCH v2 00/14] improve the fb_setcmap helper
On Tue, Jun 27, 2017 at 05:50:38AM +1000, Dave Airlie wrote: > > > > I'm traveling and cannot make progress this week. The merge window is > > also real close so this series will therefore probably miss it unless > > something unexpected happens... > > Don't worry you missed the merge window for drm already, we don't merge > things after -rc6. Please remember the Linus merge window is for maintainers > to merge stuff to Linus, things need to be ready long before it, and for drm > you shouldn't really tie yourself to the merge cycle. Yeah, drm-misc is open for refactorings like this all the time, and maintainers make sure the code will get into upstream asap, without interferring with the upstream merge window schedules. Like Dave said, don't worry. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/virtio: Replace instances of reference/unreference with get/put
On Fri, Sep 29, 2017 at 03:33:39PM +0530, Srishti Sharma wrote:
> Replace reference/unreference with get/put as it is consistent
> with the kernel coding style. Done using the following semantic
> patch by coccinelle.
>
> @r@
> expression e;
> @@
>
> -drm_gem_object_unreference_unlocked(e);
> +drm_gem_object_put_unlocked(e);
>
> Signed-off-by: Srishti Sharma <srishtis...@gmail.com>
Applied to drm-misc-next, thanks.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 12 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index b6d5205..41b0930 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -53,7 +53,7 @@ static void virtio_gpu_user_framebuffer_destroy(struct
> drm_framebuffer *fb)
> struct virtio_gpu_framebuffer *virtio_gpu_fb
> = to_virtio_gpu_framebuffer(fb);
>
> - drm_gem_object_unreference_unlocked(virtio_gpu_fb->obj);
> + drm_gem_object_put_unlocked(virtio_gpu_fb->obj);
> drm_framebuffer_cleanup(fb);
> kfree(virtio_gpu_fb);
> }
> @@ -327,7 +327,7 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
> ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
> if (ret) {
> kfree(virtio_gpu_fb);
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
> return NULL;
> }
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 72ad7b1..92fb277 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -72,7 +72,7 @@ int virtio_gpu_gem_create(struct drm_file *file,
> *obj_p = >gem_base;
>
> /* drop reference from allocate - handle holds it now */
> - drm_gem_object_unreference_unlocked(>gem_base);
> + drm_gem_object_put_unlocked(>gem_base);
>
> *handle_p = handle;
> return 0;
> @@ -130,7 +130,7 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
> return -ENOENT;
> obj = gem_to_virtio_gpu_obj(gobj);
> *offset_p = virtio_gpu_object_mmap_offset(obj);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index b94bd54..0528edb 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -86,7 +86,7 @@ static void virtio_gpu_unref_list(struct list_head *head)
> bo = buf->bo;
> qobj = container_of(bo, struct virtio_gpu_object, tbo);
>
> - drm_gem_object_unreference_unlocked(>gem_base);
> + drm_gem_object_put_unlocked(>gem_base);
> }
> }
>
> @@ -304,7 +304,7 @@ static int virtio_gpu_resource_create_ioctl(struct
> drm_device *dev, void *data,
> }
> return ret;
> }
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>
> rc->res_handle = res_id; /* similiar to a VM address */
> rc->bo_handle = handle;
> @@ -341,7 +341,7 @@ static int virtio_gpu_resource_info_ioctl(struct
> drm_device *dev, void *data,
>
> ri->size = qobj->gem_base.size;
> ri->res_handle = qobj->hw_res_handle;
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return 0;
> }
>
> @@ -389,7 +389,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
> drm_device *dev,
> out_unres:
> virtio_gpu_object_unreserve(qobj);
> out:
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> @@ -439,7 +439,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
> drm_device *dev, void *data,
> out_unres:
> virtio_gpu_object_unreserve(qobj);
> out:
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> @@ -462,7 +462,7 @@ static int virtio_gpu_wait_ioctl(struct drm_device *dev,
> void *data,
> nowait = true;
> ret = virtio_gpu_object_wait(qobj, nowait);
>
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm: virtio: constify drm_fb_helper_funcs
On Mon, Aug 21, 2017 at 04:37:32PM +0530, Arvind Yadav wrote:
> drm_fb_helper_funcs are not supposed to change at runtime.
> All functions working with drm_fb_helper_funcs provided
> by work with const drm_fb_helper_funcs.
> So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
> b/drivers/gpu/drm/virtio/virtgpu_fb.c
> index 33df067..61f33ec 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fb.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
> @@ -309,7 +309,7 @@ static int virtio_gpu_fbdev_destroy(struct drm_device
> *dev,
>
> return 0;
> }
> -static struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
> +static const struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
I have this patch already from someone else. Please create your patches
against linux-next to avoid this kind of duplicated work.
Thanks, Daniel
> .fb_probe = virtio_gpufb_create,
> };
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with > > > the same code. Extract common part from PCI drivers into separate > > > remove_conflicting_pci_framebuffers(). > > > > > > Signed-off-by: Michał Mirosław <mirq-li...@rere.qmqm.pl> > > > > Since the only driver that seems to use this is the staging one, which imo > > is a DOA project, not sure it's worth to bother with this here. > > afaik, this device is used in production by few manufacturers and it is > usefull for them to have it in the tree and the only reason it is still > in staging is because Tomi announced he will not take any new drivers in > fbdev. And, so I have not taken the initiative to properly move it out > of staging. I think Bartlomiej will also not accept new drivers in fbdev. Imo, if no one cares about porting it to kms (which will give you an fbdev driver for free), then we should throw it out. At least I thought staging was only for stuff that had a reasonable chance to get mainlined. Not as a dumping ground for drivers that people use, but don't bother to get ready for mainline. Greg? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote: > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: > > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it > > > > > > with > > > > > > the same code. Extract common part from PCI drivers into separate > > > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > > > > > Signed-off-by: Michał Mirosław <mirq-li...@rere.qmqm.pl> > > > > > > > > > > Since the only driver that seems to use this is the staging one, > > > > > which imo > > > > > is a DOA project, not sure it's worth to bother with this here. > > > > > > > > afaik, this device is used in production by few manufacturers and it is > > > > usefull for them to have it in the tree and the only reason it is still > > > > in staging is because Tomi announced he will not take any new drivers in > > > > fbdev. And, so I have not taken the initiative to properly move it out > > > > of staging. I think Bartlomiej will also not accept new drivers in > > > > fbdev. > > > > > > Imo, if no one cares about porting it to kms (which will give you an fbdev > > > driver for free), then we should throw it out. At least I thought staging > > > was only for stuff that had a reasonable chance to get mainlined. Not as a > > > dumping ground for drivers that people use, but don't bother to get ready > > > for mainline. > > > > > > Greg? > > > > Yes, if no one is working to get it out of staging, that means no one > > cares about it, and it needs to be removed from the tree. > > Agreed. I was not working on getting it out of staging as there is no > place for it to go. > But, Teddy Wang told me that they have a working drm driver for it, but > it is not atomic like Daniel was asking for. If it is ok, then I can send > in a patch to remove the existing sm750 from staging and add the new sm750 > drm driver to staging. And after it is ready, we can go ahead with moving > it out of staging to drm. Please keep the todo item that it needs to be converted to atomic. And tbh, it's probably faster if you just submit it to dri-devel, assuming you have time to work on it. For small drivers we tend to be fairly quick in getting them into good enough shape. Staging is also a major pain for drm subsystem refactorings, I really, really, really prefer we don't add more than the vbox pain we have already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> Almost all drivers using remove_conflicting_framebuffers() wrap it with
> the same code. Extract common part from PCI drivers into separate
> remove_conflicting_pci_framebuffers().
>
> Signed-off-by: Michał Mirosław <mirq-li...@rere.qmqm.pl>
Since the only driver that seems to use this is the staging one, which imo
is a DOA project, not sure it's worth to bother with this here.
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 22 ++
> include/drm/drm_fb_helper.h | 12
> include/linux/fb.h | 2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 30a18d4c9de4..5ea980e5d3b7 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1788,6 +1789,27 @@ int remove_conflicting_framebuffers(struct
> apertures_struct *a,
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> +int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id,
> const char *name)
> +{
> + struct apertures_struct *ap;
> + bool primary = false;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return -ENOMEM;
> +
> + ap->ranges[0].base = pci_resource_start(pdev, res_id);
> + ap->ranges[0].size = pci_resource_len(pdev, res_id);
> +#ifdef CONFIG_X86
> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> + IORESOURCE_ROM_SHADOW;
> +#endif
> + remove_conflicting_framebuffers(ap, name, primary);
> + kfree(ap);
> + return 0;
> +}
> +EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
> +
> /**
> * register_framebuffer - registers a frame buffer device
> * @fb_info: frame buffer info structure
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 33fe95927742..ac3412290289 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -520,4 +520,16 @@ drm_fb_helper_remove_conflicting_framebuffers(struct
> apertures_struct *a,
> #endif
> }
>
> +static inline int
> +drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> + int resource_id,
> + const char *name)
> +{
> +#if IS_REACHABLE(CONFIG_FB)
> + return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
> +#else
> + return 0;
> +#endif
> +}
> +
> #endif
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index f4386b0ccf40..4196cb09e58e 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -624,6 +624,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const
> char __user *buf,
> extern int register_framebuffer(struct fb_info *fb_info);
> extern int unregister_framebuffer(struct fb_info *fb_info);
> extern int unlink_framebuffer(struct fb_info *fb_info);
> +extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int
> res_id,
> +const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/13] remove_conflicting_framebuffers() cleanup
On Fri, Nov 24, 2017 at 06:53:25PM +0100, Michał Mirosław wrote: > This series cleans up duplicated code for replacing firmware FB > driver with proper DRI driver and adds handover support to > Tegra driver. > > The last patch is here because it uses new semantics of > remove_conflicting_framebuffers() from this series. This > can be considered independently, though. Except for that patches I've commented on: Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> Since this is for tegra and Thierry has drm-misc commit rights, it's probably simplest when Thierry pushes this all to drm-misc once driver maintainers had a chance to look at it. Also needs and ack from Bart for the fbdev sides. -Daniel > > --- > > Michał Mirosław (13): > fbdev: show fbdev number for debugging > fbdev: add remove_conflicting_pci_framebuffers() > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > staging: sm750fb: use simpler remove_conflicting_pci_framebuffers() > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > drm/tegra: kick out simplefb > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 +- > drivers/gpu/drm/bochs/bochs_drv.c| 18 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +- > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 + > drivers/gpu/drm/mgag200/mgag200_main.c | 9 --- > drivers/gpu/drm/radeon/radeon_drv.c | 23 +- > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +- > drivers/gpu/drm/tegra/drm.c | 4 > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +++ > drivers/staging/sm750fb/sm750.c | 22 +- > drivers/video/fbdev/core/fbmem.c | 40 > ++-- > include/drm/drm_fb_helper.h | 12 ++ > include/linux/fb.h | 2 ++ > 14 files changed, 67 insertions(+), 192 deletions(-) > > -- > 2.11.0 > > ___________ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Thu, Nov 30, 2017 at 11:49:53PM +, Sudip Mukherjee wrote: > Hi Daniel, > > On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter wrote: > > On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote: > > > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: > > > > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > > > > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > > > > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap > > > > > > > > it with > > > > > > > > the same code. Extract common part from PCI drivers into > > > > > > > > separate > > > > > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > > > > > > > > > > > > > > Greg? > > > > > > > > Yes, if no one is working to get it out of staging, that means no one > > > > cares about it, and it needs to be removed from the tree. > > > > > > Agreed. I was not working on getting it out of staging as there is no > > > place for it to go. > > > But, Teddy Wang told me that they have a working drm driver for it, but > > > it is not atomic like Daniel was asking for. If it is ok, then I can send > > > in a patch to remove the existing sm750 from staging and add the new sm750 > > > drm driver to staging. And after it is ready, we can go ahead with moving > > > it out of staging to drm. > > > > Please keep the todo item that it needs to be converted to atomic. And > > tbh, it's probably faster if you just submit it to dri-devel, assuming you > > have time to work on it. For small drivers we tend to be fairly quick in > > getting them into good enough shape. > > I have received the driver from Teddy and pushed it to > https://github.com/sudipm-mukherjee/parport/tree/drm_smi for your first > look into it. It is not even building with next-20171130 and has lots of > build warnings. I will have to do a lot of work on it before I can even > submit it to dri-devel. > > Time will be the problem, as this is not part of my day job. > > > > > Staging is also a major pain for drm subsystem refactorings, I really, > > really, really prefer we don't add more than the vbox pain we have > > already. > > I am hoping that after seeing it, you will agree to have it in staging. :) So I know Greg is willing to take anything into staging, but I'm no fan. We refactor and improve drm a lot, with a lot of cross-driver changes necessary to move things forward. We can do that since we have a generally rather active development community, and we try hard to keep most drivers in reasonable good shape and so easy to maintain. If you know throw a pile of unmaintainable stuff into staging, but without working on it, then that's just cost, no benefit to the dri-devel community. On top, staging tree is separate from drm trees, so more pain to synchronize trees (and we have to do that a few times per release cycle or drivers simply stop compiling). Where's the upside of taking this driver into staging? One is users, but ime for soc display drivers usually everything else is in worse shape (e.g. even great drivers like the one for qualcom must be tested on some vendor tree because critical core bits are missing in upstream), so "more users" is not the good reason. And it's clearly not "more developers", because no time to clean things up. So what exactly is the good reason to put this into staging instead of just waiting until someone has the time to clean it up quickly? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 16/17] drm/virtio: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: David Airlie <airl...@linux.ie>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 23353521f903..00c742a441bf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -36,11 +36,6 @@ static const char *virtio_get_timeline_name(struct dma_fence
*f)
return "controlq";
}
-static bool virtio_enable_signaling(struct dma_fence *f)
-{
- return true;
-}
-
static bool virtio_signaled(struct dma_fence *f)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
@@ -67,9 +62,7 @@ static void virtio_timeline_value_str(struct dma_fence *f,
char *str, int size)
static const struct dma_fence_ops virtio_fence_ops = {
.get_driver_name = virtio_get_driver_name,
.get_timeline_name = virtio_get_timeline_name,
- .enable_signaling= virtio_enable_signaling,
.signaled= virtio_signaled,
- .wait= dma_fence_default_wait,
.fence_value_str = virtio_fence_value_str,
.timeline_value_str = virtio_timeline_value_str,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 12/17] drm/qxl: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Dave Airlie <airl...@redhat.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence
*fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did
this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 14/15] drm/virtio: Remove unecessary dma_fence_ops
On Thu, May 03, 2018 at 04:26:02PM +0200, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Reviewed-by: Eric Anholt
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
Ok pulled in the remaining patches here with acks/r-bs, will resend the
others.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
> b/drivers/gpu/drm/virtio/virtgpu_fence.c
> index 23353521f903..00c742a441bf 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fence.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
> @@ -36,11 +36,6 @@ static const char *virtio_get_timeline_name(struct
> dma_fence *f)
> return "controlq";
> }
>
> -static bool virtio_enable_signaling(struct dma_fence *f)
> -{
> - return true;
> -}
> -
> static bool virtio_signaled(struct dma_fence *f)
> {
> struct virtio_gpu_fence *fence = to_virtio_fence(f);
> @@ -67,9 +62,7 @@ static void virtio_timeline_value_str(struct dma_fence *f,
> char *str, int size)
> static const struct dma_fence_ops virtio_fence_ops = {
> .get_driver_name = virtio_get_driver_name,
> .get_timeline_name = virtio_get_timeline_name,
> - .enable_signaling= virtio_enable_signaling,
> .signaled= virtio_signaled,
> - .wait= dma_fence_default_wait,
> .fence_value_str = virtio_fence_value_str,
> .timeline_value_str = virtio_timeline_value_str,
> };
> --
> 2.17.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm/qxl: Remove unecessary dma_fence_ops
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt <e...@anholt.net>
Reviewed-by: Eric Anholt <e...@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Dave Airlie <airl...@redhat.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence
*fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did
this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm/qxl: Remove unecessary dma_fence_ops
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt <e...@anholt.net>
Reviewed-by: Eric Anholt <e...@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Dave Airlie <airl...@redhat.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence
*fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did
this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses
vide
>* for easy error handling.
>*/
> drm = drm_dev_alloc(driver, parent);
> @@ -155,7 +155,7 @@ static void tinydrm_fini(struct tinydrm_device *tdev)
> drm_mode_config_cleanup(tdev->drm);
> mutex_destroy(>dirty_lock);
> tdev->drm->dev_private = NULL;
> - drm_dev_unref(tdev->drm);
> + drm_dev_put(tdev->drm);
> }
>
> static void devm_tinydrm_release(void *data)
> @@ -172,7 +172,7 @@ static void devm_tinydrm_release(void *data)
> *
> * This function initializes @tdev, the underlying DRM device and it's
> * mode_config. Resources will be automatically freed on driver detach
> (devres)
> - * using drm_mode_config_cleanup() and drm_dev_unref().
> + * using drm_mode_config_cleanup() and drm_dev_put().
> *
> * Returns:
> * Zero on success, negative error code on failure.
> diff --git a/drivers/gpu/drm/tve200/tve200_drv.c
> b/drivers/gpu/drm/tve200/tve200_drv.c
> index ac344ddb23bc..e36a78ef68b7 100644
> --- a/drivers/gpu/drm/tve200/tve200_drv.c
> +++ b/drivers/gpu/drm/tve200/tve200_drv.c
> @@ -250,7 +250,7 @@ static int tve200_probe(struct platform_device *pdev)
> clk_disable:
> clk_disable_unprepare(priv->pclk);
> dev_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> return ret;
> }
>
> @@ -265,7 +265,7 @@ static int tve200_remove(struct platform_device *pdev)
> drm_panel_bridge_remove(priv->bridge);
> drm_mode_config_cleanup(drm);
> clk_disable_unprepare(priv->pclk);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 3c45a3064726..d5e94eb7a4ca 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -94,7 +94,7 @@ static int udl_usb_probe(struct usb_interface *interface,
> return 0;
>
> err_free:
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 94b99c90425a..259c85fcd32c 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -312,7 +312,7 @@ static int vc4_drm_bind(struct device *dev)
> vc4_gem_destroy(drm);
> vc4_bo_cache_destroy(drm);
> dev_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> return ret;
> }
>
> @@ -327,7 +327,7 @@ static void vc4_drm_unbind(struct device *dev)
>
> drm_mode_config_cleanup(drm);
>
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops vc4_drm_ops = {
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff116f00..305f87665499 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -505,7 +505,7 @@ static int __init vgem_init(void)
> static void __exit vgem_exit(void)
> {
> drm_dev_unregister(_device->drm);
> - drm_dev_unref(_device->drm);
> + drm_dev_put(_device->drm);
> }
>
> module_init(vgem_init);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> index 7df8d0c9026a..094b876f6da6 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -85,6 +85,6 @@ int drm_virtio_init(struct drm_driver *driver, struct
> virtio_device *vdev)
> return 0;
>
> err_free:
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
> return ret;
> }
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e80378..02ae1caf6e8a 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -122,7 +122,7 @@ static int zx_drm_bind(struct device *dev)
> component_unbind_all(dev, drm);
> out_unregister:
> dev_set_drvdata(dev, NULL);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> return ret;
> }
>
> @@ -136,7 +136,7 @@ static void zx_drm_unbind(struct device *dev)
> drm_mode_config_cleanup(drm);
> component_unbind_all(dev, drm);
> dev_set_drvdata(dev, NULL);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops zx_drm_master_ops = {
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d23dcdd1bd95..c16dd4424b8a 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -622,7 +622,6 @@ void drm_dev_unregister(struct drm_device *dev);
>
> void drm_dev_get(struct drm_device *dev);
> void drm_dev_put(struct drm_device *dev);
> -void drm_dev_unref(struct drm_device *dev);
> void drm_put_dev(struct drm_device *dev);
> void drm_dev_unplug(struct drm_device *dev);
>
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 11/15] drm/qxl: Remove unecessary dma_fence_ops
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt <e...@anholt.net>
Reviewed-by: Eric Anholt <e...@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Dave Airlie <airl...@redhat.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 7cb214577275..e37f0097f744 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -50,12 +50,6 @@ static const char *qxl_get_timeline_name(struct dma_fence
*fence)
return "release";
}
-static bool qxl_nop_signaling(struct dma_fence *fence)
-{
- /* fences are always automatically signaled, so just pretend we did
this.. */
- return true;
-}
-
static long qxl_fence_wait(struct dma_fence *fence, bool intr,
signed long timeout)
{
@@ -119,7 +113,6 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
static const struct dma_fence_ops qxl_fence_ops = {
.get_driver_name = qxl_get_driver_name,
.get_timeline_name = qxl_get_timeline_name,
- .enable_signaling = qxl_nop_signaling,
.wait = qxl_fence_wait,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 14/15] drm/virtio: Remove unecessary dma_fence_ops
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt <e...@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: David Airlie <airl...@linux.ie>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 23353521f903..00c742a441bf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -36,11 +36,6 @@ static const char *virtio_get_timeline_name(struct dma_fence
*f)
return "controlq";
}
-static bool virtio_enable_signaling(struct dma_fence *f)
-{
- return true;
-}
-
static bool virtio_signaled(struct dma_fence *f)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
@@ -67,9 +62,7 @@ static void virtio_timeline_value_str(struct dma_fence *f,
char *str, int size)
static const struct dma_fence_ops virtio_fence_ops = {
.get_driver_name = virtio_get_driver_name,
.get_timeline_name = virtio_get_timeline_name,
- .enable_signaling= virtio_enable_signaling,
.signaled= virtio_signaled,
- .wait= dma_fence_default_wait,
.fence_value_str = virtio_fence_value_str,
.timeline_value_str = virtio_timeline_value_str,
};
--
2.17.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/bochs: make structure bochs_bo_driver static
On Wed, Feb 07, 2018 at 11:13:53AM +, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> The structure bochs_bo_driver is local to the source and does not need to
> be in global scope, so make it static.
>
> Cleans up sparse warning:
> drivers/gpu/drm/bochs/bochs_mm.c:197:22: warning: symbol 'bochs_bo_driver'
> was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Applied to drm-misc-next, thanks.
-Daniel
> ---
> drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index 704e879711e4..b1d5aee46316 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -194,7 +194,7 @@ static struct ttm_tt *bochs_ttm_tt_create(struct
> ttm_bo_device *bdev,
> return tt;
> }
>
> -struct ttm_bo_driver bochs_bo_driver = {
> +static struct ttm_bo_driver bochs_bo_driver = {
> .ttm_tt_create = bochs_ttm_tt_create,
> .ttm_tt_populate = ttm_pool_populate,
> .ttm_tt_unpopulate = ttm_pool_unpopulate,
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bochs: convert to drm_fb_helper_fbdev_setup/teardown
On Wed, Sep 05, 2018 at 04:41:27PM +0200, Peter Wu wrote:
> Currently unloading bochs_drm (after unbinding the vtconsole) results in
> a warning about a leaked connector:
>
> [drm:drm_mode_config_cleanup] *ERROR* connector Virtual-3 leaked!
>
> While investigating a potential fix I noticed that a lot of open-coded
> functionality is already implemented elsewhere, so start converting it:
> bochs_fbdev_init -> drm_fb_helper_fbdev_setup: trivial (similar impl).
> bochs_fbdev_fini -> drm_fb_helper_fbdev_teardown: requires unembedding
> "struct drm_framebuffer" from "struct bochs_framebuffer".
>
> Unembedding drm_framebuffer is made easy using drm_gem_fbdev_fb_create
> which can replace bochs_fbdev_destroy and custom routines in bochs_mm.c.
> For this to work, the GEM object is moved into "drm_framebuffer". After
> that, "bochs_framebuffer" is no longer needed and therefore removed.
>
> Remove the unused "size" and "initialized" fields from fb, the latter is
> not necessary as drm_fb_helper_fbdev_teardown can be called even if
> bochsfb_create fails. This theory was tested by returning early and
> late (just before drm_gem_fbdev_fb_create). Both scenarios fail
> gracefully although the latter seems to leak the object from
> bochsfb_create_object (not a regression).
>
> Guess on the reason for the encoder leak: drm_framebuffer_cleanup was
> previously used, but did not destroy much. drm_fb_helper_fbdev_teardown
> is now used and calls drm_framebuffer_remove which does a bit more work.
>
> Tested with 'echo 0 > /sys/class/vtconsole/vtcon1/bind; rmmod bochs_drm'
> and also with Xorg + fbdev (startx -> xterm). The latter triggered a
> warning in ttm_bo_vm_open that existed before, see
> https://lkml.kernel.org/r/1464000533-13140-4-git-send-email-msta...@suse.de
You can probably get rid of this one if you're refactoring even more. The
generic fb_probe implementation (already merged) plus gem-shmem support
for it (still in flight) from Noralf should be able to pull that off. That
gives you the fb_mmap implementation, but with 100% generic code instead
of a driver specific hack like Max did.
>
> Signed-off-by: Peter Wu
lgtm. Acked-by: Daniel Vetter
I'll leave merging to Gerd.
-Daniel
> ---
> drivers/gpu/drm/bochs/bochs.h | 19 ++-
> drivers/gpu/drm/bochs/bochs_fbdev.c | 79 +++--
> drivers/gpu/drm/bochs/bochs_kms.c | 7 +--
> drivers/gpu/drm/bochs/bochs_mm.c| 74 ---
> 4 files changed, 22 insertions(+), 157 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index 375bf92cd04f..8514a84fbdbe 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -51,11 +51,6 @@ enum bochs_types {
> BOCHS_UNKNOWN,
> };
>
> -struct bochs_framebuffer {
> - struct drm_framebuffer base;
> - struct drm_gem_object *obj;
> -};
> -
> struct bochs_device {
> /* hw */
> void __iomem *mmio;
> @@ -88,15 +83,11 @@ struct bochs_device {
>
> /* fbdev */
> struct {
> - struct bochs_framebuffer gfb;
> + struct drm_framebuffer *fb;
> struct drm_fb_helper helper;
> - int size;
> - bool initialized;
> } fb;
> };
>
> -#define to_bochs_framebuffer(x) container_of(x, struct bochs_framebuffer,
> base)
> -
> struct bochs_bo {
> struct ttm_buffer_object bo;
> struct ttm_placement placement;
> @@ -148,15 +139,9 @@ int bochs_dumb_create(struct drm_file *file, struct
> drm_device *dev,
> int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
> uint32_t handle, uint64_t *offset);
>
> -int bochs_framebuffer_init(struct drm_device *dev,
> -struct bochs_framebuffer *gfb,
> -const struct drm_mode_fb_cmd2 *mode_cmd,
> -struct drm_gem_object *obj);
> int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr);
> int bochs_bo_unpin(struct bochs_bo *bo);
>
> -extern const struct drm_mode_config_funcs bochs_mode_funcs;
> -
> /* bochs_kms.c */
> int bochs_kms_init(struct bochs_device *bochs);
> void bochs_kms_fini(struct bochs_device *bochs);
> @@ -164,3 +149,5 @@ void bochs_kms_fini(struct bochs_device *bochs);
> /* bochs_fbdev.c */
> int bochs_fbdev_init(struct bochs_device *bochs);
> void bochs_fbdev_fini(struct bochs_device *bochs);
> +
> +extern const struct drm_mode_config_funcs bochs_mode_funcs;
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
> b/drivers/gpu/d
Re: [PATCH v2 02/12] fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
On Fri, Aug 31, 2018 at 10:56:56AM +0200, Daniel Vetter wrote:
> On Thu, Aug 30, 2018 at 11:00:05PM +0200, Michał Mirosław wrote:
> > Interpret (otherwise-invalid) NULL apertures argument to mean all-memory
> > range. This will allow to remove several duplicates of this code from
> > drivers in following patches.
> >
> > Signed-off-by: Michał Mirosław
> > [for v1]
> > Acked-by: Bartlomiej Zolnierkiewicz
> >
> > ---
> > v2: added kerneldoc to corresponding DRM helper
> > ---
> > drivers/video/fbdev/core/fbmem.c | 14 ++
> > include/drm/drm_fb_helper.h | 10 ++
> > 2 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 30a18d4c9de4..0df148eb4699 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1779,11 +1779,25 @@ int remove_conflicting_framebuffers(struct
> > apertures_struct *a,
> > const char *name, bool primary)
> > {
> > int ret;
> > + bool do_free = false;
> > +
> > + if (!a) {
> > + a = alloc_apertures(1);
> > + if (!a)
> > + return -ENOMEM;
> > +
> > + a->ranges[0].base = 0;
> > + a->ranges[0].size = ~0;
> > + do_free = true;
> > + }
> >
> > mutex_lock(_lock);
> > ret = do_remove_conflicting_framebuffers(a, name, primary);
> > mutex_unlock(_lock);
> >
> > + if (do_free)
> > + kfree(a);
> > +
> > return ret;
> > }
> > EXPORT_SYMBOL(remove_conflicting_framebuffers);
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index b069433e7fc1..1c1e53abb25d 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -566,6 +566,16 @@ static inline void
> > drm_fb_helper_output_poll_changed(struct drm_device *dev)
> >
> > #endif
> >
> > +/**
> > + * drm_fb_helper_remove_conflicting_framebuffers - remove firmware
> > framebuffers
> > + * @a: memory range, users of which are to be removed
> > + * @name: requesting driver name
> > + * @primary: also kick vga16fb if present
> > + *
> > + * This function removes framebuffer devices (eg. initialized by firmware)
> > + * which use memory range described by @a. If @a is NULL all such devices
> > are
> > + * removed.
> > + */
>
> This looks like misplaced copypasta. You only need this once I think.
Ah no, just a fixup for the lack of kerneldoc we have. Can you pls split
this out into a separate patch?
Thanks, Daniel
> -Daniel
>
> > static inline int
> > drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> > const char *name, bool primary)
> > --
> > 2.18.0
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/cirrus: flip default to 32bpp
On Fri, Jul 06, 2018 at 02:35:07PM -0400, Adam Jackson wrote: > On Fri, 2018-07-06 at 11:12 +0200, Gerd Hoffmann wrote: > > cirrus can handle 1024x768 (and slightly higher) with 24bpp depth. > > cirrus can handle up to 800x600 with 32bpp. > > 16bpp is maybe a better choice? Nobody's using cirrus because they care > about color fidelity and it'll use less CPU to update. There's > precedent here, mgag200 defaults to 16bpp on sufficiently memory- > impaired devices. Yeah nouveau does the same fallback to 16bpp if there's not enough vram. So do a bunch of other drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH 08/13] drm/virtio: Stop updating plane->crtc
On Thu, Apr 05, 2018 at 06:13:55PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > We want to get rid of plane->crtc on atomic drivers. Stop setting it. > > v2: s/fb/crtc/ in the commit message (Gerd) > > Cc: David Airlie <airl...@linux.ie> > Cc: Gerd Hoffmann <kra...@redhat.com> > Cc: virtualization@lists.linux-foundation.org > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> > --- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c > b/drivers/gpu/drm/virtio/virtgpu_display.c > index 8cc8c34d67f5..42e842ceb53c 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_display.c > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c > @@ -302,8 +302,6 @@ static int vgdev_output_init(struct virtio_gpu_device > *vgdev, int index) > drm_crtc_init_with_planes(dev, crtc, primary, cursor, > _gpu_crtc_funcs, NULL); > drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs); > - primary->crtc = crtc; > - cursor->crtc = crtc; > > drm_connector_init(dev, connector, _gpu_connector_funcs, > DRM_MODE_CONNECTOR_VIRTUAL); > -- > 2.16.1 > > _______ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/2] qxl: fix qxl_release_{map,unmap}
On Wed, Apr 18, 2018 at 07:42:56AM +0200, Gerd Hoffmann wrote:
> s/PAGE_SIZE/PAGE_MASK/
>
> Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
> bad side effects and managed to stay unnoticed for years that way ...
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Sweeet. Since the buggy code uses the same expression for page frame and
offset I don't think there's a security bug. You might still want to cc:
stable (since without you defacto can't ever use this feature).
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
> index e238a1a2ec..6cc9f3367f 100644
> --- a/drivers/gpu/drm/qxl/qxl_ioctl.c
> +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
> @@ -182,9 +182,9 @@ static int qxl_process_single_command(struct qxl_device
> *qdev,
> goto out_free_reloc;
>
> /* TODO copy slow path code from i915 */
> - fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset
> & PAGE_SIZE));
> + fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset
> & PAGE_MASK));
> unwritten = __copy_from_user_inatomic_nocache
> - (fb_cmd + sizeof(union qxl_release_info) +
> (release->release_offset & ~PAGE_SIZE),
> + (fb_cmd + sizeof(union qxl_release_info) +
> (release->release_offset & ~PAGE_MASK),
>u64_to_user_ptr(cmd->command), cmd->command_size);
>
> {
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index 5d84a66fed..a0b4244d28 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -411,10 +411,10 @@ union qxl_release_info *qxl_release_map(struct
> qxl_device *qdev,
> struct qxl_bo_list *entry = list_first_entry(>bos, struct
> qxl_bo_list, tv.head);
> struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
>
> - ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset &
> PAGE_SIZE);
> + ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset &
> PAGE_MASK);
> if (!ptr)
> return NULL;
> - info = ptr + (release->release_offset & ~PAGE_SIZE);
> + info = ptr + (release->release_offset & ~PAGE_MASK);
> return info;
> }
>
> @@ -426,7 +426,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
> struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
> void *ptr;
>
> - ptr = ((void *)info) - (release->release_offset & ~PAGE_SIZE);
> + ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
> qxl_bo_kunmap_atomic_page(qdev, bo, ptr);
> }
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 4/4] qxl: drop dummy functions
On Fri, Apr 20, 2018 at 09:19:04AM +0200, Gerd Hoffmann wrote:
> These days drm core checks function pointers everywhere before calling
> them. So we can drop a bunch of dummy functions now.
>
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 50
> ---
> 1 file changed, 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 06ee00b486..af6e52af5f 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -456,13 +456,6 @@ qxl_framebuffer_init(struct drm_device *dev,
> return 0;
> }
>
> -static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
> static void qxl_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> @@ -476,7 +469,6 @@ static void qxl_crtc_atomic_disable(struct drm_crtc *crtc,
> }
>
> static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
> - .mode_fixup = qxl_crtc_mode_fixup,
> .atomic_flush = qxl_crtc_atomic_flush,
> .atomic_enable = qxl_crtc_atomic_enable,
> .atomic_disable = qxl_crtc_atomic_disable,
> @@ -620,12 +612,6 @@ static void qxl_primary_atomic_disable(struct drm_plane
> *plane,
> }
> }
>
> -static int qxl_plane_atomic_check(struct drm_plane *plane,
> - struct drm_plane_state *state)
> -{
> - return 0;
> -}
> -
> static void qxl_cursor_atomic_update(struct drm_plane *plane,
>struct drm_plane_state *old_state)
> {
> @@ -831,7 +817,6 @@ static const uint32_t qxl_cursor_plane_formats[] = {
> };
>
> static const struct drm_plane_helper_funcs qxl_cursor_helper_funcs = {
> - .atomic_check = qxl_plane_atomic_check,
> .atomic_update = qxl_cursor_atomic_update,
> .atomic_disable = qxl_cursor_atomic_disable,
> .prepare_fb = qxl_plane_prepare_fb,
> @@ -956,28 +941,6 @@ static int qdev_crtc_init(struct drm_device *dev, int
> crtc_id)
> return r;
> }
>
> -static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_prepare(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_commit(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> static int qxl_conn_get_modes(struct drm_connector *connector)
> {
> unsigned pwidth = 1024;
> @@ -1023,10 +986,6 @@ static struct drm_encoder *qxl_best_encoder(struct
> drm_connector *connector)
>
>
> static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
Hm, I thought even the vtable itself is optional? We do have tons of if
(!funcs) checks all over the place at least.
> - .dpms = qxl_enc_dpms,
> - .prepare = qxl_enc_prepare,
> - .mode_set = qxl_enc_mode_set,
> - .commit = qxl_enc_commit,
> };
>
> static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> @@ -1059,14 +1018,6 @@ static enum drm_connector_status qxl_conn_detect(
>: connector_status_disconnected;
> }
>
> -static int qxl_conn_set_property(struct drm_connector *connector,
> -struct drm_property *property,
> -uint64_t value)
> -{
> - DRM_DEBUG("\n");
> - return 0;
> -}
> -
> static void qxl_conn_destroy(struct drm_connector *connector)
> {
> struct qxl_output *qxl_output =
> @@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs
> qxl_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> .detect = qxl_conn_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> - .set_property = qxl_conn_set_property,
This is a legacy callback anyway. I kinda wonder whether we should have a
bunch of WARN_ON checks for this, so that atomic drivers don't have these
hanging around anymore.
Anyway, patch looks pretty.
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> .destroy = qxl_conn_destroy,
> .reset = drm_atomic_helper_co
Re: [PATCH] drm/virtio: fix mode_valid's return type
On Tue, Apr 24, 2018 at 03:15:24PM +0200, Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by using 'enum drm_mode_status' in the driver too.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenr...@gmail.com>
Ok, applied all the others that have been stuck in moderation or
something, except for any patch touching nouveau/radeon/amdgpu. Those need
ot go in through other trees.
All merged into drm-misc-next.
Thanks, Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 8cc8c34d6..a5edd8660 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -208,7 +208,7 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
> *connector)
> return count;
> }
>
> -static int virtio_gpu_conn_mode_valid(struct drm_connector *connector,
> +static enum drm_mode_status virtio_gpu_conn_mode_valid(struct drm_connector
> *connector,
> struct drm_display_mode *mode)
> {
> struct virtio_gpu_output *output =
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t
On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
> On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
> > Use new return type vm_fault_t for fault handler. For
> > now, this is just documenting that the function returns
> > a VM_FAULT value rather than an errno. Once all instances
> > are converted, vm_fault_t will become a distinct type.
> >
> > Reference id -> 1c8f422059ae ("mm: change return type to
> > vm_fault_t")
>
> Hmm, that commit isn't yet in drm-misc-next.
> Will drm-misc-next merge with 4.17-rcX soon?
For backmerge requests you need to cc/ping the drm-misc maintainers.
Adding them. I think the hold-up also was that Dave was on vacations
still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers
On Thu, Mar 22, 2018 at 05:22:50PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > I really just wanted to fix i915 to re-enable its planes afer load > detection (a two line patch). This is what I actually ended up with > after I ran into a framebuffer refcount leak with said two line patch. > > I've tested this on a few i915 boxes and so far it's looking > good. Everything else is just compile tested. > > Entire series available here: > git://github.com/vsyrjala/linux.git plane_fb_crtc_nuke > > Cc: Alex Deucher <alexander.deuc...@amd.com> > Cc: amd-...@lists.freedesktop.org > Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org> > Cc: Boris Brezillon <boris.brezil...@free-electrons.com> > Cc: ch...@chris-wilson.co.uk > Cc: "Christian König" <christian.koe...@amd.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Dave Airlie <airl...@gmail.com> > Cc: David Airlie <airl...@linux.ie> > Cc: "David (ChunMing) Zhou" <david1.z...@amd.com> > Cc: Eric Anholt <e...@anholt.net> > Cc: freedr...@lists.freedesktop.org > Cc: Gerd Hoffmann <kra...@redhat.com> > Cc: Harry Wentland <harry.wentl...@amd.com> > Cc: Inki Dae <inki@samsung.com> > Cc: Joonyoung Shim <jy0922.s...@samsung.com> > Cc: Kyungmin Park <kyungmin.p...@samsung.com> > Cc: linux-arm-...@vger.kernel.org > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: martin.pe...@free.fr > Cc: Rob Clark <robdcl...@gmail.com> > Cc: Seung-Woo Kim <sw0312@samsung.com> > Cc: Shawn Guo <shawn...@kernel.org> > Cc: Sinclair Yeh <s...@vmware.com> > Cc: Thomas Hellstrom <thellst...@vmware.com> > Cc: Vincent Abriou <vincent.abr...@st.com> > Cc: virtualization@lists.linux-foundation.org > Cc: VMware Graphics <linux-graphics-maintai...@vmware.com> > > Ville Syrjälä (23): > Revert "drm/atomic-helper: Fix leak in disable_all" > drm/atomic-helper: Make drm_atomic_helper_disable_all() update the > plane->fb pointers > drm: Clear crtc->primary->crtc when disabling the crtc via setcrtc() > drm/atomic-helper: WARN if legacy plane fb pointers are bogus when > committing duplicated state > drm: Add local 'plane' variable for primary/cursor planes > drm: Adjust whitespace for legibility > drm: Make the fb refcount handover less magic > drm: Use plane->state->fb over plane->fb > drm/i915: Stop consulting plane->fb > drm/msm: Stop consulting plane->fb > drm/sti: Stop consulting plane->fb > drm/vmwgfx: Stop consulting plane->fb > drm/zte: Stop consulting plane->fb > drm/atmel-hlcdc: Stop using plane->fb > drm: Stop updating plane->crtc/fb/old_fb on atomic drivers > drm/amdgpu/dc: Stop updating plane->fb > drm/i915: Stop updating plane->fb/crtc > drm/exynos: Stop updating plane->crtc > drm/msm: Stop updating plane->fb/crtc > drm/virtio: Stop updating plane->fb > drm/vc4: Stop updating plane->fb/crtc > drm/i915: Restore planes after load detection > drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplug Ok, I reviewed the core patches, looks all good. Also starting auditing all the drivers. I think there's some small oversights in there, and I need to update my grep foo a bit, but by and large looks all reasonable. Imo we should start merging, that will also make the auditing easier. -Daniel > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 12 +--- > drivers/gpu/drm/drm_atomic.c | 55 ++-- > drivers/gpu/drm/drm_atomic_helper.c | 79 > ++- > drivers/gpu/drm/drm_crtc.c| 51 ++- > drivers/gpu/drm/drm_fb_helper.c | 7 -- > drivers/gpu/drm/drm_framebuffer.c | 5 -- > drivers/gpu/drm/drm_plane.c | 64 +++--- > drivers/gpu/drm/drm_plane_helper.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 - > drivers/gpu/drm/i915/intel_crt.c | 6 ++ > drivers/gpu/drm/i915/intel_display.c | 9 +-- > drivers/gpu/drm/i915/intel_fbdev.c| 2 +- > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 3 +- > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 - > drivers/gpu/drm/sti/sti_plane.c | 9 +-- > drivers/gpu/drm/vc4/vc4_crtc.c| 3 - > drivers/gpu/drm/virtio/virtg
Re: [Outreachy kernel] [PATCH] drm/qxl: Replace drm_gem_object_reference/unreference() with _get/put()
ference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_object.c
> b/drivers/gpu/drm/qxl/qxl_object.c
> index f6b80fe..e9fb0ab 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.c
> +++ b/drivers/gpu/drm/qxl/qxl_object.c
> @@ -211,13 +211,13 @@ void qxl_bo_unref(struct qxl_bo **bo)
> if ((*bo) == NULL)
> return;
>
> - drm_gem_object_unreference_unlocked(&(*bo)->gem_base);
> + drm_gem_object_put_unlocked(&(*bo)->gem_base);
> *bo = NULL;
> }
>
> struct qxl_bo *qxl_bo_ref(struct qxl_bo *bo)
> {
> - drm_gem_object_reference(>gem_base);
> + drm_gem_object_get(>gem_base);
> return bo;
> }
>
> @@ -318,7 +318,7 @@ void qxl_bo_force_delete(struct qxl_device *qdev)
> list_del_init(>list);
> mutex_unlock(>gem.mutex);
> /* this should unref the ttm bo */
> - drm_gem_object_unreference_unlocked(>gem_base);
> + drm_gem_object_put_unlocked(>gem_base);
> }
> }
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/1521570567-22519-1-git-send-email-santhameena13%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses
On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
<alexandre.bell...@bootlin.com> wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while since we introduced drm_dev{get/put} functions
>> > > to replace reference/unreference in drm subsystem for the
>> > > consistency purpose. So, with this patch, let's just replace
>> > > all current use cases of drm_dev_unref() with drm_dev_put and remove
>> > > the function itself.
>> > >
>> > > Coccinelle was used for mass-patching.
>> > >
>> > > Signed-off-by: Vaishali Thakkar <vthakkar1...@gmail.com>
>> >
>> > Thanks for doing this. Unfortunately drm moves pretty fast, so already a
>> > conflict when I tried to apply this. Some drivers are also in their own
>> > trees, so this might lead to more fun :-/
>> >
>> > Can you pls split it up per-driver (just the directories under
>> > drivers/gpu/drm/ is enough)? Final patch to remove the function might then
>> > get stalled a bit ofc.
>>
>> I requested a single patch instead of splitting it per driver, you might want
>> to blame me for that.
>>
>
> Doesn't splitting the change per driver break bisectability unless there
> is a guarantee that the change in include/drm/drm_drv.h is applied after
> all the driver trees have been merged?
That's why I said the final patch will likely take a bit longer to get
merged, since we have to wait until all the trees converge again. But
since I have conflicts already looks like we can't take the shortcut
:-(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] virtio-gpu: add VIRTIO_GPU_F_EDID feature
On Fri, Oct 05, 2018 at 04:38:11PM +0200, Christophe de Dinechin wrote:
>
>
> > On 5 Oct 2018, at 14:51, Gerd Hoffmann wrote:
> >
> > The feature allows the guest request an EDID blob (describing monitor
> > capabilities) for a given scanout (aka virtual monitor connector).
> >
> > It brings a new command message, which has just a scanout field (beside
> > the standard virtio-gpu header) and a response message which carries the
> > EDID data.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > include/uapi/linux/virtio_gpu.h | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/include/uapi/linux/virtio_gpu.h
> > b/include/uapi/linux/virtio_gpu.h
> > index f43c3c6171..1cef1ff339 100644
> > --- a/include/uapi/linux/virtio_gpu.h
> > +++ b/include/uapi/linux/virtio_gpu.h
> > @@ -41,6 +41,7 @@
> > #include
> >
> > #define VIRTIO_GPU_F_VIRGL 0
> > +#define VIRTIO_GPU_F_EDID 1
> >
> > enum virtio_gpu_ctrl_type {
> > VIRTIO_GPU_UNDEFINED = 0,
> > @@ -56,6 +57,7 @@ enum virtio_gpu_ctrl_type {
> > VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING,
> > VIRTIO_GPU_CMD_GET_CAPSET_INFO,
> > VIRTIO_GPU_CMD_GET_CAPSET,
> > + VIRTIO_GPU_CMD_GET_EDID,
> >
> > /* 3d commands */
> > VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
> > @@ -76,6 +78,7 @@ enum virtio_gpu_ctrl_type {
> > VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
> > VIRTIO_GPU_RESP_OK_CAPSET_INFO,
> > VIRTIO_GPU_RESP_OK_CAPSET,
> > + VIRTIO_GPU_RESP_OK_EDID,
> >
> > /* error responses */
> > VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> > @@ -291,6 +294,20 @@ struct virtio_gpu_resp_capset {
> > __u8 capset_data[];
> > };
> >
> > +/* VIRTIO_GPU_CMD_GET_EDID */
> > +struct virtio_gpu_get_edid {
> > + struct virtio_gpu_ctrl_hdr hdr;
> > + __le32 scanout;
> > +};
> > +
> > +/* VIRTIO_GPU_RESP_OK_EDID */
> > +struct virtio_gpu_resp_edid {
> > + struct virtio_gpu_ctrl_hdr hdr;
> > + __le32 scanout;
> > + __le32 size;
> > + __u8 edid[1024];
>
> Wouldn’t it be enough to stick to EDID 2.0 (256 bytes)?
>
> If not, maybe add comment to explain why you chose 1024.
EDID in the wild can be up to 512 bytes.
-Daniel
>
> > +};
> > +
> > #define VIRTIO_GPU_EVENT_DISPLAY (1 << 0)
> >
> > struct virtio_gpu_config {
> > --
> > 2.9.3
> >
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Outreachy kernel] [PATCH 0/6] drm/qxl: Remove checkpatch issues
On Fri, Oct 26, 2018 at 04:20:30PM -0300, Shayenne da Luz Moura wrote:
> This series cleans the following checkpatch.pl issues:
>
> ERROR: trailing whitespace
> WARNING: Missing a blank line after declarations
> CHECK: Please don't use multiple blank lines
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ERROR: space required before the open parenthesis '('
> CHECK: Avoid using bool structure members because of possible alignment issues
I looked through the patches, all fine, great work. I've pinged
maintainers and will merge it all as soon as they've acked it.
Assuming you want to continue hacking on gpu drivers, we have a todo list
with more advanced tasks:
https://dri.freedesktop.org/docs/drm/gpu/todo.html
Best to discuss those on #dri-devel irc before getting started, to make
sure scope and all is clear.
Cheers, Daniel
>
> Shayenne da Luz Moura (6):
> drm/qxl: Remove trailing whitespace
> drm/qxl: Add line after variable declarations
> drm/qxl: Remove exceding whiteline
> drm/qxl: Use 'unsigned int' instead of 'usigned'
> drm/qxl: Add space before open parentheses
> drm/qxl: Use 'unsigned int' instead of bool
>
> drivers/gpu/drm/qxl/qxl_cmd.c | 7 +--
> drivers/gpu/drm/qxl/qxl_debugfs.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_dev.h | 1 -
> drivers/gpu/drm/qxl/qxl_display.c | 19 ++-
> drivers/gpu/drm/qxl/qxl_draw.c| 11 ++-
> drivers/gpu/drm/qxl/qxl_drv.h | 31 ++-
> drivers/gpu/drm/qxl/qxl_dumb.c| 3 ++-
> drivers/gpu/drm/qxl/qxl_fb.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_image.c | 4 +++-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 2 ++
> drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_object.h | 2 ++
> drivers/gpu/drm/qxl/qxl_prime.c | 1 -
> drivers/gpu/drm/qxl/qxl_release.c | 1 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 12 +---
> 16 files changed, 56 insertions(+), 54 deletions(-)
>
> --
> 2.19.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/cover.1540579956.git.shayenneluzmoura%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drm/bochs: add edid support.
On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote: > On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote: > > On Mon, 29 Oct 2018, Gerd Hoffmann wrote: > > > Recent qemu (latest master branch, upcoming 3.1 release) got support > > > for EDID data. This patch adds guest driver support. > > > > > > EDID support in qemu is not (yet) enabled by default, so please use > > > 'qemu -device VGA,edid=on' for testing. > > > > Any chance of making this use drm_get_edid() (requires an i2c_adapter) > > or at least drm_do_get_edid()? > > I'll have a look at using drm_do_get_edid(). drm_get_edid() will not > fly as there is no i2c adapter in the first place. Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world flakiness of sinks (it's where all the retry logic resides), if you don't have a i2c_adapater (because the hw has some magic "give me an edid" block). For virtual hw we hopefully don't randomly drop bits on the floor between the guest and host. Imo totally fine as-is. E.g. we also don't feed the VBT edid through drm_do_get_edid either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4] drm/bochs: add edid support.
On Mon, Oct 29, 2018 at 09:50:48PM +0100, Gerd Hoffmann wrote:
> Recent qemu (latest master branch, upcoming 3.1 release) got support
> for EDID data. This patch adds guest driver support.
>
> EDID support in qemu is not (yet) enabled by default, so please use
> 'qemu -device VGA,edid=on' for testing.
>
> Signed-off-by: Gerd Hoffmann
I liked v3 more, but Acked-by: Daniel Vetter on
either wone.
-Daniel
> ---
> drivers/gpu/drm/bochs/bochs.h | 2 ++
> drivers/gpu/drm/bochs/bochs_hw.c | 30 ++
> drivers/gpu/drm/bochs/bochs_kms.c | 20 +---
> 3 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index e7a69077e4..577a8b917c 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -66,6 +66,7 @@ struct bochs_device {
> u16 yres_virtual;
> u32 stride;
> u32 bpp;
> + struct edid *edid;
>
> /* drm */
> struct drm_device *dev;
> @@ -126,6 +127,7 @@ void bochs_hw_setmode(struct bochs_device *bochs,
> const struct drm_format_info *format);
> void bochs_hw_setbase(struct bochs_device *bochs,
> int x, int y, u64 addr);
> +int bochs_hw_load_edid(struct bochs_device *bochs);
>
> /* bochs_mm.c */
> int bochs_mm_init(struct bochs_device *bochs);
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index cacff73a64..c90a0d492f 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -69,6 +69,35 @@ static void bochs_hw_set_little_endian(struct bochs_device
> *bochs)
> #define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
> #endif
>
> +static int bochs_get_edid_block(void *data, u8 *buf,
> + unsigned int block, size_t len)
> +{
> + struct bochs_device *bochs = data;
> + size_t i, start = block * EDID_LENGTH;
> +
> + if (start + len > 0x400 /* vga register offset */)
> + return -1;
> +
> + for (i = 0; i < len; i++) {
> + buf[i] = readb(bochs->mmio + start + i);
> + }
> + return 0;
> +}
> +
> +int bochs_hw_load_edid(struct bochs_device *bochs)
> +{
> + if (!bochs->mmio)
> + return -1;
> +
> + kfree(bochs->edid);
> + bochs->edid = drm_do_get_edid(>connector,
> + bochs_get_edid_block, bochs);
> + if (bochs->edid == NULL)
> + return -1;
> +
> + return 0;
> +}
> +
> int bochs_hw_init(struct drm_device *dev)
> {
> struct bochs_device *bochs = dev->dev_private;
> @@ -164,6 +193,7 @@ void bochs_hw_fini(struct drm_device *dev)
> if (bochs->fb_map)
> iounmap(bochs->fb_map);
> pci_release_regions(dev->pdev);
> + kfree(bochs->edid);
> }
>
> void bochs_hw_setmode(struct bochs_device *bochs,
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 9bc5b438ae..f87c284dd9 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
>
> static int bochs_connector_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct bochs_device *bochs =
> + container_of(connector, struct bochs_device, connector);
> + int count = 0;
>
> - count = drm_add_modes_noedid(connector, 8192, 8192);
> - drm_set_preferred_mode(connector, defx, defy);
> + if (bochs->edid)
> + count = drm_add_edid_modes(connector, bochs->edid);
> +
> + if (!count) {
> + count = drm_add_modes_noedid(connector, 8192, 8192);
> + drm_set_preferred_mode(connector, defx, defy);
> + }
> return count;
> }
>
> @@ -271,6 +278,13 @@ static void bochs_connector_init(struct drm_device *dev)
> drm_connector_helper_add(connector,
>_connector_connector_helper_funcs);
> drm_connector_register(connector);
> +
> + bochs_hw_load_edid(bochs);
> + if (bochs->edid) {
> + DRM_INFO("Found EDID data blob.\n");
> + drm_connector_attach_edid_property(connector);
> + drm_connector_update_edid_property(connector, bochs->edid);
> + }
> }
>
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drm/bochs: add edid support.
On Tue, Oct 30, 2018 at 11:28:24AM +0200, Jani Nikula wrote: > On Tue, 30 Oct 2018, Daniel Vetter wrote: > > On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote: > >> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote: > >> > On Mon, 29 Oct 2018, Gerd Hoffmann wrote: > >> > > Recent qemu (latest master branch, upcoming 3.1 release) got support > >> > > for EDID data. This patch adds guest driver support. > >> > > > >> > > EDID support in qemu is not (yet) enabled by default, so please use > >> > > 'qemu -device VGA,edid=on' for testing. > >> > > >> > Any chance of making this use drm_get_edid() (requires an i2c_adapter) > >> > or at least drm_do_get_edid()? > >> > >> I'll have a look at using drm_do_get_edid(). drm_get_edid() will not > >> fly as there is no i2c adapter in the first place. > > > > Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world > > flakiness of sinks (it's where all the retry logic resides), if you don't > > have a i2c_adapater (because the hw has some magic "give me an edid" > > block). For virtual hw we hopefully don't randomly drop bits on the floor > > between the guest and host. Imo totally fine as-is. > > > > E.g. we also don't feed the VBT edid through drm_do_get_edid either. > > But nowadays we do handle the debugfs EDID override and the EDID > firmware loading in drm_do_get_edid(), so using that gives you those > features. Oh, missed that. Would be good to clarify the kernel doc and mention this in e.g. both drm_add_edid_modes() and _connector_helper_funcs.get_modes? And maybe make it more obvious that drm_do_get_edid is also for virtual drivers, atm the kerneldoc talks a lot about DDC and everything hw. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 2/2] drm/virtio: add edid support
rq_event(vgdev->ddev);
> events_clear |= VIRTIO_GPU_EVENT_DISPLAY;
> @@ -174,6 +176,10 @@ int virtio_gpu_driver_load(struct drm_device *dev,
> unsigned long flags)
> #else
> DRM_INFO("virgl 3d acceleration not supported by guest\n");
> #endif
> + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) {
> + vgdev->has_edid = true;
> + DRM_INFO("EDID support available.\n");
> + }
>
> ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
> if (ret) {
> @@ -219,6 +225,8 @@ int virtio_gpu_driver_load(struct drm_device *dev,
> unsigned long flags)
>
> if (num_capsets)
> virtio_gpu_get_capsets(vgdev, num_capsets);
> + if (vgdev->has_edid)
> + virtio_gpu_cmd_get_edids(vgdev);
> virtio_gpu_cmd_get_display_info(vgdev);
> wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
> 5 * HZ);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 4e2e037aed..dd149a59c7 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -604,6 +604,45 @@ static void virtio_gpu_cmd_capset_cb(struct
> virtio_gpu_device *vgdev,
> wake_up(>resp_wq);
> }
>
> +static int virtio_get_edid_block(void *data, u8 *buf,
> + unsigned int block, size_t len)
> +{
> + struct virtio_gpu_resp_edid *resp = data;
> + size_t start = block * EDID_LENGTH;
> +
> + if (start + len > le32_to_cpu(resp->size))
> + return -1;
> + memcpy(buf, resp->edid + start, len);
> + return 0;
> +}
> +
> +static void virtio_gpu_cmd_get_edid_cb(struct virtio_gpu_device *vgdev,
> +struct virtio_gpu_vbuffer *vbuf)
> +{
> + struct virtio_gpu_cmd_get_edid *cmd =
> + (struct virtio_gpu_cmd_get_edid *)vbuf->buf;
> + struct virtio_gpu_resp_edid *resp =
> + (struct virtio_gpu_resp_edid *)vbuf->resp_buf;
> + uint32_t scanout = le32_to_cpu(cmd->scanout);
> + struct virtio_gpu_output *output;
> + struct edid *new_edid, *old_edid;
> +
> + if (scanout >= vgdev->num_scanouts)
> + return;
> + output = vgdev->outputs + scanout;
> +
> + new_edid = drm_do_get_edid(>conn, virtio_get_edid_block, resp);
> +
> + spin_lock(>display_info_lock);
> + old_edid = output->edid;
> + output->edid = new_edid;
> + drm_connector_update_edid_property(>conn, output->edid);
> + spin_unlock(>display_info_lock);
> +
> + kfree(old_edid);
> + wake_up(>resp_wq);
> +}
> +
> int virtio_gpu_cmd_get_display_info(struct virtio_gpu_device *vgdev)
> {
> struct virtio_gpu_ctrl_hdr *cmd_p;
> @@ -706,6 +745,34 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device
> *vgdev,
> return 0;
> }
>
> +int virtio_gpu_cmd_get_edids(struct virtio_gpu_device *vgdev)
> +{
> + struct virtio_gpu_cmd_get_edid *cmd_p;
> + struct virtio_gpu_vbuffer *vbuf;
> + void *resp_buf;
> + int scanout;
> +
> + if (WARN_ON(!vgdev->has_edid))
> + return -EINVAL;
> +
> + for (scanout = 0; scanout < vgdev->num_scanouts; scanout++) {
> + resp_buf = kzalloc(sizeof(struct virtio_gpu_resp_edid),
> +GFP_KERNEL);
> + if (!resp_buf)
> + return -ENOMEM;
> +
> + cmd_p = virtio_gpu_alloc_cmd_resp
> + (vgdev, _gpu_cmd_get_edid_cb, ,
> + sizeof(*cmd_p), sizeof(struct virtio_gpu_resp_edid),
> + resp_buf);
> + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_GET_EDID);
> + cmd_p->scanout = cpu_to_le32(scanout);
> + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> + }
> +
> + return 0;
> +}
> +
> void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t
> id,
> uint32_t nlen, const char *name)
> {
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] qxl: fix null-pointer crash during suspend
On Tue, Sep 04, 2018 at 10:27:47PM +0200, Peter Wu wrote:
> "crtc->helper_private" is not initialized by the QXL driver and thus the
This is still initialized, it's the ->disable that goes boom. At least the
call to drm_crtc_helper_add is still there. The ->disable was removed in:
commit 64581714b58bc3e16ede8dc37a025c3aa0e0eef1
Author: Laurent Pinchart
Date: Fri Jun 30 12:36:45 2017 +0300
drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()
Fixes: 64581714b58b ("drm: Convert atomic drivers from CRTC .disable() to
.atomic_disable()")
Cc: # v4.14+
Reviewed-by: Daniel Vetter
I'll let Gerd pick this one up, after some testing. Also adding Laurent.
-Daniel
> "crtc_funcs->disable" call would crash (resulting in suspend failure).
> Fix this by converting the suspend/resume functions to use the
> drm_mode_config_helper_* helpers.
>
> Tested system sleep with QEMU 3.0 using "echo mem > /sys/power/state".
> During suspend the following message is visible from QEMU:
>
> spice/server/display-channel.c:2425:display_channel_validate_surface:
> canvas address is 0x7fd05da68308 for 0 (and is NULL)
> spice/server/display-channel.c:2426:display_channel_validate_surface:
> failed on 0
>
> This seems to be triggered by QXL_IO_NOTIFY_CMD after
> QXL_IO_DESTROY_PRIMARY_ASYNC, but aside from the warning things still
> seem to work (tested with both the GTK and -spice options).
>
> Signed-off-by: Peter Wu
> ---
> Hi,
>
> I found this issue while trying to suspend a VM that uses QXL. In order to see
> the stack trace over serial, boot with no_console_suspend. Searching for
> "qxl_drm_freeze" showed one recent report from Alan:
> https://lkml.kernel.org/r/891e334c-cf19-032c-b996-59ac166fc...@gmail.com
>
> Kind regards,
> Peter
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 26 +-
> 1 file changed, 5 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 2445e75cf7ea..d00f45eed03c 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -136,20 +136,11 @@ static int qxl_drm_freeze(struct drm_device *dev)
> {
> struct pci_dev *pdev = dev->pdev;
> struct qxl_device *qdev = dev->dev_private;
> - struct drm_crtc *crtc;
> -
> - drm_kms_helper_poll_disable(dev);
> -
> - console_lock();
> - qxl_fbdev_set_suspend(qdev, 1);
> - console_unlock();
> + int ret;
>
> - /* unpin the front buffers */
> - list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> - const struct drm_crtc_helper_funcs *crtc_funcs =
> crtc->helper_private;
> - if (crtc->enabled)
> - (*crtc_funcs->disable)(crtc);
> - }
> + ret = drm_mode_config_helper_suspend(dev);
> + if (ret)
> + return ret;
>
> qxl_destroy_monitors_object(qdev);
> qxl_surf_evict(qdev);
> @@ -175,14 +166,7 @@ static int qxl_drm_resume(struct drm_device *dev, bool
> thaw)
> }
>
> qxl_create_monitors_object(qdev);
> - drm_helper_resume_force_mode(dev);
> -
> - console_lock();
> - qxl_fbdev_set_suspend(qdev, 0);
> - console_unlock();
> -
> - drm_kms_helper_poll_enable(dev);
> - return 0;
> + return drm_mode_config_helper_resume(dev);
> }
>
> static int qxl_pm_suspend(struct device *dev)
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 00/13] remove_conflicting_framebuffers() cleanup
On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote: > This series cleans up duplicated code for replacing firmware FB > driver with proper DRI driver and adds handover support to > Tegra driver. > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > --- > v2: > - rebased on current drm-next > - dropped staging/sm750fb changes > - added kernel docs for DRM helpers > v3: > - move kerneldoc to fbdev, where functions are implemented > - split kerneldoc for remove_conflicting_framebuffers() Ah, that's not quite what I had in mind. I think having the docs (also) in the drm helpers would be good, since that's where drm people will look, and that's the function they'll call. I just wanted you to split the fbdev and drm parts into 2 patches (since those are two different maintainers). Anyway, this is ok too, so imo ready for merging. If you can resurrect the drm docs (with a patch title of "drm/fb-helper: document fbdev remove functions" or similar) that would be great. Only thing we need for merging now is the ack from Bartlomiej. -Daniel > - propagate return value in remove_conflicting_pci_framebuffers() > > --- > Michał Mirosław (13): > fbdev: show fbdev number for debugging > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > fbdev: add kerneldoc do remove_conflicting_framebuffers() > fbdev: add remove_conflicting_pci_framebuffers() > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > drm/tegra: kick out simplefb > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 + > drivers/gpu/drm/bochs/bochs_drv.c| 18 +-- > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 + > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 +--- > drivers/gpu/drm/mgag200/mgag200_main.c | 9 > drivers/gpu/drm/radeon/radeon_drv.c | 23 + > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +-- > drivers/gpu/drm/tegra/drm.c | 4 ++ > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 ++--- > drivers/video/fbdev/core/fbmem.c | 63 +++- > include/drm/drm_fb_helper.h | 12 + > include/linux/fb.h | 2 + > 13 files changed, 89 insertions(+), 172 deletions(-) > > -- > 2.18.0 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 00/13] remove_conflicting_framebuffers() cleanup
On Mon, Sep 03, 2018 at 01:31:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote: > > On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote: > > > This series cleans up duplicated code for replacing firmware FB > > > driver with proper DRI driver and adds handover support to > > > Tegra driver. > > > > > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > > > > > --- > > > v2: > > > - rebased on current drm-next > > > - dropped staging/sm750fb changes > > > - added kernel docs for DRM helpers > > > v3: > > > - move kerneldoc to fbdev, where functions are implemented > > > - split kerneldoc for remove_conflicting_framebuffers() > > > > Ah, that's not quite what I had in mind. I think having the docs (also) in > > the drm helpers would be good, since that's where drm people will look, > > and that's the function they'll call. I just wanted you to split the fbdev > > and drm parts into 2 patches (since those are two different maintainers). > > > > Anyway, this is ok too, so imo ready for merging. If you can resurrect the > > drm docs (with a patch title of "drm/fb-helper: document fbdev remove > > functions" or similar) that would be great. > > > > Only thing we need for merging now is the ack from Bartlomiej. > > For the whole patchset: > > Acked-by: Bartlomiej Zolnierkiewicz Thanks, entire patch set applied to drm-misc-next for 4.20. -Daniel > > > -Daniel > > > > > - propagate return value in remove_conflicting_pci_framebuffers() > > > > > > --- > > > Michał Mirosław (13): > > > fbdev: show fbdev number for debugging > > > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > > > fbdev: add kerneldoc do remove_conflicting_framebuffers() > > > fbdev: add remove_conflicting_pci_framebuffers() > > > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > > > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > > > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > > > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > > > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > > > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > > > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > > > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > > > drm/tegra: kick out simplefb > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 + > > > drivers/gpu/drm/bochs/bochs_drv.c| 18 +-- > > > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 + > > > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 +--- > > > drivers/gpu/drm/mgag200/mgag200_main.c | 9 > > > drivers/gpu/drm/radeon/radeon_drv.c | 23 + > > > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +-- > > > drivers/gpu/drm/tegra/drm.c | 4 ++ > > > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > > > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 ++--- > > > drivers/video/fbdev/core/fbmem.c | 63 +++- > > > include/drm/drm_fb_helper.h | 12 + > > > include/linux/fb.h | 2 + > > > 13 files changed, 89 insertions(+), 172 deletions(-) > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 04/13] fbdev: add remove_conflicting_pci_framebuffers()
On Sat, Sep 01, 2018 at 04:08:45PM +0200, Michał Mirosław wrote:
> Almost all PCI drivers using remove_conflicting_framebuffers() wrap it
> with the same code.
>
> ---
This cuts away the sob. Just fyi.
-Daniel
> v2: add kerneldoc for DRM helper
> v3: propagate remove_conflicting_framebuffers() return value
> + move kerneldoc to where function is implemented
>
> Signed-off-by: Michał Mirosław
> ---
> drivers/video/fbdev/core/fbmem.c | 35
> include/drm/drm_fb_helper.h | 12 +++
> include/linux/fb.h | 2 ++
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 2de93b5014e3..cd96b1c62bbe 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1812,6 +1813,40 @@ int remove_conflicting_framebuffers(struct
> apertures_struct *a,
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> +/**
> + * remove_conflicting_pci_framebuffers - remove firmware-configured
> framebuffers for PCI devices
> + * @pdev: PCI device
> + * @resource_id: index of PCI BAR configuring framebuffer memory
> + * @name: requesting driver name
> + *
> + * This function removes framebuffer devices (eg. initialized by firmware)
> + * using memory range configured for @pdev's BAR @resource_id.
> + *
> + * The function assumes that PCI device with shadowed ROM drives a primary
> + * display and so kicks out vga16fb.
> + */
> +int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id,
> const char *name)
> +{
> + struct apertures_struct *ap;
> + bool primary = false;
> + int err;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return -ENOMEM;
> +
> + ap->ranges[0].base = pci_resource_start(pdev, res_id);
> + ap->ranges[0].size = pci_resource_len(pdev, res_id);
> +#ifdef CONFIG_X86
> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> + IORESOURCE_ROM_SHADOW;
> +#endif
> + err = remove_conflicting_framebuffers(ap, name, primary);
> + kfree(ap);
> + return err;
> +}
> +EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
> +
> /**
> * register_framebuffer - registers a frame buffer device
> * @fb_info: frame buffer info structure
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index b069433e7fc1..20ea856db900 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -577,4 +577,16 @@ drm_fb_helper_remove_conflicting_framebuffers(struct
> apertures_struct *a,
> #endif
> }
>
> +static inline int
> +drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> + int resource_id,
> + const char *name)
> +{
> +#if IS_REACHABLE(CONFIG_FB)
> + return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
> +#else
> + return 0;
> +#endif
> +}
> +
> #endif
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index aa74a228bb92..abeffd55b66a 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -632,6 +632,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const
> char __user *buf,
> extern int register_framebuffer(struct fb_info *fb_info);
> extern int unregister_framebuffer(struct fb_info *fb_info);
> extern int unlink_framebuffer(struct fb_info *fb_info);
> +extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int
> res_id,
> +const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
On Tue, Dec 18, 2018 at 10:27:47AM +0100, Benjamin Gaignard wrote: > Le lun. 17 déc. 2018 à 21:48, Rodrigo Vivi a écrit : > > > > On Mon, Dec 17, 2018 at 08:43:03PM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > > confusing. Split them out. > > > > > > To make sure I actually achieved the goal here I went through all > > > drivers. And indeed, all atomic drivers are now free of > > > drm_crtc_helper.h includes. > > > > > > v2: Make it compile. There was so much compile fail on arm drivers > > > that I figured I'll better not include any of the acks on v1. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: linux-arm-ker...@lists.infradead.org > > > Cc: virtualization@lists.linux-foundation.org > > > Cc: etna...@lists.freedesktop.org > > > Cc: linux-samsung-...@vger.kernel.org > > > Cc: intel-...@lists.freedesktop.org > > > > Acked-by: Rodrigo Vivi > > With this version I'm able to compile sti driver so, > > Acked-by: Benjamin Gaignard I merged the first 3 patches, but now I'm stuck because I'm missing review on patches 5&6. Anyone volunteering? Thanks, Daniel > > > > > > Cc: linux-media...@lists.infradead.org > > > Cc: linux-amlo...@lists.infradead.org > > > Cc: linux-arm-...@vger.kernel.org > > > Cc: freedr...@lists.freedesktop.org > > > Cc: nouv...@lists.freedesktop.org > > > Cc: spice-de...@lists.freedesktop.org > > > Cc: amd-...@lists.freedesktop.org > > > Cc: linux-renesas-...@vger.kernel.org > > > Cc: linux-rockc...@lists.infradead.org > > > Cc: linux-st...@st-md-mailman.stormreply.com > > > Cc: linux-te...@vger.kernel.org > > > Cc: xen-de...@lists.xen.org > > > --- > > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > > drivers/gpu/drm/armada/armada_crtc.h | 2 + > > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 5 +- > > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- > > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > > drivers/gpu/drm/bridge/panel.c| 2 +- > > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > > drivers/gpu/drm/bridge/ti-tfp410.c| 2
Re: [PATCH] drm/cirrus: fix connector leak at unload
On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
>
> Signed-off-by: Rob Clark
> ---
> Similar case to the issue that was fixed recently in drm/ast
Reviewed-by: Daniel Vetter
>
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 4dd499c7d1ba..bb379ec4c182 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -256,6 +256,8 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
> {
> struct drm_framebuffer *gfb = gfbdev->gfb;
>
> + drm_crtc_force_disable_all(dev);
> +
> drm_fb_helper_unregister_fbi(>helper);
>
> vfree(gfbdev->sysram);
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically Cc: Sam Ravnborg Cc: Jani Nikula Cc: Laurent Pinchart Acked-by: Rodrigo Vivi Acked-by: Benjamin Gaignard Acked-by: Jani Nikula Acked-by: Neil Armstrong Acked-by: Oleksandr Andrushchenko Acked-by: CK Hu Acked-by: Alex Deucher Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_crtc.h | 2 ++ drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/exynos/exynos_dp.c| 3 ++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/
Re: [Spice-devel] [PATCH 1/3] drm/qxl: add mode/framebuffer check functions
On Wed, Jan 16, 2019 at 12:28:00PM +0100, Gerd Hoffmann wrote:
> > > +static int qxl_check_mode(struct qxl_device *qdev,
> > > + unsigned int width,
> > > + unsigned int height)
> > > +{
> > > + if (width * height * 4 > qdev->vram_size)
> >
> > Is someone checking for integer overflows already?
>
> Need to have a look. This is just ...
The addfb ioctl checks for integer overflows for you.
-Daniel
>
> > > - if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
> > > - DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
> > > - return -EINVAL;
> > > - }
>
> ... that check moved into the new function.
>
> cheers,
> Gerd
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. Cc: Sam Ravnborg Cc: Jani Nikula Cc: Laurent Pinchart Acked-by: Rodrigo Vivi Acked-by: Benjamin Gaignard Acked-by: Jani Nikula Acked-by: Neil Armstrong Acked-by: Oleksandr Andrushchenko Acked-by: CK Hu Acked-by: Alex Deucher Reviewed-by: Laurent Pinchart Acked-by: Liviu Dudau Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++--- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-- drivers/gpu/drm/arm/hdlcd_drv.c | 4 +-- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_crtc.h | 2 ++ drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + drivers/gpu/drm/bridge/analogix-anx78xx.c | 2 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/exynos/exynos_dp.c| 3 ++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/
