Drivers' probe function calling order

Drivers' probe function calling order

[DI BACCO ANTONIO - technolabs]

How can I fix the calling order of two monolithic drivers? I have an spi
driver and a driver for a dataflash, how can I force the system to call
probe function of the spi driver first?
=20
Bye and thanks.

Re: Drivers' probe function calling order

[Jeff Mock]

The only way I've know to do this is to build the drivers as modules and 
load them in the desired order from the startup scripts called from init.

If there's a better way I would like to know about it also...

jeff


DI BACCO ANTONIO - technolabs wrote:
> How can I fix the calling order of two monolithic drivers? I have an spi
> driver and a driver for a dataflash, how can I force the system to call
> probe function of the spi driver first?
>  
> Bye and thanks.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

Re: Drivers' probe function calling order

[Alessandro Rubini]

> how can I force the system to call
> probe function of the spi driver first?

You can declare their init functions at different initcall level.  For
example declaring the dataflash one as late_initcall(). Or declare
the spi one as subsys_initcall() -- whatever makes more sense.

There might be cleaner ways according to your setup, but this will
surely work.

/alessandro

Re: Drivers' probe function calling order

[Misbah khan]

Hi Mr Rubini ...

I am writing a driver in which device port is mapped to CPLD and 8 bit data
bus is directly connected from processor to CPLD. Read write on CPLD memory
mapped (buffer/register) is required to control the device. This is now IO
mapped to processor. 

I need to know whether i am right if i impliment like this :- 
         addr=ioremap(base_addr,size);          // Remap to Mem mapped
address 
         out_8(addr) and in_8(addr); 


Alessandro Rubini wrote:
> 
> 
>> how can I force the system to call
>> probe function of the spi driver first?
> 
> You can declare their init functions at different initcall level.  For
> example declaring the dataflash one as late_initcall(). Or declare
> the spi one as subsys_initcall() -- whatever makes more sense.
> 
> There might be cleaner ways according to your setup, but this will
> surely work.
> 
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Drivers%27-probe-function-calling-order-tp14601099p14612559.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: ioremap and outb

[Alessandro Rubini]

Please don't change subject matter without changing subject line, and please
open a new thread when asking a new question.

> I am writing a driver in which device port is mapped to CPLD and 8 bit data
> bus is directly connected from processor to CPLD. Read write on CPLD memory
> mapped (buffer/register) is required to control the device. This is now IO
> mapped to processor.

This is typical. You'll find quite a lot of examples.

>          addr=ioremap(base_addr,size);          // Remap to Mem mapped

Yes.

>          out_8(addr) and in_8(addr); 

It should be right, although __raw_readb() and __raw_writeb() may
suffice for you. Please check the comments in <asm/io.h>.

It may also happen that you need to read/write  32 bits instead of 8,
but this depends on your specific hardware.

/alessandro

Re: ioremap and outb

[Arnd Bergmann]

On Friday 04 January 2008, Alessandro Rubini wrote:
> > =A0 =A0 =A0 =A0 =A0addr=3Dioremap(base_addr,size); =A0 =A0 =A0 =A0 =A0/=
/ Remap to Mem mapped
>=20
> Yes.

In newer drivers that are specific to powerpc, it's often easier
to use the of_iomap() function to map a device, so you don't
have to calculate the base address manually from the device tree.

> > =A0 =A0 =A0 =A0 =A0out_8(addr) and in_8(addr);=20
>=20
> It should be right, although __raw_readb() and __raw_writeb() may
> suffice for you.

Actually not. While they may work, the __raw_* functions do not have
a specific meaning in device drivers. Depending on the I/O model, they
may or may not work on a given platform. The {in,out}_{8,{be,le}{16,32,64}}
functions however are defined to operate on local (not PCI) ioremapped
mmio devices, and are usually more efficient than the {read,write}{b,w,l,q}
variant you'd use on PCI devices.

	Arnd <><