lkml.org 
[lkml]   [2013]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
Date
On Fri, Feb 01, 2013 at 22:41:24, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [130201 09:12]:
> > * Linus Walleij <linus.walleij@linaro.org> [130129 03:03]:
> > > On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish
> > > <manishv.b@ti.com> wrote:
> > >
> > > > Currently, I2C driver gets probed before pinctrl driver.
> > > > To achieve I2C pin muxing via pinctrl driver before I2C probe get
> > > > called, register pinctrl driver in arch_initcall.
> > > > Also, add module_exit to unregister pinctrl driver.
> > > >
> > > > Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> > >
> > > So your I2C driver is not returning -EPROBE_DEFER if it cannot find
> > > its pins?
> > >
> > > Hm, well I can live with this, if Tony ACKs it.
> >
> > Hmm pinctrl is before i2c in drivers/Makefile.
> > Making initcalls happen earlier and earlier is usually the wrong way
> > to go. Sounds like there's some other issue here that needs to be
> > fixed instead.
>
> Let me guess: The i2c driver is wrongly set to run with arch_initcall?
>

Hi Tony

No, Currently i2c driver is set to subsys_initcall. I have seen some
problem while using pin control grab functionality. Please see detailed
explanation as below.

Hi Linus

I am using auto grab pin control facility to do pin muxing of I2C0
pins and seen problem as below:

Currently, probe of I2C0 driver gets called before pin control driver.
Hence, while calling I2C0 probe because of unavailability of
pin control node information, its probe get deferred giving following
messages:

"i2c_davinci i2c_davinci.1: could not find pctldev for node /soc/pinmux@1c14120
/pinmux_i2c0_pins, deferring probe"

As I2C0 is in deferred list (as auto grab patch handle this), its probe
get called once again, During this second time probe of I2C0, I have
observed following crash:

"Unable to handle kernel paging request at virtual address fffffe07"

As per code analysis of auto grab functionality, I have seen in
"pinctrl_bind_pin" function, pin control handle (dpi->p) is returned by
"devm_pinctrl_get" function.

Pin control handle is assigned with error pointer during 1st time probing of
I2C0 (as pin control information is not available at this time).
During 2nd time probing (deferred probe) of I2C0, same pin control handle
(which was get assigned during 1st probe) is getting used instead of getting
updated to correct pin control handle which leads to system crash.

I made following changes, in order to update "dip->p" pointer with
correct value:

- if (!dpi->p) {
+ if (IS_ERR_OR_NULL(dpi->p)) {
dpi->p = devm_pinctrl_get(dev);
- if (IS_ERR_OR_NULL(dpi->p)) {
- int ret = PTR_ERR(dpi->p);
-
- dev_dbg(dev, "no pinctrl handle\n");
- /* Only return deferrals */
- if (ret == -EPROBE_DEFER)
- return ret;
- return 0;
- }
+ ret = PTR_ERR(dpi->p);
+ dev_dbg(dev, "no pinctrl handle\n");
+ /* Only return deferrals */
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ return 0;

Is this intended change? or am I missing something in order to use this auto grab
functionality?

With the above change, now deferred probing is working fine and there is no need
to register pin control driver in arch_initcall.


Regards,
Manish


\
 
 \ /
  Last update: 2013-02-05 08:21    [W:0.077 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site