|
On 24.09.2015 00:52, Steven Newbury
wrote:
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_privateThanks, 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 Yeah, that approach sounds reasonable to me I would just go into a different direction with the sysfs interface. It doesn't make much sense to have more than one volume for each card (doesn't it?). So I would rather say instead of having a vram_volume_create sysfs you should rather go with something like vram_volume_size. E.g. setting the size makes the volume available, setting it to zero tries to free it again. If anybody is using it while you try to change the size return -EBUSY. Regards, Christian.
|
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
