From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 12 Aug 2015 08:18:49 -0600 Subject: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree In-Reply-To: <20150812115202.GA9068@rhino.kodakalaris.net> References: <20150809010859.GA3842@bradfordembedded.com> <20150810113256.GA3645@rhino.kodakalaris.net> <20150811120820.GA13429@rhino.kodakalaris.net> <20150811152038.GC13429@rhino.kodakalaris.net> <20150812115202.GA9068@rhino.kodakalaris.net> 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 Andrew, On 12 August 2015 at 05:52, Andrew Bradford wrote: > Hi Simon, > > On 08/11 21:54, Simon Glass wrote: >> +Gabriel >> >> Hi Andrew, >> >> On 11 August 2015 at 09:20, Andrew Bradford wrote: >> > Hi Simon, >> > >> > On 08/11 08:06, Simon Glass wrote: >> >> Hi Andrew, >> >> >> >> On 11 August 2015 at 06:08, Andrew Bradford wrote: >> >> > Hi Simon, >> >> > >> >> > On 08/10 21:07, Simon Glass wrote: >> >> >> Hi Bin, >> >> >> >> >> >> On 10 August 2015 at 20:53, Bin Meng wrote: >> >> >> > Hi Andrew, >> >> >> > >> >> >> > On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford >> >> >> > wrote: >> >> >> >> Hi Bin, >> >> >> >> >> >> >> >> On 08/09 10:52, Bin Meng wrote: >> >> >> >>> Hi Andrew, >> >> >> >>> >> >> >> >>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford >> >> >> >>> wrote: >> >> >> >>> > Hi Simon, >> >> >> >>> > >> >> >> >>> > On 08/08 10:18, Simon Glass wrote: >> >> >> >>> >> Hi, >> >> >> >>> >> >> >> >> >>> >> On 7 August 2015 at 06:44, Bin Meng wrote: >> >> >> >>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford >> >> >> >>> >> > wrote: >> >> >> >>> >> >> From: Andrew Bradford >> >> >> >>> >> >> >> >> >> >>> >> >> Allow for configuration of FSP UPD from the device tree which will >> >> >> >>> >> >> override any settings which the FSP was built with itself. >> >> >> >>> >> >> >> >> >> >>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD >> >> >> >>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files, >> >> >> >>> >> >> with the condition that the memory-down parameters for MinnowMax are >> >> >> >>> >> >> also used. >> >> >> >>> >> >> >> >> >> >>> >> >> Signed-off-by: Andrew Bradford >> >> >> >>> >> >> --- >> >> >> >>> >> >> >> >> >> >>> >> > >> >> >> >>> >> > Reviewed-by: Bin Meng >> >> >> >>> >> > Tested-by: Bin Meng >> >> >> >>> >> > >> >> >> >>> >> >> >> >> >>> >> Acked-by: Simon Glass >> >> >> >>> >> Tested on minnowmax: >> >> >> >>> >> Tested-by: Simon Glass >> >> >> >>> >> >> >> >> >>> >> I found that I need to remove two properties from the minnowmax.dts: >> >> >> >>> >> >> >> >> >>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot >> >> >> >>> >> at present and stops EHCI from working >> >> >> >>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information >> >> >> >>> >> being displayed >> >> >> >>> >> >> >> >> >>> >> I plan to apply this with these changes - please let me know if this >> >> >> >>> >> doesn't suit. >> >> >> >>> > >> >> >> >>> > I'm OK with disabling xhci and the MRC debug output in the FSP. >> >> >> >>> > >> >> >> >>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0 >> >> >> >>> > port on Minnow Max will only act as a USB 2.0 port. That u-boot doesn't >> >> >> >>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't >> >> >> >>> > sure which was a better choice. >> >> >> >>> >> >> >> >>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it >> >> >> >>> works, I'd rather we keep fsp,enable-xhci in the U-Boot. >> >> >> >> >> >> >> >> I believe that the xhci port does work on Minnow Max in Linux but I do >> >> >> >> not have a board so I'm unable to test, sorry. >> >> >> >> >> >> >> > >> >> >> > OK, my test shows that ehci works fine in U-Boot on Bayley Bay. >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > What do you think regarding to xhci vs. ehci in U-Boot? >> >> >> >> >> >> The problem is that USB is then broken in U-Boot. I think it is better >> >> >> to limit the speed for the moment until we have that fixed. It is >> >> >> quite useful to be able to use a keyboard or USB stick in U-Boot. >> >> >> >> >> >> With my testing the bottom (blue) port works fine but the top port >> >> >> does not. This happens regardless of the xhci setting. >> >> > >> >> > Minnowmax has a USB power switch enable which determines if the VBUS2 >> >> > net is turned on or not, which will supply or not supply power to the >> >> > USB 2.0 port. The blue USB 3.0 port also has an enable. Both enables >> >> > and the USB ports themselves are located on page 16 of the schematic >> >> > that I have. >> >> > >> >> > The switches to enable the VBUS for each port are active high and pulled >> >> > down. So to turn them on, I believe that's the point of the pinmuxing >> >> > and GPIO settings which are used in the minnowmax.dts. Can you verify >> >> > if these are correctly turning on VBUS2 (since it sounds like they are >> >> > turning on VBUS1)? If not, when you turn these GPIO on manually, does >> >> > the USB 2.0 port work correctly? >> >> >> >> I see power on the bottom port but not the top one. >> > >> > OK, that's odd, but likely can be fixed with changes to the pin mux and >> > pad settings in the dts. I believe that the "pad-offset" for >> > pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of >> > 0x258. >> > >> > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts >> > index d0c0fe6..4988163 100644 >> > --- a/arch/x86/dts/minnowmax.dts >> > +++ b/arch/x86/dts/minnowmax.dts >> > @@ -39,7 +39,7 @@ >> > >> > pin_usb_host_en1 at 0 { >> > gpio-offset = <0x80 9>; >> > - pad-offset = <0x258>; >> > + pad-offset = <0x250>; >> > mode-gpio; >> > output-value = <1>; >> > direction = ; >> > >> > Does that fix it? >> >> I dug into this a bit and it all seems quite broken: >> >> - PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I >> will send a patch for this >> - gpio_ich6_get_base() returns a 16-bit word but function is also used >> to read the memory address which holds a 32-bit word >> - Intel's hardware won't let you read the status of an output! > > I thought that if you cleared bit 2 in the "pad value" register (iinenb) > for a GPIO that you could read back outputs. Or am I misunderstanding? That looks right. So Intel's hardware is fine, it just requires additional configuration. I wonder why we are not setting this? > >> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We >> need to mirror the lvl register in order to be able to read it. >> >> I confirmed that with the 'correct' value in the lvl registers both >> USB ports work. > > OK, well that's good at least. > > Thanks, > Andrew Regards, Simon