AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070706114511.70423943@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E046A886A@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 6 Jul 2007 11:46:13 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Subject: Re: please review
Message-ID: <20070706114613.5c11f09e@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E046A886A@onstor-exch02.onstor.net>
References: <20070705175356.5ff0f5df@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E046A87CA@onstor-exch02.onstor.net>
	<20070706110435.27886d67@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E046A8834@onstor-exch02.onstor.net>
	<20070706112920.41a6d7d4@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E046A886A@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 6 Jul 2007 11:38:34 -0700 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> 
> 
> >-----Original Message-----
> >From: Andy Sharp
> >Sent: Friday, July 06, 2007 11:29 AM
> >To: Maxim Kozlovsky
> >Subject: Re: please review
> >
> >On Fri, 6 Jul 2007 11:13:48 -0700 "Maxim Kozlovsky"
> ><maxim.kozlovsky@onstor.com> wrote:
> >
> >>
> >>
> >> >-----Original Message-----
> >> >From: Andy Sharp
> >> >Sent: Friday, July 06, 2007 11:05 AM
> >> >To: Maxim Kozlovsky
> >> >Subject: Re: please review
> >> >
> >> >On Fri, 6 Jul 2007 10:20:11 -0700 "Maxim Kozlovsky"
> >> ><maxim.kozlovsky@onstor.com> wrote:
> >> >
> >> >> Irq.c:
> >> >>
> >> >> 97: Is marvell really using both interrupt lines? Can you even
> >> connect
> >> >> it like this? There must be a bmfpga interrupt on one of these
> >> >> lines.
> >> >
> >> >Dude, I have no fuggin clue what I'm doing here.  Feel free to
> >> >educate me.  It was just on irq 3 for the longest time, or was it
> >> >irq 2?  Then I was having trouble with the CF irq, so I added it
> >> >to both because some piece of documentation lists it that way.
> >> >Didn't seem to make any difference whatsoever.  If you know
> >> >anything, let me in on it.
> >> [MK] The interrupt works the way the code is currently, you don't
> need
> >> the second interrupt line. You could check if you really are
> >> getting the interrupts on the second line by storing the irq in
> >> some variable or something like that, but I very much doubt that
> >> you do. Since this does not make any difference for you, let's
> >> undo this change.
> >
> >Is it hurting something?
> [MK] 
> It does if we really start generating interrupts on that other line,
> and we will.

Whatever it is you're keeping to yourself, now is the time to expound
on it.  Ie, tell me what you're thinking about.  So what if we get
interrupts on that other line?  Ain't 'fraid no interrupts.

Currently on running machine:

boobcat:~# cat /proc/interrupts 
           CPU0       
  2:          0            MIPS  MV64440-Cascade
  3:          0            MIPS  MV64440-Cascade
  7:      73220            MIPS  timer
  8:      12019          RM7000  eth0
 52:        175     BC-MV-64440  mpsc-sdma

ERR:         78
boobcat:~#


Actually, the ERR thing kinda worries me.  I wonder wtf that is all
about.

>> Reset.c:
> >> >>
> >> >> What's wrong with using include file?
> >> >
> >> >what include file?  you mean for the ds1511_start_whatever
> prototype?
> >> >there isn't one in the .h for that, and besides, it's just one
> >> >function.  if that's even what you're talking about.
> >> [MK] Can we add the prototype to the include file and include it
> >> properly?
> >
> >Why?
> [MK] Why not? Prototypes should be in header files.

If needed.  I'm not feeling the need too terribly much since this is
not general use stuff.  Just me and the boys.  But if you insist...?

> >> >
> >> >> Setup.c:
> >> >>
> >> >> 417: Let's postpone these changes, you have not done the
> >> corresponding
> >> >> FC changes. This is not required currently.
> >> >
> >> >Actually, I've found that I can't get away with not declaring
> memory.
> >> >It causes the kernel to fuck up in semi-obvious ways.  I could
> >> >flag it as RESERVED so it won't get used, if you're all that
> >> >worried.
> >> >
> >> >Shit, I just noticed that I'm missing a wired entry in there for
> >> >the other 128MiB.  Doh.  Actually, I should probably make that a
> >> >wired entry and let the kernel do whatever it wants for the first
> >> >128M. Hmm, maybe that's a bad idea too.
> >> [MK] OK as long as it is not used.
> >
> >I'll change that for now.  But try changing the FC code to load and
> >run at 30000000 just for grins.
> [MK] This is completely unnecessary for now. I have a problem with
> running FC code as it is without moving it anywhere.

Hey, you want some cheeze with that wine?  It's the least you could do
considering I just hacked the exception vectors for you.  Man, everyone
is so lazy around here.  Fine, skip it for now.  But sooner or later, I
*will* get that memory.

> >
> >> >> Ide-cs.c:
> >> >>
> >> >> 219: I don't get this while (1). It looks like it only
> >> >> terminates in success case.
> >> >
> >> >Hey, I didn't write this shit.  Care to enlighten me?  It looks to
> me
> >> >like it's looking for a matching card and io window by reading CIS
> >> >info from the card and checking the Vcc, Vpp, Vcw, and other
> >> >stuff. Believe me, I spent several painful days in this code.
> >> >
> >> >If you're asking me how does it get out of the loop if it doesn't
> >> >find a match, look at the CS_CHECK macro.
> >> [MK] OK.
> >
> >Still waiting for some pearls of wisdom here.
> [MK] It is OK, I've missed this code obfuscation in CS_CHECK.
