Re: RFC: tegra2/tegra3 automotive part changes

[Ben Dooks <ben.dooks@codethink.co.uk>]

On 13/07/18 17:53, Stephen Warren wrote:
> On 07/13/2018 03:41 AM, 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.
> 
> I believe this just changes the *selection* of values to use (clock 
> rates, clock sources), not *how* to program them (set of registers and 
> fields, programming algorithm), which is what the DT compatible is 
> mainly about. In other words, it's mainly a performance/configuration 
> decision not different HW.
> 
>> 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.
>>
>> PS, we'll want to do the same for the tegra20.
> 
> As Job mentioned, the fuse driver should/could be available early enough 
> without issue. It may have to (and probably already does) hard-code the 
> physical address of the fuses rather than being configured from DT for 
> this. I think if you read the chip "SKU" value from fuses, that should 
> indicate which sets of restrictions on clocks/... are required, and 
> there are many more SKUs than just "regular" and "automotive", although 
> all the different SKUs may be bucketed into fewer sets of 
> restriction/configuration data.
> 
> Briefly looking at drivers/soc/tegra/fuse/speedo-tegra20.c, some (a very 
> little) of this may already be there

Ok, the logs I have from one of the automotive systems has:

[] Tegra Revision: A03 SKU: 176 CPU Process: 3 SoC Process: 0

So would a test for:
	sku_info->revision == TEGRA_REVISION_A03 &&
	sku_info->sku_id == 176

be ok, or does that need some sort of mask?


I've not tried updating speedo-tegra30.c as I didn't really understand
what all the values where (and we didn't use cpufreq-scaling)

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel