Thread (49 messages) flat view 49 messages, 5 authors, 2012-02-13

Re: Pinmux bindings proposal V2

From: Tony Lindgren <hidden>
Date: 2012-01-26 17:51:37
Also in: linux-arm-kernel, lkml

Hi,

* Shawn Guo [off-list ref] [120126 00:53]:
On Mon, Jan 23, 2012 at 01:00:52PM -0800, Tony Lindgren wrote:
...
quoted
So to summarize: I suggest we'll just stick to basics to get the system
booting and devices working using device tree. In most cases the device
drivers should be able to configure the suspend and off states in a generic
way using pinctrl API. Everything else, like debugging, we can probably
do with userspace tools.

This would mean just using a minimal subset of your binding, probably
very close to what you originally suggested.
IMHO, as a generic device tree binding, it should be able to cope with
different use cases.  It's really free for you to use the minimal
subset of the binding as your need, but we should not make the binding
design just be that minimal subset to force that everyone else can
only use the minimal subset.
The main issue I have is that the example posted in this thread repeats
the same registers five times for one driver entry alone in the device
tree data. The repeated registers are TEGRA_PMX_PG_DTA and TEGRA_PMX_PG_DTD
in the example.

The alternative values are something that the pinmux/pinconf driver can
set based on state changes communicated from the driver using these pins.

That's why I think these alternative states should not be listed in the
device tree.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help