From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 27 Apr 2016 10:24:59 -0600 Subject: [U-Boot] [PATCH 55/60] i2c: tegra: move pinmux setup to board files In-Reply-To: References: <1461099580-3866-1-git-send-email-swarren@wwwdotorg.org> <1461099580-3866-56-git-send-email-swarren@wwwdotorg.org> Message-ID: <5720E7DB.4030900@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/27/2016 09:12 AM, Simon Glass wrote: > Hi Stephen, > > On 19 April 2016 at 14:59, Stephen Warren wrote: >> From: Stephen Warren >> >> Remove funcmux calls from the Tegra I2C driver. Knowledge of pinmux >> setup must come from either board files or DT; it should not be embedded >> into board-agnostic driver code. The DT pinmux bindings do not allow >> drivers to derive funcmux-style information, since the DT bindings are >> pin-based whereas funcmux is controller-based, so there's no good way to >> call the existing funcmux APIs from drivers. Converting drivers to use a >> new (as yet non-existent in U-Boot) API that pulls pinmux information from >> DT isn't useful for Tegra, since Tegra's DT files don't contain any >> per-device pinmux tables, so this would simply be extra code that has no >> effect; doesn't actually set up the pinmux. We are left with moving the >> pinmux setup functionality into board files. In theory the board files >> could be converted later to use DT, but that would be a separate change. >> >> Signed-off-by: Stephen Warren >> --- >> board/avionic-design/common/tamonten.c | 5 +++++ >> board/nvidia/seaboard/seaboard.c | 3 +++ >> board/nvidia/whistler/whistler.c | 1 + >> board/toradex/colibri_t20/colibri_t20.c | 3 +++ >> drivers/i2c/tegra_i2c.c | 19 ------------------- >> 5 files changed, 12 insertions(+), 19 deletions(-) > > This should use driver model, which handles pinmux automatically if > you have a pinctrl driver. Can you define "automatic"? I don't understand exactly which benefit you're describing there. I'd rather keep this series as simple cleanup of existing code, and handle any large-scale DM conversions separately later. That said, as full disclosure, I'm certainly not signing up for any more work on pinctrl, especially if it involves reading the pinmux tables from DT, as I see no benefit in that. Note that in future chips the boot ROM will handle 100% of static pinmux setup so there won't be a U-Boot driver for those SoCs going forward. I'd rather not invest any more than minimal effort in something that's going away.