From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Fri, 22 Aug 2014 13:27:57 -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: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Thierry, On 22 August 2014 06:09, 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. > 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