Question on how to best access a chip on init that needs VAUX1 power?

Question on how to best access a chip on init that needs VAUX1 power?

[Peter Barada]

On the OMAP board I have, I want to access production information
(model, serial number, MAC addresses, etc), and the part requires 3v
which is powered off of VAUX1.

I need to pull this out at initialization time, but I have to wait until
the twl4030 driver is running or I get "twl4030: client 3 is not
initialized" when I try to turn on the power.   Looking at the
twl4030-core.c code, I see its invoked via initcall_subsys().  I'd like
to have my code invoked before the other devices come up (so I can
provide a MAC address to the ethernet, etc).  I'm trying
initcall_sysbys_sync() to have my code called after the twl4040
initializes, but before the devices come up.

Is the the right way to approach this?

-- 
Peter Barada <peterb@logicpd.com>

RE: Question on how to best access a chip on init that needs VAUX1 power?

[Woodruff, Richard]

Subject: Question on how to best access a chip on init that needs VAUX1 power?
>
> On the OMAP board I have, I want to access production information
> (model, serial number, MAC addresses, etc), and the part requires 3v
> which is powered off of VAUX1.
>
> I need to pull this out at initialization time, but I have to wait until
> the twl4030 driver is running or I get "twl4030: client 3 is not
> initialized" when I try to turn on the power.   Looking at the
> twl4030-core.c code, I see its invoked via initcall_subsys().  I'd like
> to have my code invoked before the other devices come up (so I can
> provide a MAC address to the ethernet, etc).  I'm trying
> initcall_sysbys_sync() to have my code called after the twl4040
> initializes, but before the devices come up.

You can access this info from u-boot with i2c api.  For development you want the mac address available at that time anyway.

When you program it into Ethernet chip for many it will stick so kernel will see the right thing.

u-boot also has simple utility to read from mtd which has u-boot environment where you could have stored it away.

Regards,
Richard W.

RE: Question on how to best access a chip on init that needs VAUX1 power?

[Peter Barada]

On Fri, 2009-01-16 at 14:17 -0600, Woodruff, Richard wrote:
> Subject: Question on how to best access a chip on init that needs VAUX1 power?
> >
> > On the OMAP board I have, I want to access production information
> > (model, serial number, MAC addresses, etc), and the part requires 3v
> > which is powered off of VAUX1.
> >
> > I need to pull this out at initialization time, but I have to wait until
> > the twl4030 driver is running or I get "twl4030: client 3 is not
> > initialized" when I try to turn on the power.   Looking at the
> > twl4030-core.c code, I see its invoked via initcall_subsys().  I'd like
> > to have my code invoked before the other devices come up (so I can
> > provide a MAC address to the ethernet, etc).  I'm trying
> > initcall_sysbys_sync() to have my code called after the twl4040
> > initializes, but before the devices come up.
> 
> You can access this info from u-boot with i2c api.  For development you want the mac address available at that time anyway.

> When you program it into Ethernet chip for many it will stick so kernel will see the right thing.

That is if I initialize the ethernet in u-boot.  To save on power, I'd
like to leave the ethernet alone until the user needs it(and at that
point can modprobe the driver).  I still need the data to setup wireless
in the kernel (its mac address, trim values, etc)...

> u-boot also has simple utility to read from mtd which has u-boot environment where you could have stored it away.

Ultimately I should just pull the block of data in u-boot, extract what
I need for u-boot, and then pass it to the kernel.  Outside of creating
a specific ATAG for this, what's the best way to pass a block of data
from u-boot to the kernel?

> Regards,
> Richard W.
-- 
Peter Barada <peterb@logicpd.com>

RE: Question on how to best access a chip on init that needs VAUX1 power?

[Woodruff, Richard]

> > u-boot also has simple utility to read from mtd which has u-boot environment
> where you could have stored it away.
>
> Ultimately I should just pull the block of data in u-boot, extract what
> I need for u-boot, and then pass it to the kernel.  Outside of creating
> a specific ATAG for this, what's the best way to pass a block of data
> from u-boot to the kernel?

Outside of ATAG I don't know what the best way is.  There were some omap specific tags which were recently deemed not the right way.

You should inquire on u-boot list and see what some of the ports there do.

As a thought the on chip SRAM would provide an easy way to pass the information up.

Regards,
Richard W.

Re: Question on how to best access a chip on init that needs VAUX1 power?

[David Brownell]

On Friday 16 January 2009, Peter Barada wrote:
> Ultimately I should just pull the block of data in u-boot, extract what
> I need for u-boot, and then pass it to the kernel.  Outside of creating
> a specific ATAG for this, what's the best way to pass a block of data
> from u-boot to the kernel?

kernel command line parameters.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question on how to best access a chip on init that needs VAUX1 power?

[David Brownell]

On Friday 16 January 2009, Peter Barada wrote:
>   I'm trying
> initcall_sysbys_sync() to have my code called after the twl4040
> initializes, but before the devices come up.
> 
> Is the the right way to approach this?

Well, "subsys_initcall()" ... that should work.

Declare the VAUX1 regulator in the normal way,
and you can either hook up VAUX1 to the relevant
device node and have it turn on the regulator,
or just mark it as always_on.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html