devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Thomas De Schampheleire
	<patrickdepinguin+devicetree-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: i2c child devices: binding to uio device driver
Date: Thu, 19 May 2011 09:58:08 -0600	[thread overview]
Message-ID: <20110519155808.GC3085@ponder.secretlab.ca> (raw)
In-Reply-To: <BANLkTimSBReyncTANTyy4jhah=-QvPigwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, May 19, 2011 at 05:32:32PM +0200, Thomas De Schampheleire wrote:
> Hi,
> 
> I am using the uio framework (userspace i/o) to handle devices in
> userspace. This includes memory access and interrupt handling.
> For i2c devices, I'm using the i2c-dev interface, to talk to these
> devices from userspace. This already works fine.
> 
> One of my i2c devices also has an interrupt line connected to the
> processor. To be able to handle this interrupt with uio, I need to
> have a kernel driver matched against the i2c device. However, the i2c
> device described in the device tree does not bind with the driver. Is
> this behavior supported, and if so, what am I doing wrong? Do I have
> to create a dummy bus (non-i2c) and add a shadow node for the
> interrupt?

You're wandering into new territory here.  It is definitely the right
thing to do to describe your i2c device in the device tree with the
interrupt fully specified.

What you probably need to do is create a uio helper driver for your
device that takes care of finding the device node, mapping the
interrupt, and proving the interrupt handling UIO hook to userspace.
The easiest way to work this out would be to make your uio helper
actually bind to the i2c device created by the device node (this is
probably the best way too), but you don't have to.  As long as you
arrange for you uio helper to get called at some point, you can get it
to find the appropriate node in the DT, map the interrupt, and export
it to userspace.

g.

> 
> My device tree nodes look like this:
> 
>         soc@fe000000 {
>                 i2c@118100 {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                         cell-index = <1>;
>                         compatible = "fsl-i2c";
>                         reg = <0x118100 0x100>;
>                         interrupts = <38 2 0 0>;
>                         dfsrr;
>                         mydevice@68 {
>                                 compatible = "mymanufacturer,mydevice";
>                                 reg = <0x68>;
>                                 interrupts = <7 1 0 0>; /* External
> IRQ7, active-low level */
>                         };
>                 };

This looks to be correct.

> 
> The device driver then has:
> 
> static const struct of_device_id mydevice_ids[] = {
>         {
>                 .compatible = "mymanufacturer,mydevice"
>         },
>         {},
> };
> static struct of_platform_driver mydevice_driver = {

You don't want to do this.  This is an i2c device, not a platform
device.  If anything, this should be an i2c_driver and you should use
the normal creation of i2c devices from the DT.

BTW, of_platform_driver is deprecated and is just a wrapper around
plain platform_driver on recent kernels.  platform_driver should be
used directly now.

>         .owner          = THIS_MODULE,
>         .name           = "mydevice",
>         .match_table    = mydevice_ids,
>         .probe          = mydevice_probe,
>         .remove         = __devexit_p(mydevice_remove),
> };
> 
> static int __init mydevice_init(void)
> {
>         printk(KERN_INFO "mydevice: driver init\n");
>         return of_register_platform_driver(&mydevice_driver);
> }
> 
> Note that the init function is called correctly, but the probe
> function is never called.
> 
> All this is on a p4080ds-based system, with linux 2.6.34.6.
> 
> Best regards,
> Thomas
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

  parent reply	other threads:[~2011-05-19 15:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 15:32 i2c child devices: binding to uio device driver Thomas De Schampheleire
     [not found] ` <BANLkTimSBReyncTANTyy4jhah=-QvPigwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-19 15:58   ` Grant Likely [this message]
     [not found]     ` <20110519155808.GC3085-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-05-23  8:13       ` Thomas De Schampheleire
     [not found]         ` <BANLkTim08mWohWkqF0veHbz0+ydikHTAFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-25  6:39           ` Thomas De Schampheleire
     [not found]             ` <BANLkTimKP0Bo3C5rqzJg5AAc1p9evmfxaA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-27  7:17               ` Grant Likely
     [not found]                 ` <20110527071738.GC31953-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-05-27 10:33                   ` Thomas De Schampheleire
     [not found]                     ` <BANLkTimYs5+cr_E_kW-s3oQdnhf0582Lbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-03 17:19                       ` Grant Likely
2011-05-25 11:28       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110519155808.GC3085@ponder.secretlab.ca \
    --to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=patrickdepinguin+devicetree-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).