Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1206456 > unrolled thread

Raspberry Pi KMS-only driver

Back to article view | Back to linux.kernel

Contents

  Raspberry Pi KMS-only driver Eric Anholt <eric@anholt.net> - 2015-08-13 03:00 +0200
    Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Emil Velikov <emil.l.velikov@gmail.com> - 2015-08-13 13:50 +0200
    Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Eric Anholt <eric@anholt.net> - 2015-08-13 22:50 +0200
      Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Daniel Vetter <daniel@ffwll.ch> - 2015-08-13 23:20 +0200
        Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Eric Anholt <eric@anholt.net> - 2015-08-18 23:00 +0200
      Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-08-13 23:30 +0200
        Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Eric Anholt <eric@anholt.net> - 2015-08-14 01:10 +0200
    Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Stephen Warren <swarren@wwwdotorg.org> - 2015-08-15 06:50 +0200
      Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi. Eric Anholt <eric@anholt.net> - 2015-08-17 20:00 +0200

#1206456 — Raspberry Pi KMS-only driver

Here's the first patch series for graphics on the Raspberry Pi.  It
brings up fbcon on KMS, and the xf86-video-modesetting driver runs so
you can do X with no further userspace drivers.

Right now this series doesn't support changing video modes away from
the firmware boot setup, because when I set the pixel clock using the
rpi-dt-clocks series I end up with a black display. even on no-op
modesets.

I've dropped all of the 3D bits from this series, to simplify this
review stage.  See vc4-kms-v3d-rpi2 for a series that works with the
current Mesa driver, based on downstream 2709.  I squashed all of my
messy KMS series down, but kept Derek's patches separate to make sure
he gets credit.

This code can also be found at:

https://github.com/anholt/linux/tree/vc4-kms-squash

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1206761 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

On 13 August 2015 at 01:56, Eric Anholt <eric@anholt.net> wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
...
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -0,0 +1,18 @@
> +ccflags-y := -Iinclude/drm
> +
> +# Please keep these build lists sorted!
> +
> +# core driver code
> +vc4-y := \
> +       vc4_bo.o \
> +       vc4_crtc.o \
> +       vc4_drv.o \
> +       vc4_kms.o \
> +       vc4_hdmi.o \
> +       vc4_hvs.o \
> +       vc4_plane.o \
> +       $()
> +
In case anyone is curious - this is the first sentinel in the whole
kernel (some 2000+ Makefiles) :-)

-Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1207158 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Multipart message — attachments visible in raw view] — view raw

Daniel Vetter <daniel@ffwll.ch> writes:

> On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
>> This is the start of a full VC4 driver.  Right now this just supports
>> configuring the display using a pre-existing video mode (because
>> changing the pixel clock isn't available yet, and doesn't work when it
>> is).  However, this is enough for fbcon and bringing up X using
>> xf86-video-modesetting.
>> 
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>  drivers/gpu/drm/Kconfig           |   2 +
>>  drivers/gpu/drm/Makefile          |   1 +
>>  drivers/gpu/drm/vc4/Kconfig       |  14 +
>>  drivers/gpu/drm/vc4/Makefile      |  18 ++
>>  drivers/gpu/drm/vc4/vc4_bo.c      |  54 ++++
>>  drivers/gpu/drm/vc4/vc4_crtc.c    | 583 ++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
>>  drivers/gpu/drm/vc4/vc4_drv.c     | 249 +++++++++++++++
>>  drivers/gpu/drm/vc4/vc4_drv.h     | 123 +++++++
>>  drivers/gpu/drm/vc4/vc4_hdmi.c    | 651 ++++++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/vc4/vc4_hvs.c     | 172 ++++++++++
>>  drivers/gpu/drm/vc4/vc4_kms.c     |  84 +++++
>>  drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++++++++++++++++++
>>  drivers/gpu/drm/vc4/vc4_regs.h    | 562 ++++++++++++++++++++++++++++++++
>>  14 files changed, 2871 insertions(+)
>>  create mode 100644 drivers/gpu/drm/vc4/Kconfig
>>  create mode 100644 drivers/gpu/drm/vc4/Makefile
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
>>  create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
>
> Made a quick pass and found a few things to update to latest drm
> developments. Of course didn't look at the hardware details since no clue,
> but looks really nice overall.
> -Daniel

