linux-mips-kernel — Developers list to discuss MIPS issues

Re: [Linux-mips-kernel] helper script

[Pete P. <pp...@mv...>]

Paul Mundt wrote:

>Hi Pete,
>
>Nice work on the script. One thing though, I ran into a few issues while I
>was testing it.. namely, it had some problems forcibly overwriting existing
>files with the symlink (ie, ln -sf behavior).
>
I'm not sure I understand what happens here. I wanted to rename the 
original file and then create a link to the linux-mips file.   
Apparently something else is the result?

>I talked to Charles Duffy about it, and he suggested something like the
>attached patch. After applying the patch, everything worked properly for me.
>
>Anyways, unless anyone has any issues with the patch, I'll shove it into
>CVS.
>
Cool. First python script :-)

Pete

>
>
>On Sun, Jul 01, 2001 at 07:32:44PM -0700, Pete Popov wrote:
>
>>Don't know if this would be useful to anyone else but Paul mentioned a 
>>similar script that he uses for another drop in tree. This one works for 
>>me and helps keep the linux-mips tree in a separate directory so I don't 
>>have cvs problems when updating, committing, etc.  The script takes the 
>>linux-mips tree, the stock kernel tree, and a new development directory 
>>as inputs. It copies the stock tree to the new dev directory; then it 
>>recurses through the new dev directory and:
>>* renames all files that are in common between the linux-mips and new 
>>dev tree directories to *.stock
>>* creates a link in the new dev directory that points to the file in the 
>>linux-mips directory.
>>
>>That way you can develop in the new directory, but you can still easily 
>>update and commit from within the linux-mips directory.
>>
>
>Regards,
>
>
>------------------------------------------------------------------------
>
>--- treelink.orig	Mon Jul  2 22:54:11 2001
>+++ treelink	Mon Jul  2 20:48:25 2001
>@@ -76,6 +76,7 @@
> 		line = f.readline()
> 		continue
> 
>+	file = re.match('^/*(.*)?$', file).group(1)
> 	orig_stock_file = os.path.normpath(os.path.join(abs_dev_dir,file)) # orig file in stock kernel
> 	link_file = os.path.normpath(os.path.join(abs_drop_in_dir,file))   # what we'll link it to
> 
>@@ -86,7 +87,11 @@
> 	elif (os.path.isfile(orig_stock_file) == 1):
> 		os.rename(orig_stock_file, orig_stock_file + ".stock")
> 
>-	os.symlink(link_file, orig_stock_file)
>+	try: os.remove(orig_stock_file)
>+	except OSError: pass
>+
>+	try: os.symlink(link_file, orig_stock_file)
>+	except: pass
> 	line = f.readline()
> 
> f.close()
>
> Part 1.1.1
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> treelink.diff
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> quoted-printable
>
>

Re: [Linux-mips-kernel] helper script

[Paul M. <pm...@mv...>]

Hi Pete,

Nice work on the script. One thing though, I ran into a few issues while I
was testing it.. namely, it had some problems forcibly overwriting existing
files with the symlink (ie, ln -sf behavior).

I talked to Charles Duffy about it, and he suggested something like the
attached patch. After applying the patch, everything worked properly for me.

Anyways, unless anyone has any issues with the patch, I'll shove it into
CVS.

On Sun, Jul 01, 2001 at 07:32:44PM -0700, Pete Popov wrote:
> Don't know if this would be useful to anyone else but Paul mentioned a 
> similar script that he uses for another drop in tree. This one works for 
> me and helps keep the linux-mips tree in a separate directory so I don't 
> have cvs problems when updating, committing, etc.  The script takes the 
> linux-mips tree, the stock kernel tree, and a new development directory 
> as inputs. It copies the stock tree to the new dev directory; then it 
> recurses through the new dev directory and:
> * renames all files that are in common between the linux-mips and new 
> dev tree directories to *.stock
> * creates a link in the new dev directory that points to the file in the 
> linux-mips directory.
> 
> That way you can develop in the new directory, but you can still easily 
> update and commit from within the linux-mips directory.
> 

Regards,

-- 
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] Ug!!! VR code

[Paul M. <pm...@mv...>]

On Mon, Jul 02, 2001 at 01:29:02PM -0700, James Simmons wrote:
> Anyone can make heaads or tails of it?=20
>=20
I'm currently working on slowly getting things worth salvaging from Brad's
tree (not much) and getting them working with Jun's VR patch that I applied
a little while ago.

There's still quite a bit to be done, but hopefully the tree will be in a
testable state for VR in short order.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

[Linux-mips-kernel] Ug!!! VR code

