On 13/07/18 10:41, Ben Dooks wrote:
> On 12/07/18 16:56, Stephen Warren wrote:
>> On 07/12/2018 07:36 AM, Ben Dooks wrote:
>>> Hello, we are looking at up-streaming some of the work we have
>>> done on the tegra2 and tegra3 automotive devices. The automotive
>>> grade devices are close the commercial parts so we would like to
>>> discuss the core changes before submitting.
>>>
>>> The changes are mostly with things like the clock setup and a
>>> few peripheral quirks (IIRC these are mostly MMC).
>>>
>>> We are proposing to change the device-tree properties for the root
>>> node and any other affected devices from "nvidia,tegraXX" to a new
>>> "nvidia,tegraXXa". We would welcome discussion on whether to update
>>> all the devices at the start
>>>
>>> An example of tegra30a.dtsi:
>>>
>>> #include "tegra30.dtsi"
>>>
>>> / {
>>> compatible = "nvidia,tegra30a";
>>>
>>> clock@60006000 {
>>> compatible = "nvidia,tegra30a-car";
>>> };
>>> }
>>
>> This doesn't sound right. Auto and commercial parts are identical AFAIK; it's just qualification differences. Hence at most you'd add an extra compatible value and not remove the old one. Better might be to detect this at run-time from the fuses. I think we already do some of that already; search for speedo related code in arch/arm/mach-tegra/.
>
> The nvidia pdk for the automotive didn't set the clocks up in the
> same way and we where told that there are certain clock restrictions
> for the automotive parts that the commercial ones do not have. Some of
> this came from internal discussions with nvidia and NDA'd datasheets
> so I don't know how much actual data I can share.
>
> To get the 4.4 kernel to be similar enough to work with the tegra30a
> we had to do some changes to the clock initialisation. For things
> like the clock I am not sure if leaving a tegra30-car in there would
> be a good idea, it may boot but probably won't be stable.
>
> For the fuses, is the fuse driver up early enough to allow the clock
> driver could use this? otherwise I think the device-tree change would
> be the only way. I'm not sure if I have the information to hand on
> how to differentiate the tegra30 and tegra20.
It should be, if you see drivers/soc/tegra/fuse/fuse-tegra.c there is an
'early_initcall(tegra_init_fuse)' and there is a 'tegra_fuse_read_early()'
function that can be used.
Cheers
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