If you have anything about the hardware that you were curious about, I'd
be interested in trying to explain them in the comments to the extent
that I can.  It's unfortunate that we haven't shipped docs for the
display side of things, but had to do a lot of reading of the verilog
just to get this far, anyway.

>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index c46ca31..1730a76 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -240,3 +240,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>>  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>>  
>>  source "drivers/gpu/drm/imx/Kconfig"
>> +
>> +source "drivers/gpu/drm/vc4/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 5713d05..b991ac5 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)	+= mga/
>>  obj-$(CONFIG_DRM_I810)	+= i810/
>>  obj-$(CONFIG_DRM_I915)  += i915/
>>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
>> +obj-$(CONFIG_DRM_VC4)  += vc4/
>>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>>  obj-$(CONFIG_DRM_SIS)   += sis/
>>  obj-$(CONFIG_DRM_SAVAGE)+= savage/
>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>> new file mode 100644
>> index 0000000..130cc94
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/Kconfig
>> @@ -0,0 +1,14 @@
>> +config DRM_VC4
>> +	tristate "Broadcom VC4 Graphics"
>> +	depends on ARCH_BCM2835
>> +	depends on DRM
>> +	select DRM_KMS_HELPER
>> +	select DRM_KMS_FB_HELPER
>> +	select DRM_KMS_CMA_HELPER
>
> drm-misc/linux-next already has Archit's patches to enable/disable fbdev
> in the core code, so you don't need to bother about these selects here any
> more, it'll no-op out if drm fbdev emulation isn't enabled. Since you're
> reusing cma fbdev helpers I don't think there's any need for other changes
> because of this.

It sounds like I should rebase on that, then?

>> +	help
>> +	  Choose this option if you have a system that has a Broadcom
>> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
>> +
>> +	  This driver requires that "avoid_warnings=2" be present in
>> +	  the config.txt for the firmware, to keep it from smashing
>> +	  our display setup.
>> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
>> new file mode 100644
>> index 0000000..4aa07ca
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/Makefile
>> @@ -0,0 +1,18 @@
>> +ccflags-y := -Iinclude/drm
>> +
>> +# Please keep these build lists sorted!
>> +
>> +# core driver code
>> +vc4-y := \
>> +	vc4_bo.o \
>> +	vc4_crtc.o \
>> +	vc4_drv.o \
>> +	vc4_kms.o \
>> +	vc4_hdmi.o \
>> +	vc4_hvs.o \
>> +	vc4_plane.o \
>> +	$()
>> +
>> +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
>> +
>> +obj-$(CONFIG_DRM_VC4)  += vc4.o
>> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
>> new file mode 100644
>> index 0000000..fee8cac
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
>> @@ -0,0 +1,54 @@
>> +/*
>> + *  Copyright © 2015 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +/* DOC: VC4 GEM BO management support.
>> + *
>> + * The VC4 GPU architecture (both scanout and rendering) has direct
>> + * access to system memory with no MMU in between.  To support it, we
>> + * use the GEM CMA helper functions to allocate contiguous ranges of
>> + * physical memory for our BOs.
>> + */
>
> Since you're doing kerneldoc considered pulling it all into a new vc4
> section in the drm docbook template?

I hadn't found the docbook template.  Interesting.  I'll try to cook up
some general vc4 docs for that.  I think that could be a separate
commit, though?

