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
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at gnudd.com Embedded Systems giometti at linux.it UNIX programming phone: +39 349 2432127
Quoted 1 line · On Wed, 2 May 2007 16:05:02 +0200 Rodolfo Giometti <[email protected]>…
Hello,
Greetings.
Quoted 10 lines
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.cfor 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,
Quoted 6 lines · Rodolfo Giometti
I'm looking at
drivers/usbdcore_mpc8xx.cfor 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
Quoted 5 lines · Markus Klotzb?cher
Quoted 4 lines · Rodolfo Giometti
I'm looking at
drivers/usbdcore_mpc8xx.cfor an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.
Quoted 8 lines
Quoted 2 lines
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.cdrivers/usb/device/pxa27x.c
or even
drivers/usb/gadget/mpc8xx.cdrivers/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
=====================================================================
Quoted 4 lines · Stefan Roese
drivers/usb/device/mpc8xx.cdrivers/usb/device/pxa27x.c
Quoted 8 lines
or even
drivers/usb/gadget/mpc8xx.cdrivers/usb/gadget/pxa27x.cto 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
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at gnudd.com Embedded Systems giometti at linux.it UNIX programming phone: +39 349 2432127
Hi Stefan,
Quoted 23 lines · Stefan Roese
Quoted 5 lines · Markus Klotzb?cher
Quoted 4 lines · Rodolfo Giometti
I'm looking at
drivers/usbdcore_mpc8xx.cfor an implementation example but I don't understand why such support has been put there instead of cpu/mpc8xx directory.Quoted 8 lines
Quoted 2 lines
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.cdrivers/usb/device/pxa27x.c
Quoted 8 lines
or even
drivers/usb/gadget/mpc8xx.cdrivers/usb/gadget/pxa27x.cto 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
Quoted 13 lines · Markus Klotzb?cher
Quoted 13 lines
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.cdrivers/usb/device/pxa27x.cor even
drivers/usb/gadget/mpc8xx.cdrivers/usb/gadget/pxa27x.c
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
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
=====================================================================
Quoted 10 lines · In message <[email protected]> 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
Signature · 4 lines
DENX Software Engineering GmbH, CEO: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Don't have a battle of wits with an unarmed opponent.
Hi Stefan,
Quoted 10 lines · Stefan Roese
Quoted 2 lines
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 :-)
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
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,
Quoted 9 lines · Markus Klotzb?cher
Quoted 4 lines
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.
Quoted 2 lines
Also, this is doesn't prohibit the cleaning up of "drivers" by adding subsystem subdirectories for net, usb etc.
No it doesn't.
Quoted 1 line
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,
Quoted 11 lines · Stefan Roese
Quoted 9 lines · Markus Klotzb?cher
Quoted 4 lines
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/"?
Quoted 5 lines
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.
Quoted 4 lines
Quoted 1 line
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
Quoted 6 lines · Markus Klotzb?cher
Quoted 6 lines
Quoted 5 lines
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/"?
Quoted 8 lines
Quoted 5 lines
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_ioorarch/ppc/8xx_iofor 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
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9Dear Markus,
Quoted 3 lines · in message <[email protected]> you wrote:
There are complete drivers in
arch/ppc/8260_ioorarch/ppc/8xx_iofor 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/
Quoted 6 lines
Quoted 2 lines
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
Signature · 6 lines
DENX Software Engineering GmbH, CEO: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Here is an Appalachian version of management's answer to those who are concerned with the fate of the project: "Don't worry about the mule. Just load the wagon." - Mike Dennison's hillbilly uncle
Hi,
Quoted 8 lines · Wolfgang Denk
Quoted 3 lines · in message <[email protected]> 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
Quoted 5 lines · Markus Klotzb?cher
Hi,
Quoted 1 line · Wolfgang Denk
in message <[email protected]> you wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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?
Quoted 11 lines
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
Quoted 7 lines
drivers/usb/storage/- storage class related code
drivers/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...
Quoted 2 lines
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
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at gnudd.com Embedded Systems giometti at linux.it UNIX programming phone: +39 349 2432127
Hi Rodolfo,
Quoted 10 lines · Rodolfo Giometti
Quoted 9 lines · Markus Klotzb?cher
Hi,
Quoted 6 lines · Wolfgang Denk
Quoted 3 lines · in message <[email protected]> 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)
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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/
Quoted 19 lines
Quoted 11 lines
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
Quoted 7 lines
drivers/usb/storage/- storage class related code
drivers/usb/input/- e.g. keyboard support etc.
Quoted 7 lines
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!
Quoted 6 lines
Quoted 2 lines
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.cfile 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
Quoted 2 lines · Markus Klotzb?cher
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
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at gnudd.com Embedded Systems giometti at linux.it UNIX programming phone: +39 349 2432127
Quoted 8 lines · Markus Klotzb?cher
Quoted 3 lines
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