Hi Scott,

On Thursday 28 August 2008, Scott Wood wrote:

Laurent Pinchart wrote:

quoted

On Thursday 28 August 2008, Scott Wood wrote:

quoted

On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:

quoted

I'm facing a situation where I need to call cpm2_clk_setup and 
cpm2_set_pin from a device driver compiled as a module. Before 
submitting a patch to export both functions, I'd like to make
sure there isn't a cleaner way to implement the desired
functionality without calling functions that are supposed to be
used by board setup code.

Have you looked at using the GPIO API?

Yes, but the GPIO API doesn't support dedicated pin usage. Basically
all I can do is configure a pin as a general purpose input or output,
and set its level when configured as an output. The GPIO API doesn't
provide any way to access the PAR and SOR registers.

OK, wasn't sure what it was that you needed to set at runtime.  Are you 
actually switching between dedicated functions dynamically?  Why do you 
need to do this?

quoted

Beside, the GPIO API won't help configuring clock routing.

Why does the clock routing need to change dynamically?

The Infineon SHDSL chip uses separate clocks for transmit and receives. The receive clock is always derived from the analog line and is routed from the SHDSL chip to a clock input on the MPC8248.

The transmit clock is a bit trickier to handle, as it depends on which mode the SHDSL channel is configured in. When in Central Office mode, the transmit clock is generated by the MPC8248 using one of its BRG and output on an I/O pin. Clock routing on the MPC8248 routes CLKx to the SCC RX clock and BRGx to the SCC transmit clock. The CLKx and BRGx I/O pins must be configured accordingly.

When in Remote Terminal mode, the receive clock must be looped to the transmit clock. This is achieved using a tristate buffer. The transmit clock signal is thus driven by the buffer instead of being driven by the MPC8248 BRGx pin. To avoid electrical conflicts I have to switch the BRGx I/O pin to an input. Clock routing must be reconfigured to route CLKx to both the SCC RX and TX clocks.

If it turns out this really does need to happen, we can add some locks 
and export the functions, but I'd like to hear more about the use case 
first.

GPIO configuration might be worked around by extending the GPIO API or providing CPM2-specific extensions. Clock routing configuration is in my opinion required at runtime and I can't see any easy work around this. Feel free to prove me wrong :-)

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75