>> +
>> +#include "vc4_drv.h"
>> +
>> +struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
>> +{
>> +	struct drm_gem_cma_object *cma_obj;
>> +
>> +	cma_obj = drm_gem_cma_create(dev, size);
>> +	if (IS_ERR(cma_obj))
>> +		return NULL;
>> +	else
>> +		return to_vc4_bo(&cma_obj->base);
>> +}
>> +
>> +int vc4_dumb_create(struct drm_file *file_priv,
>> +		    struct drm_device *dev,
>> +		    struct drm_mode_create_dumb *args)
>> +{
>> +	int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> +	struct vc4_bo *bo = NULL;
>> +	int ret;
>> +
>> +	if (args->pitch < min_pitch)
>> +		args->pitch = min_pitch;
>> +
>> +	if (args->size < args->pitch * args->height)
>> +		args->size = args->pitch * args->height;
>> +
>> +	mutex_lock(&dev->struct_mutex);
>> +	bo = vc4_bo_create(dev, roundup(args->size, PAGE_SIZE));
>> +	mutex_unlock(&dev->struct_mutex);
>
> I'm on a struct_mutex crusade (trying to get rid of it in core and allow
> drivers to live without it). On a quick look there doesn't seem to be
> anything that needs struct_mutex here, so please just remove it. If there
> is indeed something vc4-internal you want to protect, please use your own
> driver-internal mutex (e.g. for drm_mm or command submission or whatever).
>
> btw the last bit in the drm core for modern drivers that needs
> struct_mutex is mmap_offset gem object lookup. I plan to replace that with
> kref_get_unless_zero trickery, which would make the core and a lot of
> drivers struct_mutex free and so relegate it mostly to a legacy role (and
> can be forgotten).

Struct mutex is here because this code is from the V3D series, with the
in-kernel BO cache ripped out (it turns out that the CMA allocator is
slow, and you can't just userspace cache since we have to do allocations
within the kernel to the tune of a couple per draw and that's too much).

I'll pull the mutex calls out for now until the cache stuff is
submitted.

>> +static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
>> +				const struct drm_display_mode *mode,
>> +				struct drm_display_mode *adjusted_mode)
>> +{
>> +	return true;
>> +}
>
> mode_fixup on crtcs is optional since 840bfe953384a and I just merged a
> patch to make it optional for encoders too (when using atomic helpers
> which you do). You can remove them both.

Great!  It felt like there was a *lot* of boilerplate when I was first
writing this stuff, and things are way better than they used to be.

>> +static int vc4_drm_load(struct drm_device *dev, unsigned long flags)
>> +{
>> +	struct vc4_dev *vc4;
>> +	int ret;
>> +
>> +	vc4 = devm_kzalloc(dev->dev, sizeof(*vc4), GFP_KERNEL);
>> +	if (!vc4)
>> +		return -ENOMEM;
>> +
>> +	dev_set_drvdata(dev->dev, dev);
>> +	vc4->dev = dev;
>> +	dev->dev_private = vc4;
>> +
>> +	drm_mode_config_init(dev);
>> +
>> +	ret = component_bind_all(dev->dev, dev);
>> +	if (ret)
>> +		return ret;
>> +
>> +	vc4_kms_load(dev);
>> +
>> +	return 0;
>> +}
>
> ->load has backwards init ordering (we register public interfaces before
> calling it, yay) because backwards compat. Hence deprecated, please use
> drm_dev_alloc(); ... driver init including drm_dev_set_unique();
> drm_dev_register(); instead and drop ->load.

Will do.

[toc] | [prev] | [next] | [standalone]

