* RFC: tegra2/tegra3 automotive part changes
@ 2018-07-12 13:36 ` Ben Dooks
0 siblings, 0 replies; 20+ messages in thread
From: Ben Dooks @ 2018-07-12 13:36 UTC (permalink / raw)
To: linux-tegra, Device Tree list, linux-arm-kernel, Thomas Preston,
Terry Hu, jorgesanjuan, Beth White
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";
};
}
We don't think the changes are big enough to warrant their own
Kconfig/defconfig updates.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply [flat|nested] 20+ messages in thread* RFC: tegra2/tegra3 automotive part changes @ 2018-07-12 13:36 ` Ben Dooks 0 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-12 13:36 UTC (permalink / raw) To: linux-arm-kernel 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 at 60006000 { compatible = "nvidia,tegra30a-car"; }; } We don't think the changes are big enough to warrant their own Kconfig/defconfig updates. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-12 13:36 ` Ben Dooks @ 2018-07-12 13:50 ` Mikko Perttunen -1 siblings, 0 replies; 20+ messages in thread From: Mikko Perttunen @ 2018-07-12 13:50 UTC (permalink / raw) To: Ben Dooks, linux-tegra, Device Tree list, linux-arm-kernel, Thomas Preston, Terry Hu, jorgesanjuan, Beth White On 07/12/2018 04:36 PM, 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"; > }; > } > > We don't think the changes are big enough to warrant their own > Kconfig/defconfig updates. > What kind of changes do you have? Tegra30a would point to a separate SoC revision of Tegra3 the existence of which I'm not aware of. If you can show some of the changes it would be easier to say how the system should be specified. Thanks, Mikko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-12 13:50 ` Mikko Perttunen 0 siblings, 0 replies; 20+ messages in thread From: Mikko Perttunen @ 2018-07-12 13:50 UTC (permalink / raw) To: linux-arm-kernel On 07/12/2018 04:36 PM, 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 at 60006000 { > ??????????????? compatible = "nvidia,tegra30a-car"; > ??????? }; > } > > We don't think the changes are big enough to warrant their own > Kconfig/defconfig updates. > What kind of changes do you have? Tegra30a would point to a separate SoC revision of Tegra3 the existence of which I'm not aware of. If you can show some of the changes it would be easier to say how the system should be specified. Thanks, Mikko ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-12 13:50 ` Mikko Perttunen @ 2018-07-12 15:07 ` Ben Dooks -1 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-12 15:07 UTC (permalink / raw) To: Mikko Perttunen, linux-tegra, Device Tree list, linux-arm-kernel, Thomas Preston, Terry Hu, jorgesanjuan, Beth White On 12/07/18 14:50, Mikko Perttunen wrote: > On 07/12/2018 04:36 PM, 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"; >> }; >> } >> >> We don't think the changes are big enough to warrant their own >> Kconfig/defconfig updates. >> > > What kind of changes do you have? Tegra30a would point to a separate SoC > revision of Tegra3 the existence of which I'm not aware of. If you can > show some of the changes it would be easier to say how the system should > be specified. I'm just working on the core clock initialisation patches as our original work was just patching the tegra20 and tegra30 clock init tables. As far as we can see the tegra30 automotive grade silicon is mostly compatible with the tegra30 but has some clock restrictions and initialisation changes. -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-12 15:07 ` Ben Dooks 0 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-12 15:07 UTC (permalink / raw) To: linux-arm-kernel On 12/07/18 14:50, Mikko Perttunen wrote: > On 07/12/2018 04:36 PM, 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 at 60006000 { >> ???????????????? compatible = "nvidia,tegra30a-car"; >> ???????? }; >> } >> >> We don't think the changes are big enough to warrant their own >> Kconfig/defconfig updates. >> > > What kind of changes do you have? Tegra30a would point to a separate SoC > revision of Tegra3 the existence of which I'm not aware of. If you can > show some of the changes it would be easier to say how the system should > be specified. I'm just working on the core clock initialisation patches as our original work was just patching the tegra20 and tegra30 clock init tables. As far as we can see the tegra30 automotive grade silicon is mostly compatible with the tegra30 but has some clock restrictions and initialisation changes. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-12 13:36 ` Ben Dooks @ 2018-07-12 15:56 ` Stephen Warren -1 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-12 15:56 UTC (permalink / raw) To: Ben Dooks Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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/. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-12 15:56 ` Stephen Warren 0 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-12 15:56 UTC (permalink / raw) To: linux-arm-kernel 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 at 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/. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-12 15:56 ` Stephen Warren @ 2018-07-13 9:41 ` Ben Dooks -1 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-13 9:41 UTC (permalink / raw) To: Stephen Warren Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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. PS, we'll want to do the same for the tegra20. -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-13 9:41 ` Ben Dooks 0 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-13 9:41 UTC (permalink / raw) To: linux-arm-kernel 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 at 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. PS, we'll want to do the same for the tegra20. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-13 9:41 ` Ben Dooks @ 2018-07-13 9:58 ` Jon Hunter -1 siblings, 0 replies; 20+ messages in thread From: Jon Hunter @ 2018-07-13 9:58 UTC (permalink / raw) To: Ben Dooks, Stephen Warren Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-13 9:58 ` Jon Hunter 0 siblings, 0 replies; 20+ messages in thread From: Jon Hunter @ 2018-07-13 9:58 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-13 9:58 ` Jon Hunter @ 2018-07-13 12:51 ` Ben Dooks -1 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-13 12:51 UTC (permalink / raw) To: Jon Hunter, Stephen Warren Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White On 13/07/18 10:58, Jon Hunter wrote: > > 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. Ok, I've tried looking through all the data-sheets I have and I can't find any data on which fuse-bits would be needed to identify the two versions. Does anyone else know where to look? -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-13 12:51 ` Ben Dooks 0 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-13 12:51 UTC (permalink / raw) To: linux-arm-kernel On 13/07/18 10:58, Jon Hunter wrote: > > 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 at 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. Ok, I've tried looking through all the data-sheets I have and I can't find any data on which fuse-bits would be needed to identify the two versions. Does anyone else know where to look? -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-13 9:41 ` Ben Dooks @ 2018-07-13 16:53 ` Stephen Warren -1 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-13 16:53 UTC (permalink / raw) To: Ben Dooks Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-13 16:53 ` Stephen Warren 0 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-13 16:53 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-13 16:53 ` Stephen Warren @ 2018-07-20 10:25 ` Ben Dooks -1 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-20 10:25 UTC (permalink / raw) To: Stephen Warren Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-20 10:25 ` Ben Dooks 0 siblings, 0 replies; 20+ messages in thread From: Ben Dooks @ 2018-07-20 10:25 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC: tegra2/tegra3 automotive part changes 2018-07-20 10:25 ` Ben Dooks @ 2018-07-24 19:25 ` Stephen Warren -1 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-24 19:25 UTC (permalink / raw) To: Ben Dooks Cc: Terry Hu, Device Tree list, jorgesanjuan, Thomas Preston, linux-tegra, linux-arm-kernel, Beth White 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) > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 20+ messages in thread
* RFC: tegra2/tegra3 automotive part changes @ 2018-07-24 19:25 ` Stephen Warren 0 siblings, 0 replies; 20+ messages in thread From: Stephen Warren @ 2018-07-24 19:25 UTC (permalink / raw) To: linux-arm-kernel 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 at 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) > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-07-24 19:25 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-12 13:36 RFC: tegra2/tegra3 automotive part changes Ben Dooks 2018-07-12 13:36 ` Ben Dooks 2018-07-12 13:50 ` Mikko Perttunen 2018-07-12 13:50 ` Mikko Perttunen 2018-07-12 15:07 ` Ben Dooks 2018-07-12 15:07 ` Ben Dooks 2018-07-12 15:56 ` Stephen Warren 2018-07-12 15:56 ` Stephen Warren 2018-07-13 9:41 ` Ben Dooks 2018-07-13 9:41 ` Ben Dooks 2018-07-13 9:58 ` Jon Hunter 2018-07-13 9:58 ` Jon Hunter 2018-07-13 12:51 ` Ben Dooks 2018-07-13 12:51 ` Ben Dooks 2018-07-13 16:53 ` Stephen Warren 2018-07-13 16:53 ` Stephen Warren 2018-07-20 10:25 ` Ben Dooks 2018-07-20 10:25 ` Ben Dooks 2018-07-24 19:25 ` Stephen Warren 2018-07-24 19:25 ` Stephen Warren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.