Skip to contentSkip to conversation

MUX driver on E55

parisc-linux Christoph Plattner 3 participants 7 messages Sep 13, 2002 – Sep 17, 2002 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hallo Ryan !

Congratulation, your MUX driver on port 0 is really working on my machine !!

What do you miss to support the other lines ? Have you already knowledge of the data structure ? Can I help you here in the code ?

Another point: you mentioned the skeleton of the SCSI SPIFI driver. Where can I find that ? I only found a NetBSD code, which I will use as functional template, but I do not know, if this would be enough. Can you give me a hint in this point ?

Christoph

Signature · 3 lines
-------------------------------------------------------
private:	[email protected]
company:	[email protected]
#1 lore raw
Quoted 4 lines · Christoph Plattner

Hallo Ryan !

Congratulation, your MUX driver on port 0 is really working on my machine !!

Glad to hear that!

Quoted 1 line

What do you miss to support the other lines ?

I am not sure, I've never tried to hook up additional lines. I do have an 8-port MDP somewhere, I'll look for it here shortly, and see if I can hook it up.

Quoted 1 line

Have you already knowledge of the data structure ?

Just what I have added into the driver. If there is something that we are obviously missing, I can go back and reference the HP-UX mux driver and see what is missing.

Quoted 1 line

Can I help you here in the code ?

Please! :) I do not use multiple lines currently ... I only use the line 0, so any testing, optimizing, etc is greatly appreciated!

Quoted 5 lines

Another point: you mentioned the skeleton of the SCSI SPIFI driver. Where can I find that ? I only found a NetBSD code, which I will use as functional template, but I do not know, if this would be enough. Can you give me a hint in this point ?

I have it on my local system. It is _very_ ugly at this point. I have got enough to query information from the spifi chip, register an interrupt, etc... but currently I can not get the spifi chip to actually generate an interrupt.

I would be happy to send you a copy when I get back next monday (unless you catch my in the next hour or so), but I'm not ready to check it into CVS yeah until I get rid of the some ugly hardcoded hacks, global variables, etc. Right now the driver is really coded to gather info from the ESIEE E35 that I have been testing on. Once again, I do not have any docs on the chipset, I am using both the NetBSD and HP-UX drivers as reference. :(

The driver should be easy to modify for your specific E55, but not sure if you are interested in that level of work, messyness now. I promise it will get much better :)

Thanks,

- Ryan

Quoted 8 lines

Christoph

Signature · 3 lines
-------------------------------------------------------
private:	[email protected]
company:	[email protected]
#2 lore raw

Hello,

if it is possible, send the code to me (perhpas I can have a look @ week end.

Is it possible to geht the HP-UX driver codes for those to things ? MUX + SCSI ?

I was offered to sign a NDA, but then nothing happens ... It would be more easy for me to read such original HP-UX code. Perhaps you see a possibility to send it also.

Have a nice week end

Christoph

Quoted 65 lines · Ryan Bradetich
Quoted 4 lines · Christoph Plattner

Hallo Ryan !

Congratulation, your MUX driver on port 0 is really working on my machine !!

Glad to hear that!

Quoted 1 line

What do you miss to support the other lines ?

I am not sure, I've never tried to hook up additional lines. I do have an 8-port MDP somewhere, I'll look for it here shortly, and see if I can hook it up.

Quoted 1 line

Have you already knowledge of the data structure ?

Just what I have added into the driver. If there is something that we are obviously missing, I can go back and reference the HP-UX mux driver and see what is missing.

Quoted 1 line

Can I help you here in the code ?

Please! :) I do not use multiple lines currently ... I only use the line 0, so any testing, optimizing, etc is greatly appreciated!

Quoted 5 lines

Another point: you mentioned the skeleton of the SCSI SPIFI driver. Where can I find that ? I only found a NetBSD code, which I will use as functional template, but I do not know, if this would be enough. Can you give me a hint in this point ?

I have it on my local system. It is _very_ ugly at this point. I have got enough to query information from the spifi chip, register an interrupt, etc... but currently I can not get the spifi chip to actually generate an interrupt.