[James S. <jsi...@tr...>]

Anyone can make heaads or tails of it? 

[Linux-mips-kernel] Parital Cobalt support.

[James S. <jsi...@tr...>]

Yes. I incorporated early cobalt support. It needs some really cleanup. 

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[James S. <jsi...@tr...>]

> >Do you have the codes tha hardware produces for each key? I will need the
> >to create the keycode map to event values. With the input api their is
> >only ONE keymap needed :-)
> >
> I don't have them, but I get hook up the keyboard and get them.

Thanks :-)

> BTW, do you realize that this keyboard driver is of limited value?  

Yes. It is more of a demo for people to use.

Re: [Linux-mips-kernel] helper script

[Pete P. <pp...@pa...>]

James Simmons wrote:

>>Don't know if this would be useful to anyone else but Paul mentioned a 
>>similar script that he uses for another drop in tree. This one works for 
>>me and helps keep the linux-mips tree in a separate directory so I don't 
>>have cvs problems when updating, committing, etc.  The script takes the 
>>linux-mips tree, the stock kernel tree, and a new development directory 
>>as inputs. It copies the stock tree to the new dev directory; then it 
>>recurses through the new dev directory and:
>>* renames all files that are in common between the linux-mips and new 
>>dev tree directories to *.stock
>>* creates a link in the new dev directory that points to the file in the 
>>linux-mips directory.
>>
>>That way you can develop in the new directory, but you can still easily 
>>update and commit from within the linux-mips directory.
>>
> 
> Could you place that into the top level of CVS. 


Yes, but it hasn't been tested all that much.

> We should have a INSTALL  file as well with instructions.


I'll try to do a first pass at a short INSTALL file sometime tonight.

Pete

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[Pete P. <pp...@mv...>]

James Simmons wrote:

>>>Qtronix 990P infrared keyboard driver.
>>>
>>That would be great -- if you convert it to the input api.
>>
>>I wrote that driver, not knowing anything about keyboards, and I picked 
>>the wrong way to do it.  After the scancode is decoded from the raw 
>>serial data, I should have at that point translated the Qtronix scancode 
>>to a PS2 scancode. That way you don't need to worry about the scancode 
>>to keycode translation and you don't need a new keymap file.
>>
>
>Do you have the codes tha hardware produces for each key? I will need the
>to create the keycode map to event values. With the input api their is
>only ONE keymap needed :-)
>
I don't have them, but I get hook up the keyboard and get them.

>
>You probably won't be able to test the new keyboard driver.  I can test 
>it when you're ready.
>
>
>Okay. Cool. Just give me some time. I'm working on serial stuff right now.
>I hope to port over my code to CVS soon.
>

BTW, do you realize that this keyboard driver is of limited value?  The 
keyboard ships with a ps2/usb adapter that you connect to your PS2 or 
USB port on your PC or embedded board.  The adapter has the infrared 
receiver. If you use this adapter, the keyboard is just a regular ps2 or 
usb keyboard.  However, one of our customers has an infrared receiver on 
the board itself, so they wanted to be able to use a wireless keyboard 
without the special adapter that the board ships with.  Bottom line is 
that not too many people will be able to use this keyboard driver.  It's 
possible though that someone else could make another embedded board with 
an infrared port that could then use this keyboard driver.  Currently 
the ITE IT8172 referrence board and the Globespan PVR (their personal 
video recorder eval board) use the keyboard driver.  Just FYI.

Pete

Re: [Linux-mips-kernel] helper script

[James S. <jsi...@tr...>]

> Don't know if this would be useful to anyone else but Paul mentioned a 
> similar script that he uses for another drop in tree. This one works for 
> me and helps keep the linux-mips tree in a separate directory so I don't 
> have cvs problems when updating, committing, etc.  The script takes the 
> linux-mips tree, the stock kernel tree, and a new development directory 
> as inputs. It copies the stock tree to the new dev directory; then it 
> recurses through the new dev directory and:
> * renames all files that are in common between the linux-mips and new 
> dev tree directories to *.stock
> * creates a link in the new dev directory that points to the file in the 
> linux-mips directory.
> 
> That way you can develop in the new directory, but you can still easily 
> update and commit from within the linux-mips directory.

Could you place that into the top level of CVS. We should have a INSTALL 
file as well with instructions.

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[James S. <jsi...@tr...>]

> >Qtronix 990P infrared keyboard driver.
> >
> That would be great -- if you convert it to the input api.
> 
> I wrote that driver, not knowing anything about keyboards, and I picked 
> the wrong way to do it.  After the scancode is decoded from the raw 
> serial data, I should have at that point translated the Qtronix scancode 
> to a PS2 scancode. That way you don't need to worry about the scancode 
> to keycode translation and you don't need a new keymap file.

