Converting i2c-omap driver to use device tree

Grant Likely grant.likely at secretlab.ca
Wed Jun 29 05:38:54 EST 2011


On Tue, Jun 28, 2011 at 07:48:29PM +0530, Manjunatha GK wrote:
> Grant,
> I am able to sort out this issue and i can see irq numbers getting populated
> in i2c driver.
> 
> I have some other queries related to handling SoC specific data. I will post
> the query with separate thread.
> 
> -Manjunath
> 
> On 27 June 2011 00:21, Manjunatha GK <manjugk at ti.com> wrote:
> 
> > Hi Grant,
> >
> > On 26 June 2011 13:42, Grant Likely <grant.likely at secretlab.ca> wrote:
> >
> >> On Fri, Jun 24, 2011 at 07:08:34PM +0530, Manjunatha GK wrote:
> >> > Hi Thomas,
> >> >
> >> > On 24 June 2011 18:13, Thomas Abraham <thomas.abraham at linaro.org>
> >> wrote:
> >> >
> >> > > Hi Manjunath,
> >> > >
> >>
> >
> > [...]
> >
> > > > >
> >> > > > With the above changes, i was expecting probe function to be called
> >> since
> >> > > > device gets binded to driver. But probe will never get called.
> >> > > >
> >> > > > Did I miss anything with above procedure?
> >> > >
> >> > > What about platform_driver->driver.of_match_table? Is it populated
> >> > > (set to omap_i2c_of_match)?
> >> > >
> >> >
> >> > Yes. This entry was missing with my changes. With of_match_table, probe
> >> is
> >> > getting called.
> >> > Thanks for the pointer.
> >>
> >> Glad to hear you got it sorted out.
> >>
> >
> > Yes. Now I am able to get i2c base address from DT through device node
> > structure but not able to get irq number from DT. The .dts entries are:
> >
> > +       gic: intc at 48241000 {
> > +               compatible = "arm,omap-gic", "arm,gic";
> > +               interrupt-controller;
> > +               #interrupt-cells = <1>;
> > +               reg = <0x48241000 0x1000>;
> > +       };
> > +
> > +       i2c at 48072000 {
> > +               interrupts = <88>;
> > +               interrupt-parent = <&gic>;
> > +               compatible = "ti,omap_i2c";
> > +               #address-cells = <1>;
> > +               #size-cells = <0>;
> > +               reg = <0x48072000 0x80>;
> > +
> > +               twl at 0x48 {
> > +                       compatible = "ti,twl6030";
> > +                       reg = < 0x48 >;
> > +               };
> > +
> > +       };
> >
> > From the debug log, it is observed that, the interrupts field will not
> > exists in device_node data structure. It captures all the fields from the
> > about i2c DT entries except interrupts field.
> >
> > [    0.293182] of_irq_map_one: dev=/i2c at 48072000, index=0
> > [    0.293212] of_find_property; pp->name: compatible    name: interrupts
> > [    0.293212] of_find_property; pp->name: reg   name: interrupts
> > [    0.293243] of_find_property; pp->name: #address-cells        name:
> > interrupts
> > [    0.293243] of_find_property; pp->name: #size-cells   name: interrupts
> > [    0.293273] of_find_property; pp->name: name  name: interrupts
> > [    0.293304] omap_i2c_probe: i2c: dev->base: fa072000
> > [    0.293304] omap_i2c_probe: i2c: dev->irq: ffffffff
> >
> > Any specific reason for missing entries in device node structures?
> >
> > Since you explored other ARM boards, is this interrupts field used and
> > tested?

What tree do you have your work based on top of?  Do you have the
irq_domain patch applied?  If so, then the problem is most likely that an
irq_domain has not been registered for the OMAP interrupt controller
(which is not surprising since the gic has not been converted to use
irq_domain yet).  There are patches that have been posted to the list
to do so, but they are not finished yet.  In the mean time you can use
irq_domain_generate_simple() to create an irq_domain registration for
the OMAP that will get you past this step.

Search the devicetree/test branch for irq_domain_generate_simple() to
see how to use it.

g.

> >
> > -Manjunath
> >
> >
> 
> 
> -- 
> Manjunatha GK
> 
> Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs
> 
> Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
> Twitter<http://twitter.com/#%21/linaroorg>|
> Blog <http://www.linaro.org/linaro-blog/>


More information about the devicetree-discuss mailing list