Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
Hi Scott, On Thursday 28 August 2008, Scott Wood wrote: Laurent Pinchart wrote: On Thursday 28 August 2008, Scott Wood wrote: On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote: 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? 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 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
On Thursday 28 August 2008, Scott Wood wrote: On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote: 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. Beside, the GPIO API won't help configuring clock routing. 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 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote: 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? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
Laurent Pinchart wrote: On Thursday 28 August 2008, Scott Wood wrote: On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote: 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? Beside, the GPIO API won't help configuring clock routing. Why does the clock routing need to change dynamically? 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. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
