[U-Boot-Users] PXA27x USB device

[U-Boot-Users] PXA27x USB device

[Rodolfo Giometti]

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

-- 

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

[U-Boot-Users] PXA27x USB device

[Bryan O'Donoghue]

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

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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

[U-Boot-Users] PXA27x USB device

[Stefan Roese]

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
=====================================================================

[U-Boot-Users] PXA27x USB device

[Rodolfo Giometti]

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

-- 

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

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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

[U-Boot-Users] PXA27x USB device

[Stefan Roese]

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
=====================================================================

[U-Boot-Users] PXA27x USB device

[Wolfgang Denk]

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

-- 
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.

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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

[U-Boot-Users] PXA27x USB device

[Stefan Roese]

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
=====================================================================

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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

[U-Boot-Users] PXA27x USB device

[Robert Schwebel]

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
-- 
 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-9

[U-Boot-Users] PXA27x USB device

[Wolfgang Denk]

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

-- 
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

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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

[U-Boot-Users] PXA27x USB device

[Rodolfo Giometti]

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 logic
> 
> 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...

> 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

-- 

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

[U-Boot-Users] PXA27x USB device

[Markus Klotzbücher]

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 logic
>> 
>> 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...

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

[U-Boot-Users] PXA27x USB device

[Rodolfo Giometti]

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

-- 

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

[U-Boot-Users] PXA27x USB device

[Loeliger Jon-LOELIGER]

 
> 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