[PATCH v6 1/3] serial: sh-sci: Add OF support

[Bastian Hecht]

Hi Paul,

2013/3/6 Paul Mundt <lethal at linux-sh.org>:
> On Wed, Mar 06, 2013 at 01:25:16PM +0100, Laurent Pinchart wrote:
>> On Wednesday 06 March 2013 13:10:55 Laurent Pinchart wrote:
>> > On Wednesday 06 March 2013 12:30:35 Bastian Hecht wrote:
>> > > +- renesas,scbrr-algorithm : Choose an algorithm ID for the baud rate
>> > > generator.
>> > > +  1 = SCBRR_ALGO_1 ((clk + 16 * bps) / (16 * bps) - 1)
>> > > +  2 = SCBRR_ALGO_2 ((clk + 16 * bps) / (32 * bps) - 1)
>> > > +  3 = SCBRR_ALGO_3 (((clk * 2) + 16 * bps) / (16 * bps) - 1)
>> > > +  4 = SCBRR_ALGO_4 (((clk * 2) + 16 * bps) / (32 * bps) - 1)
>> > > +  5 = SCBRR_ALGO_5 (((clk * 1000 / 32) / bps) - 1)
>> >
>> > Isn't it a property specific to our implementation of the driver instead of
>> > a hardware property ? How is one supposed to select the right algorithm ?
>>
>> I realize I haven't expressed myself very clearly here. What I mean is that
>> expressing how the baud rate generator works internally using an algorithm ID
>> is pretty specific to the Linux driver.
>>
>> I assume that, for a given serial port on a given SoC, the algorithm that
>> matches the baud rate generator hardware implementation needs to be selected.
>> Can't this information be inferred from the compatible string and port number
>> ?
>>
> Now that we have split things out in to regtype for the compat string we
> may be able to get away with selecting defaults that match the regtype
> and drop it from the binding (assuming all future parts remain relatively
> sane), but it would still complicate things if we were to ever do DT
> support for legacy CPUs. It's not enough to tie to the port type, as
> there are plenty of cases where the port type uses a non-standard algo on
> some CPU subtypes (although things are pretty consistent for the arm side
> so far).

regarding Laurent's question about the SCSCR register, do you think we
can assume the same there?
If so we could start out omitting these 2 properties and rely on
adding optional properties later in case we want to support legacy
stuff.
I don't see where it complicates things as we probably got the minimal
binding set then.

Thanks,

 Bastian