RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Hi everybody,

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.

The hardware is an Infineon SHDSL chip connected directly to 3 SCC ports of an MPC8248. The SHDSL ports roles can be set at runtime to Central Office or Remote Terminal (thing about a kind of master/slave configuration). SCC clock routing needs to configured at runtime to accommodate the ports roles (in one of the roles the SCC uses a baud rate generator, while in the other it receives the clock from the chip). Clocks are described in the device tree, so the driver does not hardcode clock values, but I need to call cpm2_clk_setup at runtime. Should this be done through board-supplied callbacks passed to the driver in a platform data structure (in which case I can't declare the device in the device tree as I'm doing now) or would it be acceptable to export cpm2_clk_setup ?

cpm2_set_pin is used for a similar purpose, as I have to setup BRG/CLK pins in input or output mode depending on the clock configuration. Additionally, cpm2_set_pin is also used to configure all inputs as outputs when the driver detects that the optional SDHSL module is not plugged in. Would it be safe to leave those pins as floating inputs, or could that potentially damage the MPC8248 ?

Thanks for your help.

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

[Scott Wood]

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

Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

[Scott Wood]

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

Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]