#1207170 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
> 
> > On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
> >> This is the start of a full VC4 driver.  Right now this just supports
> >> configuring the display using a pre-existing video mode (because
> >> changing the pixel clock isn't available yet, and doesn't work when it
> >> is).  However, this is enough for fbcon and bringing up X using
> >> xf86-video-modesetting.
> >> 
> >> Signed-off-by: Eric Anholt <eric@anholt.net>
> >> ---
> >>  drivers/gpu/drm/Kconfig           |   2 +
> >>  drivers/gpu/drm/Makefile          |   1 +
> >>  drivers/gpu/drm/vc4/Kconfig       |  14 +
> >>  drivers/gpu/drm/vc4/Makefile      |  18 ++
> >>  drivers/gpu/drm/vc4/vc4_bo.c      |  54 ++++
> >>  drivers/gpu/drm/vc4/vc4_crtc.c    | 583 ++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
> >>  drivers/gpu/drm/vc4/vc4_drv.c     | 249 +++++++++++++++
> >>  drivers/gpu/drm/vc4/vc4_drv.h     | 123 +++++++
> >>  drivers/gpu/drm/vc4/vc4_hdmi.c    | 651 ++++++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/vc4/vc4_hvs.c     | 172 ++++++++++
> >>  drivers/gpu/drm/vc4/vc4_kms.c     |  84 +++++
> >>  drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++++++++++++++++++
> >>  drivers/gpu/drm/vc4/vc4_regs.h    | 562 ++++++++++++++++++++++++++++++++
> >>  14 files changed, 2871 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/vc4/Kconfig
> >>  create mode 100644 drivers/gpu/drm/vc4/Makefile
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
> >
> > Made a quick pass and found a few things to update to latest drm
> > developments. Of course didn't look at the hardware details since no clue,
> > but looks really nice overall.
> 
> If you have anything about the hardware that you were curious about, I'd
> be interested in trying to explain them in the comments to the extent
> that I can.  It's unfortunate that we haven't shipped docs for the
> display side of things, but had to do a lot of reading of the verilog
> just to get this far, anyway.

The only thing I spotted is that you right now only register a primary and
cursor plane. I guess the plan we once discussed about exposing piles of
planes for -modesetting accel isn't there yet?

But otherwise I really didn't go into the hardware details.

> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index c46ca31..1730a76 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -240,3 +240,5 @@ source "drivers/gpu/drm/sti/Kconfig"
> >>  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
> >>  
> >>  source "drivers/gpu/drm/imx/Kconfig"
> >> +
> >> +source "drivers/gpu/drm/vc4/Kconfig"
> >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> >> index 5713d05..b991ac5 100644
> >> --- a/drivers/gpu/drm/Makefile
> >> +++ b/drivers/gpu/drm/Makefile
> >> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)	+= mga/
> >>  obj-$(CONFIG_DRM_I810)	+= i810/
> >>  obj-$(CONFIG_DRM_I915)  += i915/
> >>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
> >> +obj-$(CONFIG_DRM_VC4)  += vc4/
> >>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> >>  obj-$(CONFIG_DRM_SIS)   += sis/
> >>  obj-$(CONFIG_DRM_SAVAGE)+= savage/
> >> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> >> new file mode 100644
> >> index 0000000..130cc94
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/vc4/Kconfig
> >> @@ -0,0 +1,14 @@
> >> +config DRM_VC4
> >> +	tristate "Broadcom VC4 Graphics"
> >> +	depends on ARCH_BCM2835
> >> +	depends on DRM
> >> +	select DRM_KMS_HELPER
> >> +	select DRM_KMS_FB_HELPER
> >> +	select DRM_KMS_CMA_HELPER
> >
> > drm-misc/linux-next already has Archit's patches to enable/disable fbdev
> > in the core code, so you don't need to bother about these selects here any
> > more, it'll no-op out if drm fbdev emulation isn't enabled. Since you're
> > reusing cma fbdev helpers I don't think there's any need for other changes
> > because of this.
> 
> It sounds like I should rebase on that, then?

Yeah probably simplest. I made a pull request for drm-misc and a tag and
cc'ed you on it so you have a baseline.

