[U-Boot] [PATCH 23/23] ARM: tegra: Enable PCIe on Jetson TK1

[Simon Glass]

Hi Thierry,

On 22 August 2014 06:09, Thierry Reding <thierry.reding at gmail.com> wrote:

> On Wed, Aug 20, 2014 at 12:51:35PM -0600, Stephen Warren wrote:
> > On 08/18/2014 01:16 AM, Thierry Reding wrote:
> > >From: Thierry Reding <treding at nvidia.com>
> > >
> > >The Jetson TK1 has an ethernet NIC connected to the PCIe bus and routes
> > >the second root port to a miniPCIe slot. Enable the PCIe controller and
> >
> > >diff --git a/arch/arm/dts/tegra124-jetson-tk1.dts
> b/arch/arm/dts/tegra124-jetson-tk1.dts
> >
> > >+    regulators {
> >
> > >+            /* Molex power connector */
> > >+            vdd_5v0_sata: regulator at 13 {
> > ...
> > >+            vdd_12v0_sata: regulator at 14 {
> >
> > Those two aren't in the kernel DT yet. I'll assume they match what's been
> > proposed for the SATA patches:-)
> >
> > >diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c
> b/board/nvidia/jetson-tk1/jetson-tk1.c
> >
> > A lot of the AS3722 code here duplicates what's in
> > board/nvidia/venice2/as3722_init.[ch]. It'd be good to put it all in one
> > place. Personally I'd be OK with putting it into the existing Venice2
> code,
> > but I suppose as Simon mentioned, a "real" AS3722 driver in
> > drivers/power/pmic would be a good idea.
>
> Unfortunately turning this into a real driver for AS3722 makes it
> impossible (or at least too difficult) to unify with the code in
> venice2/as3722_init.ch. The issue is that the new driver relies on
> infrastructure (I2C, FDT) that's not available in SPL (where this
> code is run). I tried extending the SPL with I2C and power drivers
> support so that I could use the driver here as well, but that keeps
> failing at various points, so I preferred having a proper driver for
> full U-Boot and kept the low-level code for CPU power rail setup as is.
>

That seems OK to me. When we have driver model in there we can perhaps
revisit things.


>
> Note that I haven't turned the AS3722 support into a "PMIC" driver,
> because the framework for that seems to be unusable. It doesn't seem to
> abstract away driver-specifics at all but rather provides a way to
> access registers in a uniform way (sort of what regmap does in Linux).
> Using that framework would therefore require knowledge about the exact
> register accesses within drivers and therefore wouldn't be an
> improvement over the current situation.
>

It doesn't provide a PMIC API as such - just a way to find a PMIC and the
access registers. I think it is useful for that at least.

Regards,
Simon