
Hi Stephen,
On 27 April 2016 at 10:24, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/27/2016 09:12 AM, Simon Glass wrote:
Hi Stephen,
On 19 April 2016 at 14:59, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
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 swarren@nvidia.com
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.
When you probe a device, its pinmux is set up automatically, so the explicit funcmux calls can go away.
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.
There's no need for it to read from DT, and it doesn't have to be comprehensive but I think you should create a pinctrl driver and put the funcmux stuff in that (along with processing your big tables of pinmux stuff).
Regards, Simon