Do you have the codes tha hardware produces for each key? I will need the
to create the keycode map to event values. With the input api their is
only ONE keymap needed :-)

> You probably won't be able to test the new keyboard driver.  I can test 
> it when you're ready.

Okay. Cool. Just give me some time. I'm working on serial stuff right now.
I hope to port over my code to CVS soon.

[Linux-mips-kernel] helper script

[Pete P. <pp...@pa...>]

Don't know if this would be useful to anyone else but Paul mentioned a 
similar script that he uses for another drop in tree. This one works for 
me and helps keep the linux-mips tree in a separate directory so I don't 
have cvs problems when updating, committing, etc.  The script takes the 
linux-mips tree, the stock kernel tree, and a new development directory 
as inputs. It copies the stock tree to the new dev directory; then it 
recurses through the new dev directory and:
* renames all files that are in common between the linux-mips and new 
dev tree directories to *.stock
* creates a link in the new dev directory that points to the file in the 
linux-mips directory.

That way you can develop in the new directory, but you can still easily 
update and commit from within the linux-mips directory.

Pete

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[Pete P. <pp...@mv...>]

James Simmons wrote:

>>>P.S
>>> I noticed a keyboard driver in CVS. I like to help convert that to the
>>>input api.
>>>
>>Which keyboard driver are you referring to?
>>
>
>Qtronix 990P infrared keyboard driver.
>
That would be great -- if you convert it to the input api.

I wrote that driver, not knowing anything about keyboards, and I picked 
the wrong way to do it.  After the scancode is decoded from the raw 
serial data, I should have at that point translated the Qtronix scancode 
to a PS2 scancode. That way you don't need to worry about the scancode 
to keycode translation and you don't need a new keymap file.

You probably won't be able to test the new keyboard driver.  I can test 
it when you're ready.

Pete

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[James S. <jsi...@tr...>]

> >P.S
> >  I noticed a keyboard driver in CVS. I like to help convert that to the
> >input api.
> >
> Which keyboard driver are you referring to?

Qtronix 990P infrared keyboard driver.

Re: [Linux-mips-kernel] Cleaner fbdev driver writing

[Pete P. <pp...@mv...>]

James Simmons wrote:

>I folks. I placed into CVS a new fbgen whcih will make driver writing much
>easier. I have been testing it out on the ARM but I know it will work like
>a charm on the mips.
>
>P.S
>  I noticed a keyboard driver in CVS. I like to help convert that to the
>input api.
>
Which keyboard driver are you referring to?

Pete

[Linux-mips-kernel] Cleaner fbdev driver writing

[James S. <jsi...@tr...>]

I folks. I placed into CVS a new fbgen whcih will make driver writing much
easier. I have been testing it out on the ARM but I know it will work like
a charm on the mips.

P.S
  I noticed a keyboard driver in CVS. I like to help convert that to the
input api.

Re: [Linux-mips-kernel] Alchemy Au1000 updates

[James S. <jsi...@tr...>]

> Another option is to put in a new except_vec0_xxxx 
> routine, which is the routine I've modified. There's already a few of 
> those for different cpus, so there's a precedent there.    Hmm, I think 
> that's what I should do.

That sounds like the best option to handle this. Please do it this way.

Re: [Linux-mips-kernel] Alchemy Au1000 updates

[Pete P. <pp...@mv...>]

James Simmons wrote:

>>I just updated most of the Alchemy Au1000 files.  
>>
>
>Great work.
>
>>which modifies arch/mips/kernel/head.S (inside ifdefs) to deal 
>>with 36 bit physical addresses of that cpu only.  I would like to get 
>>some comments on whether this can be accepted in an external tree like 
>>this one.
>>
>
>Hum. Shouldn't this be CPU specific? 
>
The code that's inside ifdefs is cpu specific. But right now there's 
only one head.S file so there's no other place to put it.  If I create a 
new head.S (au1000_head.S, for example), then I would have to modify 
arch/mips/Makefile.   Another option is to put in a new except_vec0_xxxx 
routine, which is the routine I've modified. There's already a few of 
those for different cpus, so there's a precedent there.    Hmm, I think 
that's what I should do.

>Regarding the pcmcia, how about if I bring in only the files I need for 
>this board (which unfortunately is most of the files under 
>drivers/pcmcia)?
>
>
>Please only the ones you modified. Just drop the tree over Linus tree and
>your set to go.
>
Right, I think I was still confused about the drop-in tree when I sent 
that email.  I'll do it next week.

