[PATCH V2 1/4] pinctrl: tegra: remove redundant data table fields
Linus Walleij
linus.walleij at linaro.org
Tue Apr 22 07:49:35 PDT 2014
On Tue, Apr 15, 2014 at 7:00 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> From: Stephen Warren <swarren at nvidia.com>
>
> Any SoC which supports the einput, odrain, lock, ioreset, or rcv_sel
> options has the relevant HW register fields in the same register as the
> mux function selection. Similarly, the drvtype option is always in the
> drive register, if it is supported at all. Hence, we don't need to have
> struct *_reg fields in the pin group table to define which register and
> bank to use for those options. Delete this to save space in the driver's
> data tables.
>
> However, many of those options are not supported on all SoCs, or not
> supported on some pingroups. We need a way to detect when they are
> supported. Previously, this was indicated by setting the struct *_reg
> field to -1. With the struct *_reg fields removed, we use the struct
> *_bit fields for this purpose instead. The struct *_bit fields need to
> be expanded from 5 to 6 bits in order to store a value outside the valid
> HW bit range of 0..31.
>
> Even without removing the struct *_reg fields, we still need to add code
> to validate the struct *_bit fields, since some struct *_bit fields were
> already being set to -1, without an option-specific struct *_reg field to
> "guard" them. In other words, before this change, the pinmux driver might
> allow some unsupported options to be written to HW.
>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> (Note: For V2, I'm only reposting patch 1/4, since patch 2/4 is large, and
> I don't want to spam the list again with the whole series)
>
> v2:
> * Modify width of struct tegra_pingroup's drvtype_bit in the same way as
> other *_bit fields.
> * Fix struct tegra_pingroup's documentation to match the changes made
> to the struct.
> * Fix pinctrl-tegra20.c's DRV_PG_EXT() macro to initialize the drvtype_bit
> field.
This v2 version applied.
Yours,
Linus Walleij
More information about the linux-arm-kernel
mailing list