lkml.org 
[lkml]   [2016]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
    Hi!

    > > > adp1653 registers itself as a subdev, but there's no device that
    > > > register it as its part.
    > > >
    > > > (ad5820 driver seems to have the same problem).
    > > >
    > > > Is there example "dummy" device I could use, for sole purpose of
    > > > having these devices appear in /dev? They are on i2c, so both can work
    > > > on their own.
    > >
    > > Ah, interesting. This was discussed a little bit during the Media Summit
    > > a few weeks back:
    > >
    > > http://linuxtv.org/news.php?entry=2016-04-20.mchehab
    > >
    > > See section 5:
    > >
    > > "5. DT Bindings for flash & lens controllers
    > >
    > > There are drivers that create their MC topology using the device tree information,
    > > which works great for entities that transport data, but how to detect entities
    > > that don’t transport data such as flash devices, focusers, etc.? How can those be
    > > deduced using the device tree?
    > >
    > > Sensor DT node add phandle to focus controller: add generic v4l binding properties
    > > to reference such devices."
    > >
    > > This wasn't a problem with the original N900 since that didn't use DT AFAIK and
    > > these devices were loaded explicitly through board code.

    > > But now you run into the same problem that I have.

    Actually... being able to do board-code solution for testing for now
    would be nice...

    > >
    > > The solution is that sensor devices have to provide phandles to those controller
    > > devices. And to do that you need to define bindings which is always the hard part.
    > >
    > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section
    > > "Optional endpoint properties".
    > >
    > > Something like:
    > >
    > > controllers: an array of phandles to controller devices associated with this
    > > endpoint such as flash and lens controllers.
    > >
    > > Warning: I'm no DT expert, so this is just a first attempt.
    > >
    > > Platform drivers (omap3isp) will have to add these controller devices to the list
    > > of subdevs to load asynchronously.
    >
    > I seem to have patches I haven't had time to push back then:
    >
    > <URL:http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a>
    >

    That gitweb is a bit confused about its own address, but I figured it
    out. Let me check...

    pavel@amd:/data/l/linux-n900$ git fetch
    git://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a
    fatal: unable to connect to git.retiisi.org.uk:
    git.retiisi.org.uk: Name or service not known

    pavel@amd:/data/l/linux-n900$ git fetch
    git://salottisipuli.retiisi.org.uk/~sailus/linux.git
    leds-as3645a:leds-as3645a
    remote: Counting objects: 132, done.
    remote: Compressing objects: 100% (46/46), done.
    remote: Total 132 (delta 111), reused 107 (delta 86)
    Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done.
    Resolving deltas: 100% (111/111), completed with 34 local objects.
    From git://salottisipuli.retiisi.org.uk/~sailus/linux
    * [new branch] leds-as3645a -> leds-as3645a


    > This seems to be mostly in line with what has been discussed in the meeting,
    > except that the patches add a device specific property. Please ignore the
    > led patches in that tree for now (i.e. four patches on the top are the
    > relevant ones here).
    >

    I'm currently trying to apply them to v4.6, but am getting rather ugly
    rejects :-(.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

    \
     
     \ /
      Last update: 2016-04-29 12:21    [W:2.662 / U:23.728 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site