[U-Boot] [RFC] general ULPI support

Hi all, my patch, which added USB support for Efika, needed som ULPI functions. I was suggested to write general ULPI support code rather than implenent demanded functionality in the driver. However, I've encountered following problems: 1. Where should I put this code? Linux kernel has it in ./drivers/usb/otg/ together with OTG utility code. Use this name looks a bit deceiving for me. Should I create some directory named like ./drivers/usb/ulpi/, or is there better place? 2. I don't know what to add to the Makefile. Should I create a new config option (named CONFIG_ULPI I suppose) or simply add rule for new files?
Regards, Jana Rapava

On Saturday, October 15, 2011 03:19:45 PM Jana Rapava wrote:
Hi all,
Dear Jana Rapava,
please Cc respective custodians if you want to get _ANY_ feedback at all.
my patch, which added USB support for Efika, needed som ULPI functions. I was suggested to write general ULPI support code rather than implenent demanded functionality in the driver. However, I've encountered following problems:
- Where should I put this code? Linux kernel has it in ./drivers/usb/otg/
together with OTG utility code. Use this name looks a bit deceiving for me. Should I create some directory named like ./drivers/usb/ulpi/, or is there better place?
drivers/usb/ulpi looks ok
- I don't know what to add to the Makefile. Should I create a new config
option (named CONFIG_ULPI I suppose) or simply add rule for new files?
You definitelly don't want to compile the code in unconditionally.
Anyway, do you really need the linux ulpi code as is or can you implement more lightweight thing?
Cheers

Hi Marek,
[...]
Anyway, do you really need the linux ulpi code as is or can you implement more lightweight thing?
Especially with respect to usb I'd like to encourage code sharing. The first USB implementation in U-Boot was such a "we do it ourself" thing and effectively cut us off from the hepful of bugfixes/new features that Linux saw in the meantime. Let's try to share as much as possible in such areas of complex code (with that I mean not algorithmic complexity but work-arounds and special cases).
Cheers Detlev
participants (3)
-
Detlev Zundel
-
Jana Rapava
-
Marek Vasut