From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 7 Dec 2011 19:36:24 +0100 Subject: [U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport In-Reply-To: <4EDFAD9A.3050304@compulab.co.il> References: <1323076020-19573-1-git-send-email-grinberg@compulab.co.il> <201112071827.48767.marek.vasut@gmail.com> <4EDFAD9A.3050304@compulab.co.il> Message-ID: <201112071936.24494.marek.vasut@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 > Hi Marek, > > On 12/07/11 19:27, Marek Vasut wrote: > >> On 12/07/11 03:42, Simon Glass wrote: > >>> Hi Igor, > >>> > >>> Looks good - a few comments from me. > >>> > >>> On Mon, Dec 5, 2011 at 1:07 AM, Igor Grinberg > > > > wrote: > >>>> From: Jana Rapava > >>>> > >>>> Add partial ULPI specification implementation that should be enough to > >>>> interface the ULPI PHYs in the boot loader context. > >>>> Add a viewport implementation for Chipidea/ARC based controllers. > >>>> > >>>> Signed-off-by: Jana Rapava > >>>> Signed-off-by: Igor Grinberg > >>>> Cc: Remy Bohmer > >>>> Cc: Stefano Babic > >>>> Cc: Wolfgang Grandegger > >>>> Cc: Simon Glass > >>>> --- > > [...] > > >>> Just out of interest, is it possible to test this? How would I plumb it > >>> in? > >> > >> Well, from my experience with ULPI hardware, > >> I think the controller specific glue looks like the right place > >> for putting the ULPI layer calls in. > >> > >> In general, the controller code knows which PHYs it supports > >> and board code knows which PHY is assembled on the board, > >> so it is not that straight simple to find the right place. > >> > >> I think, Marek has patches that supposed to use this framework on > >> efikamx board. > > > > I tried using the interface, but the design seems completely wrong :-( > > Jana was supposed to design it mainly for the efikamx board, but this > > interface is unusable there. > > May I ask you why? > Isn't it because of that nasty VBUS bug efikamx has? > You can't say the design is wrong if it is more generic then you want... I think it's overengineered. Basically, to achieve what I needed, I either didn't find the right function or I had to use multiple functions. Therefore I had to fall back to plain simple ulpi_read/write(). > > > I had to fall back to basic ulpi_read()/ulpi_write() calls :-( > > That's too bad. > Because ulpi_{read|write}() is only a viewport implementation and > it is not following the ULPI spec. Well ... we'll need to rethink this. > > > I'm afraid we won't make it for .12 release window with this patches ... > > very bad :-( I'll try talking to WD if he can push the release window to > > allow this > > Good. > > > (or redesigned version) in, but I don't know if that's a good idea. > > I don't think it should be redesigned. > Currently, it is generic and abstracts the ULPI specification nicely. Nicely maybe, but try using it on top of some hardware that has ULPI chip. > It can be used on any architecture. > I have already stated in the cover letter, > what IMO is missing to improve usability, but that will not be a problem. > > Do you have the efikamx patches somewhere I can look at? Submitted to ML just a while ago. M