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

[Stephen Warren]

On 08/22/2014 06:09 AM, Thierry Reding 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.

Ah yes. That makes sense.

> 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.
>
> Thierry
>