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_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
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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150924/9a2aca13/attachment.html>