[PATCH 1/2] ARM: Tegra: dt: Split out separate Tegra SoC DT

[Grant Likely]

On Thu, May 12, 2011 at 6:40 PM, Stephen Warren <swarren at nvidia.com> wrote:
> Grant Likely wrote at Monday, May 02, 2011 2:16 PM:
>> On Mon, May 2, 2011 at 12:00 PM, Stephen Warren <swarren at nvidia.com> wrote:
>> > Olof Johansson wrote at Sunday, May 01, 2011 8:56 AM:
>> >> On Fri, Apr 29, 2011 at 10:12:30PM -0600, Stephen Warren wrote:
>> >> A mostly unrelated question below.
>> >>
>> >> [...]
>> >>
>> >> > +   serial at 70006000 {
>> >> > +           compatible = "nvidia,tegra250-uart";
>> >>
>> >> I know this is how Grant specified it, but shouldn't these also have
>> >> a compat for ns16550?
>> >
>> > At present, I'm not sure it is technically compatible. If you look at
>> > drivers/tty/serial/of_serial.c, you'll see:
>> >
>> > static struct of_device_id __devinitdata of_platform_serial_table[] = {
>> > ...
>> >        { .compatible = "ns16550",  .data = (void *)PORT_16550, },
>> > ...
>> >        { .compatible = "nvidia,tegra250-uart",  .data = (void *)PORT_XSCALE, },
>> >
>> > That PORT_XSCALE is different to the ns16550 entry. Arguably, that
>> > field should be something that comes from the device tree, just
>> > like e.g. reg-shift, but it certainly doesn't right now.
>> >
>> > Grant, what are your thoughts on this?
>>
>> Heh, when I added that line I just mirrored the 'type' of 16550 as
>> detected by the 8250.c driver when it probes and made a mental note
>> that it should be revisited.  I don't know the hardware very well, so
>> I cannot easily say what the right thing to do is, but making it
>> ns16550 compatible does seem to make sense.
>
> I looked into this a bit more and found the following:
>
> In all the existing board files for Tegra, none of the
> plat_serial8250_port initializations specify any type value, and equally
> the flags do not include UPF_FIXED_TYPE. This causes the UART driver to
> probe (run tests on) the hardware to determine exactly what type of UART
> is present.
>
> However, of_serial.c does set UPF_FIXED_TYPE, and hence port->type must
> have a valid value. I suspect it'd be a bad idea to change this since
> it'd affect a ton of extant PPC platforms.
>
> Equally, PORT_XSCALE does imply different HW behavior to any of the
> other types, so tegra250.dtsi shouldn't just specify that it's compatible
> with "ns16550".

I investigated and found the same thing, and that is why I set up the
current code the way I did; to preserve the current behaviour.

However, is the current behaviour even right?  My impression from the
code is that probing for the type of ns16550 is little more than an
accident.  Is xscale really the best behaviour to select fro this
device?

g.