On 03/09/2015 09:36 AM, Daniel Stone wrote:
Hi Stephen,
Thanks for looking at this.
On Fri, 6 Mar, 2015 at 8:46 PM, Stephen Warren <swarren@xxxxxxxxxxxxx>
wrote:
On 03/06/2015 01:42 PM, Simon Glass wrote:
On 6 March 2015 at 13:31, Stephen Warren <swarren@xxxxxxxxxxxxx
<mailto:swarren@xxxxxxxxxxxxx>> wrote:
Can you comment on this change? If the data currently in
tegra-pinmux-scripts is wrong, where did it come from if not
the ChromeOS kernel?
Sorry, I have no direct knowledge.
Oh, I see the answer in the patch description:
commit 4a5373e4bd6477addd3764e25989f74d34eba8c6 Author: Simon
Glass <sjg@xxxxxxxxxxxx <mailto:sjg@xxxxxxxxxxxx>> Date: Tue Feb 3
11:29:03 2015 +0100 Add support for Nyan-big Add support for
Tegra124 Nyan-big. Pinmux is based on norrin with a single change
for the reset GPIO.
The need for Daniel's patch seems like a good reason not to base one
board's pinmux on another board, assuming they're identical...
Indeed.
Daniel, have you confirmed that 100% of the data in your patch matches
that used by the ChromeOS kernel, such that there shouldn't be any
more fixes needed down the line?
Actually, no, I hadn't. The diff is annoying to produce, as the format
used in chromeos-3.10 is totally different (different pin naming scheme,
aggregation of one entry to multiple nvidia,pins entries),
I guess this is roughly what your Perl script does, but in the past I've
written one-off scripts to import our downstream DT files into the
*.board format that tegra-pinmux-scripts uses, and then diff'd that. The
advantage here is that I can then use the output with tegra-pinmux-scripts.
but I managed
to get a full diff with a blindingly horrible bit of Perl[0] (take
chromeos-3.10 entries, map names -> numbers, map back from numbers to
current upstream names, produce DT fragment), and then manually
reconcile that back to tegra-pinmux-scripts to remove the delta.
There is only a small delta remaining between the two after manually
harmonising these. First, the nvidia,lock property was set downstream
but t-p-s doesn't seem to have any facility for handling this - is that
a problem?
Lock doesn't do anything that would functionally affect the pinmux
assuming there are no SW bugs that come along and corrupt the pinmux
registers later. All lock does is prevent any changes to that particular
register/pin after the bit is set. Good for safety, but shouldn't have
any impact.
> Secondly, chromeos-3.10 used TEGRA_PIN_PULL_DOWN for rcv-sel
being enabled, which just happened to map to 1 (ENABLED).
Yikes!
And lastly,
there are a number of entries in nyan-big.config which aren't present in
the downstream config. If these entries are unneeded (presumably unused
... ?), should they be removed?
Typically I'd hope that every pin had an explicit configuration, so that
we know we've actively avoided any conflicting settings. Do you have a
list of the pins that aren't configured in the ChromeOS kernel but are
in the updated tegra-pinmux-scripts config file?
These patches are sitting in
git://git.collabora.com/git/user/daniels/tegra-pinmux-scripts - I'll
post them after myself & Tomeu have done some more testing on them, as
there are a rather worrying amount of changes. I can do the same to
Blaze as well, but that'll have to wait a couple of days as I don't
actually have one on my desk.
Cheers,
Daniel
[0]: It really is horrible, and is only intended to be throwaway.
http://people.collabora.com/~daniels/tmp/reconcile-downstream-dt.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
