Subject: Re: How to implement PSC driver on Au1550
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-evbmips
Date: 02/24/2006 08:47:17
Izumi Tsutsui wrote:
>> Hmm... I'm also not sure about the clock selection logic in general. 
>> How do you know which clock to select?  That seems to be a board
>> specific configuration option.  Maybe another set of board_info() ops? 
>> Or another locator?  I don't know what the right option is.
>>     
>
> Maybe we should think how much board specific clock variables
> are needed:
> - master clock frequency for internal clock source (peripheral clock?)
> - PSCn_EXTCLK frequencies
> - etc.
> Or we should also have devprop_set() (or so) to define frequencies
> and divider values for clock generater etc. in board specific
> init functions?
>   
devprop_set would work fine, I think.  Maybe devprop_set should have
been used for some of the board-specific PCI and PCMCIA stuff too, hmm? 
(Probably not the PCMCIA, too many complications there.)

I should take a look at that.  It might clean the code up a bit.  (But
it might complicate it too, because then you have board-specific logic
in autoconf that isn't there right now.)
>   
>> (In any
>> case,  it seems likely that you need expose some aupsc operations to
>> individual drivers -- e.g. aupsc_enable()/disable()/suspend(),
>> aupsc_set_protocol(), aupsc_set_clock() maybe?
>>     
>
> For now, we don't have to have enable/disable/suspend, and
> set_protocol() and set_clock() can be done in attach functions
> in children, I think.
>   
As the logic for how to do this is the same for all PSCs protocols (with
only an integer value), I believe that it is cleanest to put this in the
parent bus driver (aupsc) and have the children call into them.

Also, enable() at least needs to be in there, because the current aupsc
attach logic attaches the children with the PSC disabled.  I can imagine
that a child device driver *might* want to suspend or disable a device
as well (e.g. for power mgmt), but probably right now it isn't required.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191