[U-Boot-Users] PXA27x USB device
Hello,
I'm just studing the possibility of implementing the USB device support for my custom PXA270 based board in order to get a serial console through the USB port.
I'm looking at drivers/usbdcore_mpc8xx.c for an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Can someone explain to me why? Should I put my PXA27x support also there?
Thanks,
Rodolfo
On Wed, 2 May 2007 16:05:02 +0200 Rodolfo Giometti giometti@enneenne.com wrote:
Hello,
Greetings.
I'm just studing the possibility of implementing the USB device support for my custom PXA270 based board in order to get a serial console through the USB port.
I'm looking at drivers/usbdcore_mpc8xx.c for an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Can someone explain to me why? Should I put my PXA27x support also there?
Don't ask me.
usbdcore_omap1510.c was in that directory *already* so it seemed ... consistent to put the usbdcore_mpc8xx in the same place.
Good luck with the pxa !
Bryan
Hi Rodolfo,
Rodolfo Giometti giometti@enneenne.com writes:
I'm looking at drivers/usbdcore_mpc8xx.c for an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Can someone explain to me why? Should I put my PXA27x support also there?
I have no idea why this is so, but it does seem wrong to me. Platform specific code should go into the corresponding cpu/ directory, and so should your pxa support.
Any objections?
Regards
Markus
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On Thursday 03 May 2007 09:49, Markus Klotzbücher wrote:
Rodolfo Giometti giometti@enneenne.com writes:
I'm looking at drivers/usbdcore_mpc8xx.c for an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Can someone explain to me why? Should I put my PXA27x support also there?
I have no idea why this is so, but it does seem wrong to me. Platform specific code should go into the corresponding cpu/ directory, and so should your pxa support.
Any objections?
We had a lengthy discussion about the right places for such drivers a few months ago. IIRC the consent was to put them into the drivers directory (please correct me, if my memory fails me here). But we wanted to structure this directly better. So I would suggest something like:
drivers/usb/device/mpc8xx.c drivers/usb/device/pxa27x.c
or even
drivers/usb/gadget/mpc8xx.c drivers/usb/gadget/pxa27x.c
to follow the Linux example a little more.
Any comments?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
On Thu, May 03, 2007 at 10:29:38AM +0200, Stefan Roese wrote:
drivers/usb/device/mpc8xx.c drivers/usb/device/pxa27x.c
or even
drivers/usb/gadget/mpc8xx.c drivers/usb/gadget/pxa27x.c
to follow the Linux example a little more.
Any comments?
Mmm.. I agree with Markus. U-boot has itsown method regarding CPU specific code. If it was as you suggest several drivers are now placed in the wrong place.
Ciao,
Rodolfo
Hi Stefan,
Stefan Roese sr@denx.de writes:
On Thursday 03 May 2007 09:49, Markus Klotzbücher wrote:
Rodolfo Giometti giometti@enneenne.com writes:
I'm looking at drivers/usbdcore_mpc8xx.c for an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Can someone explain to me why? Should I put my PXA27x support also there?
I have no idea why this is so, but it does seem wrong to me. Platform specific code should go into the corresponding cpu/ directory, and so should your pxa support.
Any objections?
We had a lengthy discussion about the right places for such drivers a few months ago. IIRC the consent was to put them into the drivers directory (please correct me, if my memory fails me here). But we wanted to structure this directly better. So I would suggest something like:
drivers/usb/device/mpc8xx.c drivers/usb/device/pxa27x.c
or even
drivers/usb/gadget/mpc8xx.c drivers/usb/gadget/pxa27x.c
to follow the Linux example a little more.
Any comments?
Hmm. Seems reasonable, especially if this structure will be used for all drivers. But is this the case? I still feel uncomfortable about placing a cpu dependant host controller driver in a generic driver directory. Will such a driver be maintained mainly by the USB Custodian or the respective Architecture Custodian? I would assume the latter.
Best regards
Markus
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On Friday 04 May 2007 12:20, Markus Klotzbücher wrote:
We had a lengthy discussion about the right places for such drivers a few months ago. IIRC the consent was to put them into the drivers directory (please correct me, if my memory fails me here). But we wanted to structure this directly better. So I would suggest something like:
drivers/usb/device/mpc8xx.c drivers/usb/device/pxa27x.c
or even
drivers/usb/gadget/mpc8xx.c drivers/usb/gadget/pxa27x.c
to follow the Linux example a little more.
Any comments?
Hmm. Seems reasonable, especially if this structure will be used for all drivers. But is this the case?
It's a mess right now. Some cpu-specific drivers are under the drivers directory (like the fsl drivers/qe/* for example) and some in the cpu directories. We should move those drivers from time to time to the drivers directory. But this will take quite a while.
If we have a consense with this location for the drivers, then at least we should start with moving *new* drivers directly into the "correct" place.
I still feel uncomfortable about placing a cpu dependant host controller driver in a generic driver directory. Will such a driver be maintained mainly by the USB Custodian or the respective Architecture Custodian? I would assume the latter.
This depends on the driver. If it's for example the ppc4xx ethernet driver it should be handled by the architecture custodian, but if it's the usb-ohci driver then it should be handled by the usb custodian. Most drivers will be handled (as they are right now) by the architecture custodian.
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
Viele Grüße, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
In message 200705041347.13816.sr@denx.de you wrote:
This depends on the driver. If it's for example the ppc4xx ethernet driver it should be handled by the architecture custodian, but if it's the usb-ohci driver then it should be handled by the usb custodian. Most drivers will be handled (as they are right now) by the architecture custodian.
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
We have this situation in other places as well - for example, we mirror the whole directory structure in post/:
post/ post/cpu/ post/cpu/mpc8xx/ ... post/board/ post/board/lwmon/ ... post/drivers/ ... post/lib_ppc/ ...
I don't see how this could be avoided; the other optiuon would be to mirror .../devices/, .../post/ etc in the CPU and board and ... directories which would be worse.
Best regards,
Wolfgang Denk
Hi Stefan,
Stefan Roese sr@denx.de writes:
Hmm. Seems reasonable, especially if this structure will be used for all drivers. But is this the case?
It's a mess right now. Some cpu-specific drivers are under the drivers directory (like the fsl drivers/qe/* for example) and some in the cpu directories. We should move those drivers from time to time to the drivers directory. But this will take quite a while.
If we have a consense with this location for the drivers, then at least we should start with moving *new* drivers directly into the "correct" place.
Yes, definitely. Now we only need to agree on where this is :-)
I still feel uncomfortable about placing a cpu dependant host controller driver in a generic driver directory. Will such a driver be maintained mainly by the USB Custodian or the respective Architecture Custodian? I would assume the latter.
This depends on the driver. If it's for example the ppc4xx ethernet driver it should be handled by the architecture custodian, but if it's the usb-ohci driver then it should be handled by the usb custodian. Most drivers will be handled (as they are right now) by the architecture custodian.
Yes, agreed.
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
This is why I favor the old way of storing cpu dependant drivers in the appropriate cpu directory. This makes the responsibility clear and allows to cleanly seperate arch and generic code. Isn't this similar to linux where cpu dependant drivers are found in "arch/cpu/"?
Also, this is doesn't prohibit the cleaning up of "drivers" by adding subsystem subdirectories for net, usb etc.
What do you think?
Best Regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Hi Markus,
On Monday 07 May 2007, Markus Klotzbücher wrote:
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
This is why I favor the old way of storing cpu dependant drivers in the appropriate cpu directory. This makes the responsibility clear and allows to cleanly seperate arch and generic code. Isn't this similar to linux where cpu dependant drivers are found in "arch/cpu/"?
No, quite the contrary. In Linux you will find even the cpu-specific drivers (like ethernet, uart, i2c driver etc) in the "drivers" directory. Only the board- and cpu-specific setup code and some additional code like interrupt controller implementation etc is normally found in the Linux "arch" directories.
This is one of the reason for me to suggest this.
Also, this is doesn't prohibit the cleaning up of "drivers" by adding subsystem subdirectories for net, usb etc.
No it doesn't.
What do you think?
I still think we should move to implementing drivers in the drivers directory, even if the responsibility for the files is not so easily visible anymore.
Viele Grüße, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
Hi Stefan,
Stefan Roese sr@denx.de writes:
On Monday 07 May 2007, Markus Klotzbücher wrote:
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
This is why I favor the old way of storing cpu dependant drivers in the appropriate cpu directory. This makes the responsibility clear and allows to cleanly seperate arch and generic code. Isn't this similar to linux where cpu dependant drivers are found in "arch/cpu/"?
No, quite the contrary. In Linux you will find even the cpu-specific drivers (like ethernet, uart, i2c driver etc) in the "drivers" directory. Only the board- and cpu-specific setup code and some additional code like interrupt controller implementation etc is normally found in the Linux "arch" directories.
There are complete drivers in arch/ppc/8260_io or arch/ppc/8xx_io for example, but I agree you're right in general.
What do you think?
I still think we should move to implementing drivers in the drivers directory, even if the responsibility for the files is not so easily visible anymore.
Ok, if this is what was agreed upon I can live with it. (Don't get me wrong, I don't think this is a big mistake or so, I just fail to see any real benefit beside of beeing more Linux-like)
Best regards
Markus
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On Mon, May 07, 2007 at 03:23:21PM +0200, Markus Klotzbücher wrote:
This is why I favor the old way of storing cpu dependant drivers in the appropriate cpu directory. This makes the responsibility clear and allows to cleanly seperate arch and generic code. Isn't this similar to linux where cpu dependant drivers are found in "arch/cpu/"?
No, quite the contrary. In Linux you will find even the cpu-specific drivers (like ethernet, uart, i2c driver etc) in the "drivers" directory. Only the board- and cpu-specific setup code and some additional code like interrupt controller implementation etc is normally found in the Linux "arch" directories.
There are complete drivers in arch/ppc/8260_io or arch/ppc/8xx_io for example, but I agree you're right in general.
Putting drivers into arch/cpu/* is evil, because manufacturers tend to reusing IP cores in other CPUs. So IMHO putting them into drivers/ is the right way to do it.
Robert
Dear Markus,
in message 87ejlssr7a.fsf@denx.de you wrote:
There are complete drivers in arch/ppc/8260_io or arch/ppc/8xx_io for example, but I agree you're right in general.
Historical reasons. Remember that we oncve stared with 8xx, and at that time even Linux had the drivers in arch/ppc/8xx_io/
I still think we should move to implementing drivers in the drivers directory, even if the responsibility for the files is not so easily visible anymore.
Ok, if this is what was agreed upon I can live with it. (Don't get me wrong, I don't think this is a big mistake or so, I just fail to see any real benefit beside of beeing more Linux-like)
Both versionshave their pros and cons, so doing it like Linux is probably a reasonable thing.
Best regards,
Wolfgang Denk
Hi,
Wolfgang Denk wd@denx.de writes:
in message 87ejlssr7a.fsf@denx.de you wrote:
Ok, if this is what was agreed upon I can live with it. (Don't get me wrong, I don't think this is a big mistake or so, I just fail to see any real benefit beside of beeing more Linux-like)
Both versionshave their pros and cons, so doing it like Linux is probably a reasonable thing.
Ok, then so it be.
How shall we structure the drivers/usb/ directory? How about something like this:
drivers/usb/host/
- generic and specific host controller drivers (ohci, uhci)
drivers/usb/core/
- usb core logic
drivers/usb/storage/
- storage class related code
drivers/usb/input/
- e.g. keyboard support etc.
As said before it needn't be done in one go, but just to make clear where usb stuff shall be placed from now on.
Comments?
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On Tue, May 08, 2007 at 08:39:23AM +0200, Markus Klotzbücher wrote:
Hi,
Wolfgang Denk wd@denx.de writes:
in message 87ejlssr7a.fsf@denx.de you wrote:
Ok, if this is what was agreed upon I can live with it. (Don't get me wrong, I don't think this is a big mistake or so, I just fail to see any real benefit beside of beeing more Linux-like)
Both versionshave their pros and cons, so doing it like Linux is probably a reasonable thing.
Ok, then so it be.
So we should put there even on-chip devices supports? Like on-chip USB OHCI controllers and USB devices?
How shall we structure the drivers/usb/ directory? How about something like this:
drivers/usb/host/
- generic and specific host controller drivers (ohci, uhci)drivers/usb/core/
- usb core logicdrivers/usb/storage/
- storage class related codedrivers/usb/input/
- e.g. keyboard support etc.
Since I'm working on USB device I think we need also:
drivers/usb/gadget/
- usb gadget drivers
Also I think we should also move usbtty support there...
As said before it needn't be done in one go, but just to make clear where usb stuff shall be placed from now on.
Currently I'm developing my PXA27x USB device support in cpu/pxa/usbd.c file but as soon as the new tree structure is available I can move it accordingly.
Ciao,
Rodolfo
Hi Rodolfo,
Rodolfo Giometti giometti@enneenne.com writes:
On Tue, May 08, 2007 at 08:39:23AM +0200, Markus Klotzbücher wrote:
Hi,
Wolfgang Denk wd@denx.de writes:
in message 87ejlssr7a.fsf@denx.de you wrote:
Ok, if this is what was agreed upon I can live with it. (Don't get me wrong, I don't think this is a big mistake or so, I just fail to see any real benefit beside of beeing more Linux-like)
Both versionshave their pros and cons, so doing it like Linux is probably a reasonable thing.
Ok, then so it be.
So we should put there even on-chip devices supports? Like on-chip USB OHCI controllers and USB devices?
Yes. If it's a driver, it should go into drivers/
How shall we structure the drivers/usb/ directory? How about something like this:
drivers/usb/host/
- generic and specific host controller drivers (ohci, uhci)drivers/usb/core/
- usb core logicdrivers/usb/storage/
- storage class related codedrivers/usb/input/
- e.g. keyboard support etc.Since I'm working on USB device I think we need also:
drivers/usb/gadget/
- usb gadget drivers
Also I think we should also move usbtty support there...
Ok, fine!
As said before it needn't be done in one go, but just to make clear where usb stuff shall be placed from now on.
Currently I'm developing my PXA27x USB device support in cpu/pxa/usbd.c file but as soon as the new tree structure is available I can move it accordingly.
Just create the directories you need while your working on your driver. AFAIK you can't add empty directories with git.
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On Tue, May 08, 2007 at 12:04:59PM +0200, Markus Klotzbücher wrote:
Just create the directories you need while your working on your driver. AFAIK you can't add empty directories with git.
I think is better I wait for your modifications, directories add, etc... meanwhile I continue to work in the old way.
Ciao,
Rodolfo
On Tue, May 08, 2007 at 12:04:59PM +0200, Markus Klotzbücher wrote:
Just create the directories you need while your working on your driver. AFAIK you can't add empty directories with git.
I think is better I wait for your modifications, directories add, etc... meanwhile I continue to work in the old way.
So, MK is right -- Git will not just add an Empty directory to a repository. If you need A new directory, you have to have at least one File within it. Remember, git manages _content_; You have to have some actual stuff there!
jdl
participants (7)
-
Bryan O'Donoghue -
Loeliger Jon-LOELIGER -
Markus Klotzbücher -
Robert Schwebel -
Rodolfo Giometti -
Stefan Roese -
Wolfgang Denk