Questions regarding mfd drivers

Questions regarding mfd drivers

[Kristoffer Ericson]

Greetings,

Trying to wrap my head around sm501. From what I can tell an mfd driver is a "master" driver that takes control of all
memory and io areas. It then hands out areas of those to drivers. Anywhere near correct?

I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now?

The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before
attempting to write one on my own. Anyone know any documentation aside from example drivers?

Best wishes
Kristoffer

Re: Questions regarding mfd drivers

[Ben Dooks]

On Mon, Feb 04, 2008 at 12:37:14PM +0100, Kristoffer Ericson wrote:
> Greetings,
> 
> Trying to wrap my head around sm501. From what I can tell an mfd driver is a "master" driver that takes control of all
> memory and io areas. It then hands out areas of those to drivers. Anywhere near correct?

Yes, it is the central management for these, but also ensures that any
of the sub-drivers have properly locked access to the clocks, gpio and
other shared resources.

The mfd driver for the sm501 exports a number of functions for the
sub drivers to use, you should be able to see what is exported easily
by the fact they are exported with EXPORT_SYMBOL_GPL(). The header
files should document basic functionality of this.
 
> I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now?
> 
> The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before
> attempting to write one on my own. Anyone know any documentation aside from example drivers?

Are you trying to write your own SM501, or something else? It seems
you are writing for something else.

If the chip you are targetting has shared resources, such as clock
gates, PLLs, or gpio that other drivers need to touch, then the best
way to go is for an mfd driver to provide this functionality and have
all the child drivers use the exported functionality.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: Questions regarding mfd drivers

[Kristoffer Ericson]

On Mon, 4 Feb 2008 23:01:55 +0000
Ben Dooks <ben@fluff.org> wrote:

> On Mon, Feb 04, 2008 at 12:37:14PM +0100, Kristoffer Ericson wrote:
> > Greetings,
> > 
> > Trying to wrap my head around sm501. From what I can tell an mfd driver is a "master" driver that takes control of all
> > memory and io areas. It then hands out areas of those to drivers. Anywhere near correct?
> 
> Yes, it is the central management for these, but also ensures that any
> of the sub-drivers have properly locked access to the clocks, gpio and
> other shared resources.

Oki

> 
> The mfd driver for the sm501 exports a number of functions for the
> sub drivers to use, you should be able to see what is exported easily
> by the fact they are exported with EXPORT_SYMBOL_GPL(). The header
> files should document basic functionality of this.
> 

Will take a look at that.
 
> > I can see some benefit but still hard for me to motivate. What am I missing? What will the mfd be able to do, that I lack now?
> > 
> > The sm501 driver seems way more advanced than I will need for hd64461/hd64465 anyhow, but still need to understand sm501 completely before
> > attempting to write one on my own. Anyone know any documentation aside from example drivers?
> 
> Are you trying to write your own SM501, or something else? It seems
> you are writing for something else.
>

Im trying to move the companion chip hd64461 to a more sensible location. Paul suggested building an mfd driver.
The hd64461 chipset supplies for example pcmcia and framebuffer support. Its not as advanced as the SM501.
 
> If the chip you are targetting has shared resources, such as clock
> gates, PLLs, or gpio that other drivers need to touch, then the best
> way to go is for an mfd driver to provide this functionality and have
> all the child drivers use the exported functionality.

Oki, sounds good. Thanks for info.

> 
> -- 
> Ben (ben@fluff.org, http://www.fluff.org/)
> 
>   'a smiley only costs 4 bytes'