> >> +	help
> >> +	  Choose this option if you have a system that has a Broadcom
> >> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
> >> +
> >> +	  This driver requires that "avoid_warnings=2" be present in
> >> +	  the config.txt for the firmware, to keep it from smashing
> >> +	  our display setup.
> >> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> >> new file mode 100644
> >> index 0000000..4aa07ca
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/vc4/Makefile
> >> @@ -0,0 +1,18 @@
> >> +ccflags-y := -Iinclude/drm
> >> +
> >> +# Please keep these build lists sorted!
> >> +
> >> +# core driver code
> >> +vc4-y := \
> >> +	vc4_bo.o \
> >> +	vc4_crtc.o \
> >> +	vc4_drv.o \
> >> +	vc4_kms.o \
> >> +	vc4_hdmi.o \
> >> +	vc4_hvs.o \
> >> +	vc4_plane.o \
> >> +	$()
> >> +
> >> +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
> >> +
> >> +obj-$(CONFIG_DRM_VC4)  += vc4.o
> >> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> >> new file mode 100644
> >> index 0000000..fee8cac
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> >> @@ -0,0 +1,54 @@
> >> +/*
> >> + *  Copyright © 2015 Broadcom
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +
> >> +/* DOC: VC4 GEM BO management support.
> >> + *
> >> + * The VC4 GPU architecture (both scanout and rendering) has direct
> >> + * access to system memory with no MMU in between.  To support it, we
> >> + * use the GEM CMA helper functions to allocate contiguous ranges of
> >> + * physical memory for our BOs.
> >> + */
> >
> > Since you're doing kerneldoc considered pulling it all into a new vc4
> > section in the drm docbook template?
> 
> I hadn't found the docbook template.  Interesting.  I'll try to cook up
> some general vc4 docs for that.  I think that could be a separate
> commit, though?

Sure. Really just for yourself and other people hacking on this. btw
there's some work intel sponsors from collabora to improve kerneldoc
comments with automated hyperlinking, markdown and a few other things. But
unfortunately not yet merged.

> >> +
> >> +#include "vc4_drv.h"
> >> +
> >> +struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
> >> +{
> >> +	struct drm_gem_cma_object *cma_obj;
> >> +
> >> +	cma_obj = drm_gem_cma_create(dev, size);
> >> +	if (IS_ERR(cma_obj))
> >> +		return NULL;
> >> +	else
> >> +		return to_vc4_bo(&cma_obj->base);
> >> +}
> >> +
> >> +int vc4_dumb_create(struct drm_file *file_priv,
> >> +		    struct drm_device *dev,
> >> +		    struct drm_mode_create_dumb *args)
> >> +{
> >> +	int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> >> +	struct vc4_bo *bo = NULL;
> >> +	int ret;
> >> +
> >> +	if (args->pitch < min_pitch)
> >> +		args->pitch = min_pitch;
> >> +
> >> +	if (args->size < args->pitch * args->height)
> >> +		args->size = args->pitch * args->height;
> >> +
> >> +	mutex_lock(&dev->struct_mutex);
> >> +	bo = vc4_bo_create(dev, roundup(args->size, PAGE_SIZE));
> >> +	mutex_unlock(&dev->struct_mutex);
> >
> > I'm on a struct_mutex crusade (trying to get rid of it in core and allow
> > drivers to live without it). On a quick look there doesn't seem to be
> > anything that needs struct_mutex here, so please just remove it. If there
> > is indeed something vc4-internal you want to protect, please use your own
> > driver-internal mutex (e.g. for drm_mm or command submission or whatever).
> >
> > btw the last bit in the drm core for modern drivers that needs
> > struct_mutex is mmap_offset gem object lookup. I plan to replace that with
> > kref_get_unless_zero trickery, which would make the core and a lot of
> > drivers struct_mutex free and so relegate it mostly to a legacy role (and
> > can be forgotten).
> 
> Struct mutex is here because this code is from the V3D series, with the
> in-kernel BO cache ripped out (it turns out that the CMA allocator is
> slow, and you can't just userspace cache since we have to do allocations
> within the kernel to the tune of a couple per draw and that's too much).
> 
> I'll pull the mutex calls out for now until the cache stuff is
> submitted.

Yeah I suspected that's for later. If feasible it'd be great if you could
rearchtect it to use a driver-private lock, just to not grow another place
using it.

> >> +static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
> >> +				const struct drm_display_mode *mode,
> >> +				struct drm_display_mode *adjusted_mode)
> >> +{
> >> +	return true;
> >> +}
> >
> > mode_fixup on crtcs is optional since 840bfe953384a and I just merged a
> > patch to make it optional for encoders too (when using atomic helpers
> > which you do). You can remove them both.
> 
> Great!  It felt like there was a *lot* of boilerplate when I was first
> writing this stuff, and things are way better than they used to be.

