From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 22 Aug 2014 12:50:30 -0600 Subject: [U-Boot] [PATCH 23/23] ARM: tegra: Enable PCIe on Jetson TK1 In-Reply-To: <20140822120943.GA15686@ulmo> References: <1408346196-30419-1-git-send-email-thierry.reding@gmail.com> <1408346196-30419-24-git-send-email-thierry.reding@gmail.com> <53F4EE37.3020003@wwwdotorg.org> <20140822120943.GA15686@ulmo> Message-ID: <53F790F6.9070401@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> >>> 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 >