I would be happy to send you a copy when I get back next monday (unless you catch my in the next hour or so), but I'm not ready to check it into CVS yeah until I get rid of the some ugly hardcoded hacks, global variables, etc. Right now the driver is really coded to gather info from the ESIEE E35 that I have been testing on. Once again, I do not have any docs on the chipset, I am using both the NetBSD and HP-UX drivers as reference. :(

The driver should be easy to modify for your specific E55, but not sure if you are interested in that level of work, messyness now. I promise it will get much better :)

Thanks,

- Ryan

Quoted 8 lines

Christoph

--
-------------------------------------------------------

private:      [email protected]
company:      [email protected]
Signature · 3 lines
-------------------------------------------------------
private:	[email protected]
company:	[email protected]

A message that is not in the archive (sent off-list or not yet received): 1031964117.1043.29.camel@beavis

#4 lore raw

[parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code

Yes, I would be interested in HP-UX source code access, if there are no costs I have to pay. I would sign a NDA.

The status of SCSI driver you sent me:
The machine does not really access the hardware. Also if I patch the data structures or the "dev->hpa" pointer, the driver reacts the same strange way.

The status of MUX: It is not working to access to offset 0x80 for the lines. The machine dies. I think this problem can be solved very easy, looking in the HP-UX driver code.

I will do some futher code instrumentation on the SPIFI driver. Then I will reread the driver of you and NetBSD to have an idea, which access does fail here. Or do we have a wrong hardware access anyway ?

Good start of the next week

Christoph

Quoted 113 lines · Ryan Bradetich

Thomas and Christoph,

Here is the current diff I have (I told you it was ugly! :))

I can not send you the HP-UX code. If you are interested in pursuing the NDA to get access to the drivers, I can approach Alan Meyer (LSO Lab manager). I am in IT, not the R&D lab so I do not have much insight in what they are doing :(

Hope this diff helps, and together hopefully we can get this to work and committed!

thanks,

- Ryan

Quoted 85 lines · Christoph Plattner

Hello,

if it is possible, send the code to me (perhpas I can have a look @ week end.

Is it possible to geht the HP-UX driver codes for those to things ? MUX + SCSI ?

I was offered to sign a NDA, but then nothing happens ... It would be more easy for me to read such original HP-UX code. Perhaps you see a possibility to send it also.

Have a nice week end

Christoph

Quoted 49 lines · Ryan Bradetich
Quoted 4 lines · Christoph Plattner

Hallo Ryan !

Congratulation, your MUX driver on port 0 is really working on my machine !!

Glad to hear that!

Quoted 1 line

What do you miss to support the other lines ?

I am not sure, I've never tried to hook up additional lines. I do have an 8-port MDP somewhere, I'll look for it here shortly, and see if I can hook it up.

Quoted 1 line

Have you already knowledge of the data structure ?

Just what I have added into the driver. If there is something that we are obviously missing, I can go back and reference the HP-UX mux driver and see what is missing.

Quoted 1 line

Can I help you here in the code ?

Please! :) I do not use multiple lines currently ... I only use the line 0, so any testing, optimizing, etc is greatly appreciated!

Quoted 5 lines

Another point: you mentioned the skeleton of the SCSI SPIFI driver. Where can I find that ? I only found a NetBSD code, which I will use as functional template, but I do not know, if this would be enough. Can you give me a hint in this point ?

I have it on my local system. It is _very_ ugly at this point. I have got enough to query information from the spifi chip, register an interrupt, etc... but currently I can not get the spifi chip to actually generate an interrupt.

I would be happy to send you a copy when I get back next monday (unless you catch my in the next hour or so), but I'm not ready to check it into CVS yeah until I get rid of the some ugly hardcoded hacks, global variables, etc. Right now the driver is really coded to gather info from the ESIEE E35 that I have been testing on. Once again, I do not have any docs on the chipset, I am using both the NetBSD and HP-UX drivers as reference. :(

Quoted 16 lines

The driver should be easy to modify for your specific E55, but not sure if you are interested in that level of work, messyness now. I promise it will get much better :)

Thanks,

- Ryan

Quoted 8 lines

Christoph

--
-------------------------------------------------------

private:      [email protected]
company:      [email protected]
Quoted 5 lines

--
-------------------------------------------------------

