On 07/20/2018 04:25 AM, Ben Dooks wrote:
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 don't know all the automotive SKU numbers, but that seems like it
might be a good start. I'm not sure if SKU numbers are subordinate to
chip revisions (probably not) or global and apply to all chip revisions
(I guess so).
Let's create a helper function, something like
tegra_is_automotive_chip(), to centralize the check so it's easy to add
more SKUs/revisions in the future.
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)
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