Just noticed that crtc->atomic_begin is optional too. btw if you spot
boilerplate somewhere else please raise it on irc, there's still a lot of
room for improvement for atomic helpers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209474 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Multipart message — attachments visible in raw view] — view raw

Daniel Vetter <daniel@ffwll.ch> writes:

> On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
>> Daniel Vetter <daniel@ffwll.ch> writes:
>> 
>> > On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
>> >> This is the start of a full VC4 driver.  Right now this just supports
>> >> configuring the display using a pre-existing video mode (because
>> >> changing the pixel clock isn't available yet, and doesn't work when it
>> >> is).  However, this is enough for fbcon and bringing up X using
>> >> xf86-video-modesetting.
>> >> 
>> >> Signed-off-by: Eric Anholt <eric@anholt.net>
>> >> ---
>> >>  drivers/gpu/drm/Kconfig           |   2 +
>> >>  drivers/gpu/drm/Makefile          |   1 +
>> >>  drivers/gpu/drm/vc4/Kconfig       |  14 +
>> >>  drivers/gpu/drm/vc4/Makefile      |  18 ++
>> >>  drivers/gpu/drm/vc4/vc4_bo.c      |  54 ++++
>> >>  drivers/gpu/drm/vc4/vc4_crtc.c    | 583 ++++++++++++++++++++++++++++++++++
>> >>  drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
>> >>  drivers/gpu/drm/vc4/vc4_drv.c     | 249 +++++++++++++++
>> >>  drivers/gpu/drm/vc4/vc4_drv.h     | 123 +++++++
>> >>  drivers/gpu/drm/vc4/vc4_hdmi.c    | 651 ++++++++++++++++++++++++++++++++++++++
>> >>  drivers/gpu/drm/vc4/vc4_hvs.c     | 172 ++++++++++
>> >>  drivers/gpu/drm/vc4/vc4_kms.c     |  84 +++++
>> >>  drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++++++++++++++++++
>> >>  drivers/gpu/drm/vc4/vc4_regs.h    | 562 ++++++++++++++++++++++++++++++++
>> >>  14 files changed, 2871 insertions(+)
>> >>  create mode 100644 drivers/gpu/drm/vc4/Kconfig
>> >>  create mode 100644 drivers/gpu/drm/vc4/Makefile
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
>> >>  create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
>> >
>> > Made a quick pass and found a few things to update to latest drm
>> > developments. Of course didn't look at the hardware details since no clue,
>> > but looks really nice overall.
>> 
>> If you have anything about the hardware that you were curious about, I'd
>> be interested in trying to explain them in the comments to the extent
>> that I can.  It's unfortunate that we haven't shipped docs for the
>> display side of things, but had to do a lot of reading of the verilog
>> just to get this far, anyway.
>
> The only thing I spotted is that you right now only register a primary and
> cursor plane. I guess the plan we once discussed about exposing piles of
> planes for -modesetting accel isn't there yet?
>
> But otherwise I really didn't go into the hardware details.

Yeah, I haven't done piles of planes because what we have right now
means I don't have to do the bandwidth limits tracking yet.

