drm_device from another device driver? (was: Re: block device backed by DRM buffer object)

[Steven Newbury]

On Wed, 2015-09-23 at 23:41 +0200, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Sep 23, 2015 at 08:37:48PM +0000, Steven Newbury wrote:
> > I can't figure out how to get a pointer to the radeon_device struct
> > for a specific card, or the parent drm_device from an external
> > device
> > driver.
> 
> struct device -> struct drm_device: dev_get_drvdata()
> struct pci_dev -> struct drm_device: pci_get_drvdata()
> struct drm_device -> struct radeon_device: drm_device->dev_private
> 
Thanks, that's useful.

> 
> > I imagine I somehow need to take a reference to the drm class
> > kobject
> > for the card in question, and in so doing presumably I should then
> > be
> > able to discover the pointer to device.
> 
> It sounds like you want to discover the available radeon cards in the
> system? If so you could iterate over all pci devices and look for
> pci->vendor == PCI_VENDOR_ID_ATI || pci->vendor == PCI_VENDOR_ID_AMD,
> then get to the radeon_device as shown above.
> 
Yes, my plan was to eventually discover all the drm devices on the
system and make available a sysfs entry to allocate a volume from VRAM
for each capable card selecting an appropriate backend for driver.  I
was initially just going to implement it for radoen using a static
allocation from module params.

> However as Christian König pointed out, memory allocation is driver
> dependent. For an initial proof of concept it may be simplest to hack
> the radeon driver. Then you'll get an idea which parts are generic
> and
> which are driver specific and you can move the generic stuff to a
> central broker.
> 
Hacking the radeon driver was very much something I'd considered; I'd
only decided not to because I was thinking too far ahead really.  I
need to keep it simple, as you say, and only add complexity once I have
something working, and hopefully able to demonstrate its utility.

> Rather than discovering the VRAM it probably makes more sense to have
> drm devices register a set of callbacks with the central broker
> (e.g. return amount of currently free VRAM, allocate VRAM for use as
> block device, deallocate VRAM, read vector of blocks, write vector
> of blocks). The broker could then be controlled from user space via
> sysfs or ioctls or whatever.
For now I think I'll just take the approach bcache does with "thinly
provisioned volumes", and have an entry in the radeon sysfs:

/sys/class/drm/card0/device/vram_volume_create

which will attempt to allocate a given sized volume and register a
vrambd[0]. (or some better name?) Unregistering/deallocation can be
triggered from /sys/block/vramd[0]/vrambd/unregister
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150923/7a6ab35d/attachment.sig>