From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: drm_device from another device driver? Date: Thu, 24 Sep 2015 11:41:41 +0200 Message-ID: <5603C555.3030206@vodafone.de> References: <1442835186.12687.26.camel@snewbury.org.uk> <5600009B.6060909@vodafone.de> <1442954650.14110.24.camel@snewbury.org.uk> <47j707.nv5dbe.2u4lbf-qmf@mail.snewbury.org.uk> <20150923214138.GA8680@wunner.de> <1443048770.1731.33.camel@snewbury.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1701309199==" Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 467F36E79E for ; Thu, 24 Sep 2015 02:41:49 -0700 (PDT) In-Reply-To: <1443048770.1731.33.camel@snewbury.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Steven Newbury , Lukas Wunner Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============1701309199== Content-Type: multipart/alternative; boundary="------------060802070404070202000608" This is a multi-part message in MIME format. --------------060802070404070202000608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 =3D=3D PCI_VENDOR_ID_ATI || pci->vendor =3D=3D 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=C3=B6nig pointed out, memory allocation is driv= er >> 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=20 different direction with the sysfs interface. It doesn't make much sense to have more than one volume for each card=20 (doesn't it?). So I would rather say instead of having a=20 vram_volume_create sysfs you should rather go with something like=20 vram_volume_size. E.g. setting the size makes the volume available, setting it to zero=20 tries to free it again. If anybody is using it while you try to change=20 the size return -EBUSY. Regards, Christian. > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel --------------060802070404070202000608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 24.09.2015 00:52, Steven Newbury wrote:
On Wed, 2015-09-23 at 23:41 +0200, Lukas Wunner wrot=
e:

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 r=
adeon_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 =3D=3D PCI_VENDOR_ID_ATI ||=C2=A0pci->vendor =3D=3D 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. =C2=A0=
I
was initially just going to implement it for radoen using a static
allocation from module params.



      

        
However as Christian K=C3=B6nig pointed out, memor=
y 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. =C2=A0I
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 d=
oes 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


    

    

  


--------------060802070404070202000608--

--===============1701309199==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK

--===============1701309199==--