On Wed, Apr 08, 2009 at 02:30:52PM -0700, David Brownell wrote: > On Tuesday 07 April 2009, Mark A. Greer wrote: > > Maybe this will help. > > > > Its just a hack for your dm355 spi example try to get my > > point across. It uses lspc as the tag for what the device > > is but the clk struct could be extended to add a field for > > the pinmux. davinci_pinmux_alloc() basically does a > > davinci_cfg_reg() on every pin in dm355_pins[DAVINCI_LPSC_SPI] > > while making sure each pin has not already been allocated. > > Doesn't really help: > > - You're still coupling clocks to pinmux. Just don't. > > - The "pin has not been allocated" stuff isn't actually > managing pins/balls ... I see nothing there that could > record how for example which balls a cfg_reg setting > can affect (it's not one pin per setting). > > - Doesn't even look particularly better in terms of how > the SPI setup is used. Each board's setup code gets > more complicated, not less.
Well, I see my example failed to accomplish its goal. The goal wasn't to provide a complete solution, it was to show that board code can easily override the soc default setup. I used the dm355 spi example because that's that one you've referrd to several times. It would look better with a better example with lots of pins that need to be setup but only a few that need to be changed by board code. Mark -- _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