private:      [email protected]
company:      [email protected]

------------------------------------------------------------------------
Name: spifi.patch
spifi.patch Type: text/x-patch
Encoding: quoted-printable

Signature · 3 lines
-------------------------------------------------------
private:	[email protected]
company:	[email protected]
#5 lore raw

Re: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code

Quoted 3 lines · Christoph Plattner

The status of MUX: It is not working to access to offset 0x80 for the lines. The machine dies. I think this problem can be solved very easy, looking in the HP-UX driver code.

Not so sure...

common/sio/mux2.c:

for (loop = 0; loop < ports; loop++, ttyp++) {
        HW.hpa                  = MUX_DATA.hpa + 0x800 + (loop * 0x80);
        HW.io_reg_ptr           = (io_reg_type *)(HW.hpa + 0x30);
}
Signature · 1 line
Revolutions do not require corporate support.
#6 lore raw

Re: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code

Thanks for that !

But I think, my Linux code dose the same !!!

	info->iomem_base = (void *)(hpa + MUX_OFFSET + 
				    (line * MUX_LINE_OFFSET));

This info->iomem_base is used by all accesses, the registers of i/o are defined by Ryan as:

#define IO_COMMAND_REG_OFFSET 0x30
#define IO_STATUS_REG_OFFSET 0x34
#define IO_DATA_REG_OFFSET 0x3c
#define IO_DCOUNT_REG_OFFSET 0x40
#define IO_UCOUNT_REG_OFFSET 0x44
#define IO_FIFOS_REG_OFFSET 0x48

So the offset of 0x30 is inside those macros.

An example of an access:

		data = __raw_readl((unsigned long)info->iomem_base 
				   + IO_DATA_REG_OFFSET);

... reading characters from the input buffers.

Any further idea ?

Ryan, you mentioned problems concerning missing locks, but I cannot think about this. Those devices should be controlled independent, am I wrong ?

I hope, we will solve this all (all means including SPIFI SCSI driver too !).

Christoph

Quoted 21 lines · Matthew Wilcox
Quoted 3 lines · Christoph Plattner

The status of MUX: It is not working to access to offset 0x80 for the lines. The machine dies. I think this problem can be solved very easy, looking in the HP-UX driver code.

Not so sure...

common/sio/mux2.c:

for (loop = 0; loop < ports; loop++, ttyp++) {
        HW.hpa                  = MUX_DATA.hpa + 0x800 + (loop * 0x80);
        HW.io_reg_ptr           = (io_reg_type *)(HW.hpa + 0x30);
}

--
Revolutions do not require corporate support.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Signature · 3 lines
-------------------------------------------------------
private:	[email protected]
company:	[email protected]
#7 lore raw

Re: [parisc-linux] Re: SCSI/MUX driver on E55, NDA for sorce code

Quoted 24 lines · Christoph Plattner

Thanks for that !

But I think, my Linux code dose the same !!!

	info->iomem_base = (void *)(hpa + MUX_OFFSET + 
				    (line * MUX_LINE_OFFSET));

This info->iomem_base is used by all accesses, the registers of i/o are defined by Ryan as:

#define IO_COMMAND_REG_OFFSET 0x30
#define IO_STATUS_REG_OFFSET 0x34
#define IO_DATA_REG_OFFSET 0x3c
#define IO_DCOUNT_REG_OFFSET 0x40
#define IO_UCOUNT_REG_OFFSET 0x44
#define IO_FIFOS_REG_OFFSET 0x48

So the offset of 0x30 is inside those macros.

An example of an access:

		data = __raw_readl((unsigned long)info->iomem_base 
				   + IO_DATA_REG_OFFSET);
Quoted 7 lines

... reading characters from the input buffers.

Any further idea ?

Ryan, you mentioned problems concerning missing locks, but I cannot think about this. Those devices should be controlled independent, am I wrong ?

Locks was just an idea of why it might now work. Nothing suggested that yet. I found the MPD, now I just need to make a cable for it to hook up to a different system and test with. Hopefully will get this done this week and I'll take a look at it :)

Quoted 4 lines

I hope, we will solve this all (all means including SPIFI SCSI driver too !).

Christoph