Re: drm_device from another device driver?

["Christian König" <deathsimple@vodafone.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3475 bytes --]

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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[-- Attachment #1.2: Type: text/html, Size: 4870 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel