From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mateusz Kulikowski Date: Wed, 16 Dec 2015 23:51:16 +0100 Subject: [U-Boot] [RFC PATCH 05/11] ehci: Add support for Qualcomm EHCI In-Reply-To: <201512131648.01919.marex@denx.de> References: <1449783707-23594-1-git-send-email-mateusz.kulikowski@gmail.com> <201512110022.20112.marex@denx.de> <566D66D1.4090709@gmail.com> <201512131648.01919.marex@denx.de> Message-ID: <5671EAE4.3020402@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Marek, On 13.12.2015 16:48, Marek Vasut wrote: > On Sunday, December 13, 2015 at 01:38:41 PM, Mateusz Kulikowski wrote: [...] >> It doesn't matter if I add it as >> select USB_ULPI_VIEWPORT >> in usb KConfig, or forcibly add CONFIG_USB_ULPI_VIEWPORT to .config > > I think it should be quite easily possible to add this to USB Kconfig. Will do. >> I can use fsl headers with little exception that two registers are >> marked as reserved: USB_AHB_MODE (0x98) and USB_GENCONFIG_2 (0xA0) >> >> My guess is that it's just different revision/config of IP core. >> >> Do you think it wouldn't look awkward if I use fsl headers? > > Just rename them to ehci-ci.h, that should be the quickest. Will do. [...] >>>> + struct ulpi_viewport ulpi_vp = {.port_num = priv->ulpi_port, >>>> + .viewport_addr = priv->ulpi_base}; >>>> + >>>> + /* Disable VBUS mimicing in the controller. */ >>>> + ulpi_write(&ulpi_vp, (u8 *)ULPI_MISC_A_CLEAR, >>> >>> This should be a pointer to a field in struct ulpi_regs, so the (u8 *) >>> cast does not seem right. See for example ehci-zynq.c >> >> Perhaps I misussed ulpi_viewport code in that case; >> >> The reason is I need to access MISC_A register (0x96+) that is >> not in ulpi_regs structure - afaik it's vendor-specific. >> >> Any hints how to tackle that properly? >> >> I can of course duplicate ulpi code, but it probably doesn't make much >> sense. > > I don't have a better suggestion, sorry. Let's keep this as-is unless > someone can come up with something better. Code duplication is not a > good idea, so we won't do that. OK Thanks, Mateusz -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWcerfAAoJELvtohmVtQzB1AMH/260Ioo6W6+skWJJhmm+g3yD B3kWhJWWyGPSkY4QcA7O/dgzU9i/n9a6gwlqcwYLhYlzyKG/p0aRBim0RWEFWK+S V1SMYA3iQhYLkjMdOfqNXdQ5NrG2osll1Nk2GK9wBthVtPkjqfQkOupw7oZq3kd5 3pNpbsREIuxfct26C7kaTJccRf7MIYdlslYu53h4T/t03oO8xBIrSDGAR+9UD841 yCWuATbg461uhPrD1/WBG/wiIzMaOsITyiXIkxr7Z0GNrOeaZ38YqSwASwLTUmxO NB+UkOvA9eM1oz79Qaoxyrfm/rDtds+CHXuFco2LY2gOl1280ffwKG1UQWCWDsk= =XMV7 -----END PGP SIGNATURE-----