Pete

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[James S. <jsi...@tr...>]

> >I doubt he would like it. Is this card used for other platforms as well? 
> >
> 
> No, it's mips only, and the pcmcia controller is part of the SOC.  I 
> don't want to modify pcmcia client drivers, because that's even worse.   
>  Keeping patches around is also a pita.

True. It is a limitation in the mips tree. I will have to see what the
proper solution is. Their are a bunch of macros in the io.h file I'm
trying to make out. 

Re: [Linux-mips-kernel] Alchemy Au1000 updates

[James S. <jsi...@tr...>]

> I just updated most of the Alchemy Au1000 files.  

Great work.

> which modifies arch/mips/kernel/head.S (inside ifdefs) to deal 
> with 36 bit physical addresses of that cpu only.  I would like to get 
> some comments on whether this can be accepted in an external tree like 
> this one.

Hum. Shouldn't this be CPU specific? 

> Regarding the pcmcia, how about if I bring in only the files I need for 
> this board (which unfortunately is most of the files under 
> drivers/pcmcia)?

Please only the ones you modified. Just drop the tree over Linus tree and
your set to go.

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[Paul M. <pm...@mv...>]

On Tue, Jun 26, 2001 at 09:43:44AM -0700, James Simmons wrote:
> > New drivers should be sent to Alan, though they should only be sent to
> > Alan after they're sitting comfortably in the linux-mips tree. If we st=
art
> > sending code directly into Alan's tree, then we get into the issue you
> > just mentioned regarding our up to date tree having to play catch up.
>=20
> Actually we will be sending them to the SGI tree. In fact once the device
> drivers are well tested and they work they will be the easiest to get into
> the main mips tree. It is any changes to the core mips code that will need
> to thought out since it can effect other devices using mips. These would
> have to be discussed.
>=20
I would say that mips-specific drivers get pushed to the SGI tree, and driv=
ers
that can be used on multiple architectures should likely be pushed both to =
the
SGI tree and to Alan.

Anything that gets new drivers into the kernel faster is a Good Thing(tm).

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[Pete P. <pp...@mv...>]

James Simmons wrote:

>>In other words, it's OK to commit new drivers to, let's say, drivers/net 
>>in the linux-mips tree?   That would be fine -- I thought that by the 
>>drop-in approach this wasn't desirable.
>>
>
>Yes. With the drop down approach we just have to keep the Config.in and
>Makefile files in sync.
>
>>The pcmcia client drivers use insl/outsl instructions, 
>>eventhough pcmcia is 16 bit.  The mips insl/outsl macros do not work on 
>>my board because it only does 16 bit pcmcia accesses. So I had to 
>>"ifdef" the io.h file to redefine the insl/outsl macros to use 16 bit 
>>accesses.  The patch is small, but ugly because it modifies a mips 
>>global file with a board-specific ifdef. I don't know if Ralf would take 
>>that patch.  What do you do in this case?  
>>
>
>I doubt he would like it. Is this card used for other platforms as well? 
>

No, it's mips only, and the pcmcia controller is part of the SOC.  I 
don't want to modify pcmcia client drivers, because that's even worse.   
 Keeping patches around is also a pita.

Pete

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[James S. <jsi...@tr...>]

> In other words, it's OK to commit new drivers to, let's say, drivers/net 
> in the linux-mips tree?   That would be fine -- I thought that by the 
> drop-in approach this wasn't desirable.

Yes. With the drop down approach we just have to keep the Config.in and
Makefile files in sync.

> The pcmcia client drivers use insl/outsl instructions, 
> eventhough pcmcia is 16 bit.  The mips insl/outsl macros do not work on 
> my board because it only does 16 bit pcmcia accesses. So I had to 
> "ifdef" the io.h file to redefine the insl/outsl macros to use 16 bit 
> accesses.  The patch is small, but ugly because it modifies a mips 
> global file with a board-specific ifdef. I don't know if Ralf would take 
> that patch.  What do you do in this case?  

I doubt he would like it. Is this card used for other platforms as well? 

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[James S. <jsi...@tr...>]

> New drivers should be sent to Alan, though they should only be sent to
> Alan after they're sitting comfortably in the linux-mips tree. If we start
> sending code directly into Alan's tree, then we get into the issue you
> just mentioned regarding our up to date tree having to play catch up.

Actually we will be sending them to the SGI tree. In fact once the device
drivers are well tested and they work they will be the easiest to get into
the main mips tree. It is any changes to the core mips code that will need
to thought out since it can effect other devices using mips. These would
have to be discussed.

