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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
