On 2013-08-13 10:46, Mark Rutland wrote:
[Adding Marc to Cc]

On Tue, Aug 13, 2013 at 08:24:31AM +0100, Rajendra Nayak wrote:
[]..

>> +
>> +       cpus {
>> +               cpu@0 {
>> +                       compatible = "arm,cortex-a15";
>> +                       timer {
>> +                               compatible = "arm,armv7-timer";
>> +                               /*
>> +                                * PPI secure/nonsecure IRQ,
>> +                                * active low level-sensitive
>> +                                */
>> +                               interrupts = <1 13 0x308>,
>> +                                            <1 14 0x308>;
>> +                               clock-frequency = <6144000>;
>> +                       };
>> +               };
>
> The cpu nodes should have a reg matching their unit-address, and a
> device_type = "cpu".
>
> The timer nodes should *not* be under the CPU nodes. They should be > under under the root node. I realise that it makes intuitive sense to > describe per-cpu resources this way, but that's not the way the bindings
> are intended to be used (does thei DT even work?).
>
> No virtual/hypervisor interrupts?

Mark, all valid points. I just updated the patch to include all the missing interrupts and registers for timer and gic and moved the timer node out as
its supposed to be.

Great!


>
> Do you really need the clock-frequency property? It's far preferrable to > have your bootloader do the right thing and program CNTFRQ with the
> correct value.

I kept the clock-frequency property since our bootloader does not handle this and I am not sure if its a good idea to have the dependency on bootloader
to do this.

There is precedent for handling it this way, but it would be far nicer to fix the bootloader to set CNTFRQ. For one thing it's only writeable from the secure side, so a host os can't fix it up for guests that might depend on it rather than dt. I realise it's not necessarily as simple as
it sounds to fix that up, however.

Indeed, having the wrong CNTFRQ in the host has the unfortunate effect of propagating the crap into the guests.

While this can be worked around for Linux guests (you have to hack the DT passed to the guests, which is very unpleasant at best and varies from one host to another), there is nothing you can do for non-DT guests.

So please, fix it in your firmware/boot-ROM while it is still time.

Thanks,

        M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to