I agree about the drop in tree stuff. The most important thing is we
maintain patches against the SGI and linus trees and post them. 

[Linux-mips-kernel] Alchemy Au1000 updates

[Pete P. <pp...@pa...>]

I just updated most of the Alchemy Au1000 files.  There are a couple of 
patches remaining which I'm not sure what to do it.  I've attached one 
of them, which modifies arch/mips/kernel/head.S (inside ifdefs) to deal 
with 36 bit physical addresses of that cpu only.  I would like to get 
some comments on whether this can be accepted in an external tree like 
this one.

Regarding the pcmcia, how about if I bring in only the files I need for 
this board (which unfortunately is most of the files under 
drivers/pcmcia)?

Pete

Re: [Linux-mips-kernel] Whole tree or no whole tree.

[Pete P. <pp...@mv...>]

Paul Mundt wrote:

>On Mon, Jun 25, 2001 at 03:45:32PM -0700, Pete Popov wrote:
>
>>>Putting a whole tree in CVS will make it a maintenance nightmare, and take
>>>away from real development time. If certain items (like pcmcia) need to be
>>>added into the tree, they should be added in as they're needed.
>>>
>>>Importing an entire tree so development can be done on some small part of
>>>the tree seems kind of wasteful. If patches for the small parts (outside of
>>>the MIPS portion of the kernel, such as drivers) are necessary, then it'd
>>>be more beneficial to try and get them pushed into Linus' tree then worry
>>>about dragging them around in our tree..
>>>
>>Sending new drivers, whether pcmcia or network or any other driver, to 
>>Alan Cox or Linus probably makes the most sense. However, the problem 
>>then is that the linux-mips tree will hardly ever be bleeding edge and 
>>up to date with any given board. For example, I'm doing work on a system 
>>on a chip which includes quite a few peripherals. Even though these 
>>periperals are "mips specific", since they are part of this mips soc, it 
>>still make sense to put their drivers in the appropriate directory -- 
>>like drivers/net driver/pcmcia, etc. If I only push those new drivers to 
>>Alan or Linus, then the linux-mips tree will have to wait until these 
>>drivers are a) accepted and b) we pull down the changes from the stock 
>>kernel.  Thus, at any given time the linux-mips tree will not have all 
>>the bleeding edge code that developers might/will be interested in.
>>
>Another advantage of the drop-in tree approach. If you have new drivers that
>need merging into the tree, they can be added under the appropriate location
>without us having to copy the entire subsystem over. All that's necessary
>at that point is retaining the Config.in and Makefile so it can be kept up
>to date, and so the new driver(s) can be added into them. (Maintaing a
>drop-in Configure.help would be useful too.. could just be appended to the
>current one).
>
>New drivers should be sent to Alan, though they should only be sent to
>Alan after they're sitting comfortably in the linux-mips tree. If we start
>sending code directly into Alan's tree, then we get into the issue you
>just mentioned regarding our up to date tree having to play catch up
>
In other words, it's OK to commit new drivers to, let's say, drivers/net 
in the linux-mips tree?   That would be fine -- I thought that by the 
drop-in approach this wasn't desirable.

>I was simply noting that it'd be faster for small fix-ups and such to be
>pushed into the kernel directly instead of us having to track them in our
>tree. For example.. say you have a board that requires a 3 line hack to the
>ne2k driver.. should we start carrying around the entire ne2k driver, or
>should we try to get the 3 line hack into the driver but make sure that it's
>a carefully thought through hack that doesn't come off as a cheap hack.
>If it becomes an issue where a necessary hack to a third party driver is
>crucial for operation but the change has no chance of getting into the kernel,
>then it'd be justifiable to keep an up to date copy of the driver in the
>tree with the hack applied.
>
So do we keep a patch somewhere in this case?    Let me give you an 
example.  The pcmcia client drivers use insl/outsl instructions, 
eventhough pcmcia is 16 bit.  The mips insl/outsl macros do not work on 
my board because it only does 16 bit pcmcia accesses. So I had to 
"ifdef" the io.h file to redefine the insl/outsl macros to use 16 bit 
accesses.  The patch is small, but ugly because it modifies a mips 
global file with a board-specific ifdef. I don't know if Ralf would take 
that patch.  What do you do in this case?  

>My only point is that we should be weary about what we carry around in the
>tree. Keeping unnecessary source in the tree means more maintenance.
>

I buy that argument, I'm just trying to figure out how to work in this 
environment and what's allowed and/or recommended.

Pete

>