[RFC] Using two baud rate generators with the cpm_uart driver

[RFC] Using two baud rate generators with the cpm_uart driver

[Laurent Pinchart]

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

Hi everybody,

thanks to a bad hardware design decision, I'm faced with a software issue with 
the cpm_uart driver.

My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port 
with an external transceiver. The transceiver's data direction is controlled 
by external logic that monitors the SCC4/SMC2 TxD signal.

The external logic needs an input clock at the baud rate frequency on the 
MPC8248 BRG5 output pin (although I could modify it to accept an input clock 
at 16x the baud rate frequency). This means the cpm_uart driver has to setup 
two baud rate generators instead of one.

The ppc architecture was easy to hack as it used a fs_uart_platform_info 
structure in which I added a set_brg function pointer provided by platform 
code. This isn't possible with the powerpc architecture anymore.

Is there a clean way to fix this issue ? Kicking the hardware designer won't 
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: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Using two baud rate generators with the cpm_uart driver

[Scott Wood]

Laurent Pinchart wrote:
> thanks to a bad hardware design decision, I'm faced with a software issue with 
> the cpm_uart driver.
> 
> My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port 
> with an external transceiver. The transceiver's data direction is controlled 
> by external logic that monitors the SCC4/SMC2 TxD signal.
> 
> The external logic needs an input clock at the baud rate frequency on the 
> MPC8248 BRG5 output pin (although I could modify it to accept an input clock 
> at 16x the baud rate frequency). This means the cpm_uart driver has to setup 
> two baud rate generators instead of one.
> 
> The ppc architecture was easy to hack as it used a fs_uart_platform_info 
> structure in which I added a set_brg function pointer provided by platform 
> code. This isn't possible with the powerpc architecture anymore.
 >
> Is there a clean way to fix this issue ? Kicking the hardware designer won't 
> help :-)

Maybe not, but it'd be satisfying. :-)

The clean solution would be to have an abstracted clock API, similar to 
phylib, where the caller doesn't know details about BRGs and such. 
Maybe the linux/clk.h API would be suitable; I haven't looked at it in 
detail.

-Scott

Re: [RFC] Using two baud rate generators with the cpm_uart driver

[Laurent Pinchart]

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

Hi Scott,

On Tuesday 15 April 2008 17:34, Scott Wood wrote:
> Laurent Pinchart wrote:
> > thanks to a bad hardware design decision, I'm faced with a software issue
> > with the cpm_uart driver.
> > 
> > My hardware uses either SCC4 or SMC2 (production-time option) as an RS485
> > port with an external transceiver. The transceiver's data direction is
> > controlled by external logic that monitors the SCC4/SMC2 TxD signal.
> > 
> > The external logic needs an input clock at the baud rate frequency on the 
> > MPC8248 BRG5 output pin (although I could modify it to accept an input
> > clock at 16x the baud rate frequency). This means the cpm_uart driver has
> > to setup two baud rate generators instead of one.
> > 
> > The ppc architecture was easy to hack as it used a fs_uart_platform_info 
> > structure in which I added a set_brg function pointer provided by platform 
> > code. This isn't possible with the powerpc architecture anymore.
>  >
> > Is there a clean way to fix this issue ? Kicking the hardware designer
> > won't help :-)
> 
> Maybe not, but it'd be satisfying. :-)

Don't tempt me :-)

> The clean solution would be to have an abstracted clock API, similar to 
> phylib, where the caller doesn't know details about BRGs and such. 
> Maybe the linux/clk.h API would be suitable; I haven't looked at it in 
> detail.

The clock API would have to be quite advanced to express things like "the SCC4 
clock is a combination of BRG2 and BRG5" (and I don't even consider 
adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").

I'm not even sure a generic API should be developed to solve my problem. I'm 
more looking for a not too dirty hack.

-- 
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: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Using two baud rate generators with the cpm_uart driver

[Scott Wood]

Laurent Pinchart wrote:
>> The clean solution would be to have an abstracted clock API, similar to 
>> phylib, where the caller doesn't know details about BRGs and such. 
>> Maybe the linux/clk.h API would be suitable; I haven't looked at it in 
>> detail.
> 
> The clock API would have to be quite advanced to express things like "the SCC4 
> clock is a combination of BRG2 and BRG5" (and I don't even consider 
> adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").

What I was picturing was platform code providing a clock object that the 
cpm_uart driver could be pointed at (possibly by modifying the device 
tree in platform init); the knowledge of the multiple BRG weirdness 
would be contained in platform code.

-Scott

Re: [RFC] Using two baud rate generators with the cpm_uart driver

[Laurent Pinchart]

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

On Tuesday 15 April 2008 17:59, Scott Wood wrote:
> Laurent Pinchart wrote:
> >> The clean solution would be to have an abstracted clock API, similar to 
> >> phylib, where the caller doesn't know details about BRGs and such. 
> >> Maybe the linux/clk.h API would be suitable; I haven't looked at it in 
> >> detail.
> > 
> > The clock API would have to be quite advanced to express things like "the SCC4 
> > clock is a combination of BRG2 and BRG5" (and I don't even consider 
> > adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
> 
> What I was picturing was platform code providing a clock object that the 
> cpm_uart driver could be pointed at (possibly by modifying the device 
> tree in platform init); the knowledge of the multiple BRG weirdness 
> would be contained in platform code.

I'll think about it.

Thanks.

-- 
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: Type: application/pgp-signature, Size: 189 bytes --]