| Message ID | 1420540653-14816-2-git-send-email-tomeu.vizoso@collabora.com |
|---|---|
| State | Deferred |
| Headers | show |
On 01/06/2015 03:37 AM, Tomeu Vizoso wrote: > Following 6dbaff2b, the kernel expects that the bootloader has correctly > programmed the Tegra pinmux. > > DTs for the Jetson and the Venice2 had been updated already but this one > was left behind. So this setup is true for NVIDIA-controlled development/reference boards where we've ensured that the bootloader sets up 100% of the pinmux. However, I know that Coreboot on this board doesn't set up everything in the pinmux, and since it's in r/o flash never will. As such, I'm not sure this change is safe for this board. That is, unless you want to force upstream kernels to be booted via a chain-loaded path: Coreboot (r/o) -> U-Boot (r/w with full pinmux setup) -> kernel. > Have tested this with the stock vendor firmware (coreboot) and have found no > issues. There are presumably a bunch of features which aren't yet supported upstream, and hence you couldn't test though? That means we might find that parts of the pinmux aren't yet programmed but need to be to enable those features. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 6, 2015 at 9:09 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 01/06/2015 03:37 AM, Tomeu Vizoso wrote: >> >> Following 6dbaff2b, the kernel expects that the bootloader has correctly >> programmed the Tegra pinmux. >> >> DTs for the Jetson and the Venice2 had been updated already but this one >> was left behind. > > > So this setup is true for NVIDIA-controlled development/reference boards > where we've ensured that the bootloader sets up 100% of the pinmux. > > However, I know that Coreboot on this board doesn't set up everything in the > pinmux, and since it's in r/o flash never will. As such, I'm not sure this > change is safe for this board. That is, unless you want to force upstream > kernels to be booted via a chain-loaded path: Coreboot (r/o) -> U-Boot (r/w > with full pinmux setup) -> kernel. That's correct. We did have a patch floating around to configure all the pinmux settings in coreboot, but that never made it in. While we could issue a R/W firmware update to apply the pinmux settings (unlikely to happen), it would still result in pinmux settings being applied in two separate locations - which, IIRC, was exactly what Stephen was trying to avoid by moving pinmux out of the device-trees. So I'd agree that pulling the pinmux settings out of the nyan* device-trees is not a good idea. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 6 January 2015 at 18:09, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 01/06/2015 03:37 AM, Tomeu Vizoso wrote: >> >> Following 6dbaff2b, the kernel expects that the bootloader has correctly >> programmed the Tegra pinmux. >> >> DTs for the Jetson and the Venice2 had been updated already but this one >> was left behind. > > > So this setup is true for NVIDIA-controlled development/reference boards > where we've ensured that the bootloader sets up 100% of the pinmux. > > However, I know that Coreboot on this board doesn't set up everything in the > pinmux, and since it's in r/o flash never will. As such, I'm not sure this > change is safe for this board. That is, unless you want to force upstream > kernels to be booted via a chain-loaded path: Coreboot (r/o) -> U-Boot (r/w > with full pinmux setup) -> kernel. > >> Have tested this with the stock vendor firmware (coreboot) and have found >> no >> issues. > > > There are presumably a bunch of features which aren't yet supported > upstream, and hence you couldn't test though? That means we might find that > parts of the pinmux aren't yet programmed but need to be to enable those > features. Sure, there's no chance that my testing could have been extensive enough. Following Andrew's feedback, I will be looking at getting the pinmux programming right in the DTs. Thanks, Tomeu > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/07/2015 01:06 AM, Tomeu Vizoso wrote: > On 6 January 2015 at 18:09, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 01/06/2015 03:37 AM, Tomeu Vizoso wrote: >>> >>> Following 6dbaff2b, the kernel expects that the bootloader has correctly >>> programmed the Tegra pinmux. >>> >>> DTs for the Jetson and the Venice2 had been updated already but this one >>> was left behind. >> >> >> So this setup is true for NVIDIA-controlled development/reference boards >> where we've ensured that the bootloader sets up 100% of the pinmux. >> >> However, I know that Coreboot on this board doesn't set up everything in the >> pinmux, and since it's in r/o flash never will. As such, I'm not sure this >> change is safe for this board. That is, unless you want to force upstream >> kernels to be booted via a chain-loaded path: Coreboot (r/o) -> U-Boot (r/w >> with full pinmux setup) -> kernel. >> >>> Have tested this with the stock vendor firmware (coreboot) and have found >>> no >>> issues. >> >> >> There are presumably a bunch of features which aren't yet supported >> upstream, and hence you couldn't test though? That means we might find that >> parts of the pinmux aren't yet programmed but need to be to enable those >> features. > > Sure, there's no chance that my testing could have been extensive enough. > > Following Andrew's feedback, I will be looking at getting the pinmux > programming right in the DTs. As an FYI, the way this typically works (for NVIDIA reference boards, and many/most customer boards) is that NVIDIA syseng publishes an Excel spreadsheet that can be edited to define the board's pinmux, and which performs some error checks. This spreadsheet can directly generate (via Excel macros/...) pinmux data tables and/or DT files for our product/internal/downstream Android and L4T kernels. For recent SoCs, the tegra-pinmux-scripts project[1] can take a CSV representation of the spreadsheet and generate both a U-Boot header file (for upstream or L4T; they're the same) and upstream Linux kernel DT files that represent the pinmux. So, your best bet is to see if such a spreadsheet exists for these platforms, and import it into tegra-pinmux-scripts. That will save a lot of work if the spreadsheet exists (and is up-to-date). [1] https://github.com/NVIDIA/tegra-pinmux-scripts -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts index 53181d3..4752572 100644 --- a/arch/arm/boot/dts/tegra124-nyan-big.dts +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts @@ -44,10 +44,10 @@ }; pinmux@0,70000868 { - pinctrl-names = "default"; - pinctrl-0 = <&pinmux_default>; + pinctrl-names = "boot"; + pinctrl-0 = <&pinmux_boot>; - pinmux_default: common { + pinmux_boot: common { dap_mclk1_pw4 { nvidia,pins = "dap_mclk1_pw4"; nvidia,function = "extperiph1";
Following 6dbaff2b, the kernel expects that the bootloader has correctly programmed the Tegra pinmux. DTs for the Jetson and the Venice2 had been updated already but this one was left behind. Have tested this with the stock vendor firmware (coreboot) and have found no issues. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> --- arch/arm/boot/dts/tegra124-nyan-big.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)