[toc] | [prev] | [next] | [standalone]

#1207177 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
> Struct mutex is here because this code is from the V3D series, with the
> in-kernel BO cache ripped out (it turns out that the CMA allocator is
> slow, and you can't just userspace cache since we have to do allocations
> within the kernel to the tune of a couple per draw and that's too much).

The CMA allocator is fast until you have pinned pages in its region,
where it becomes _very_ slow to do allocations, sometimes getting up
to the order of seconds.

The main culpret of this are GFP_HIGHUSER_MOVABLE allocations which
then pin the page.  It doesn't take many of those to make CMA really
inefficient.

The problem is that CMA doesn't get any information back from the
internal page migration about which pages couldn't be moved, so it
dumbly just tries incrementing the allocation by one page (subject
to alignment constraints) and retrying again - repeating over the
entire CMA region.  The bigger the region, the more time this takes.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1207224 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Multipart message — attachments visible in raw view] — view raw

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
>> Struct mutex is here because this code is from the V3D series, with the
>> in-kernel BO cache ripped out (it turns out that the CMA allocator is
>> slow, and you can't just userspace cache since we have to do allocations
>> within the kernel to the tune of a couple per draw and that's too much).
>
> The CMA allocator is fast until you have pinned pages in its region,
> where it becomes _very_ slow to do allocations, sometimes getting up
> to the order of seconds.
>
> The main culpret of this are GFP_HIGHUSER_MOVABLE allocations which
> then pin the page.  It doesn't take many of those to make CMA really
> inefficient.
>
> The problem is that CMA doesn't get any information back from the
> internal page migration about which pages couldn't be moved, so it
> dumbly just tries incrementing the allocation by one page (subject
> to alignment constraints) and retrying again - repeating over the
> entire CMA region.  The bigger the region, the more time this takes.

Ouch.

Since I can workaround the allocation cost, the main problem I have
right now is that I've got a set of small allocations for 3D that all
need to have the same high 4 bits of paddr, because someone cleverly
packed some address bits in a GPU-managed structure.  Any
recommendations for ways to handle this with CMA?

[toc] | [prev] | [next] | [standalone]

#1208014 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

On 08/12/2015 06:56 PM, Eric Anholt wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.

> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig

> +config DRM_VC4
> +	tristate "Broadcom VC4 Graphics"

> +	help
> +	  Choose this option if you have a system that has a Broadcom
> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
> +
> +	  This driver requires that "avoid_warnings=2" be present in
> +	  the config.txt for the firmware, to keep it from smashing
> +	  our display setup.

The need for "avoid_warnings=2" seems like it will trip people up. I
don't think it's in any config.txt I've seen. Can you expand more on that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1208763 — Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

r<#secure method=pgpmime mode=sign>
Stephen Warren <swarren@wwwdotorg.org> writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>> This is the start of a full VC4 driver.  Right now this just supports
>> configuring the display using a pre-existing video mode (because
>> changing the pixel clock isn't available yet, and doesn't work when it
>> is).  However, this is enough for fbcon and bringing up X using
>> xf86-video-modesetting.
>
>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>
>> +config DRM_VC4
>> +	tristate "Broadcom VC4 Graphics"
>
>> +	help
>> +	  Choose this option if you have a system that has a Broadcom
>> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
>> +
>> +	  This driver requires that "avoid_warnings=2" be present in
>> +	  the config.txt for the firmware, to keep it from smashing
>> +	  our display setup.
>
> The need for "avoid_warnings=2" seems like it will trip people up. I
> don't think it's in any config.txt I've seen. Can you expand more on that?

The warnings thing is the firmware watching for undervoltage and then it
calls into dispmanx to overlay a little rainbow box on the screen.  This
of course interferes with our display setup.

I think we'll be able to wire up notifications to Linux for
undervoltage, at which point we can do something useful with that
information, ourselves.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web