On 03/09/2015 10:40 AM, Daniel Stone wrote:
Hi,
Stephen Warren <swarren@...> writes:
On 03/09/2015 09:36 AM, Daniel Stone wrote:
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.
Fair enough. I came into this hoping to spend rather less time on it than I
did. ;)
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?
Sure, I've attached it
That's quite a large list. I guess since ChromeOS works without
configuring all those missing pins, we should probably not put
values/configuration for those pins into tegra-pinmux-scripts.
Otherwise, we can't know what values to set for any of those pins. I
think missing information is better than present information that might
be actively wrong.
That is, unless you want to extract the actual configuration that's
programmed into HW from a running system, under the ChromeOS kernel. At
least we'd then have a set of data that's 100% aligned with what's
actually in use on production systems.
I wish the ChromeOS boards had had one of the NVIDIA syseng-supplied
pinmux spreadsheets created. Then, we'd know exactly how everything was
supposed to be configured, or even if there were bugs in the
spreadsheet, at least have a single canonical source for the data, and
source to fix.
after having done Blaze as well (pushed to the same
tree, totally untested in any way; Big at least boots and gives me
USB/eMMC/eDP/HDMI). The only difference between the two is that Blaze does
have a definition for kb_row11_ps[34]. I've not checked to see if these are
actually required / in use, i.e. whether we do need them or if we're just
getting lucky with existing/default configuration. I'll do this before I
post the final patchset.
It's good the two boards are very similar. At least that corresponds
well with them both having been derived from the same reference board.
--
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
