IXP425: help on HSS channelized service

IXP425: help on HSS channelized service

[Davide Di Gesualdo]

Hi Krzysztof,
thanks for your answer..

 > The buffers have different structures for RX and TX.
Do you refer to the tx_pointer_lists (which is not present for rx 
buffer)? The organization of rx and tx buffers isn't the same? If I want 
to read bytes of timeslot "ts" at offset "off", is it correct to read at 
position "chan_rx_buf(port) + CHAN_RX_FRAMES * ts + off"?

 > Looks like a modified code from one of my ixp4xx-[0-9][0-9] branch.
It IS a modified code from your ixp4xx_hss.

 > Have you tried using the original code in e.g. ixp4xx-31?
I cannot use right the original code because I need transfer callback in 
kernel space, not in user space..

 > You may need to make some trivial changes related to "MVIP".
Sorry, what changes do you mean? Keep in mind I have one channel per 
timeslot (maybe you refer to the possibility to have more channels?)

Thank you!

Davide



Krzysztof Halasa ha scritto:
 > Davide Di Gesualdo <davide.digesualdo@kaskonetworks.it> writes:
 >
 >> I'm writing a kernel module for a HSS channelized service on IXP425
 >> processor, based on ixp4xx_hss. I'm developing on a IXDPG425 Intel
 >> board, and the HSS bus is attached to four Si3210 ProSLIC chips.
 >> The purpose of this module is to read/write from/to HSS 8-byte buffers
 >> in raw mode (no particular alignment is required). In write direction,
 >> everything seems ok: if I write a buffer like
 >> char buf[] = {0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb};
 >> on a fixed timeslot and then read the TXD pin signal with a scope, I
 >> can see the correct waveform at the correct place; I've also tried to
 >> write a tone with a fixed freqeuncy, and I've listened it correctly.
 >> The problem comes with read direction: I've tried to make a loopback
 >> by copying the rxbuffer in the txbuffer, but I can't hear my voice
 >> back (instead I hear something like a continous buzz). I'm quite sure
 >> I read the rxbuffer in the correct way (I do the same when I write
 >> txbuffer, which works properly!).
 >
 > The buffers have different structures for RX and TX.
 >
 >> This is the ISR for HSS
 >> read-complete interrupt:
 >
 > Looks like a modified code from one of my ixp4xx-[0-9][0-9] branch. Have
 > you tried using the original code in e.g. ixp4xx-31? You may need to
 > make some trivial changes related to "MVIP".
 >
 > Not that my channelized HSS code is flawless or something, far from it,
 > but it works, both directions.


-- 
Davide Di Gesualdo
Kasko Networks S.r.l.
P.zza Regina Margherita, 7
L'Aquila (AQ) - CAP 67100 - Italy
Labs: +39 0862200460
Mobile: +39 3206203127
VoIP: +39 0857993233
Skype: davide.digesualdo

IXP425: help on HSS channelized service

[Davide Di Gesualdo]

Hi all,
I'm writing a kernel module for a HSS channelized service on IXP425 
processor, based on ixp4xx_hss. I'm developing on a IXDPG425 Intel 
board, and the HSS bus is attached to four Si3210 ProSLIC chips.
The purpose of this module is to read/write from/to HSS 8-byte buffers 
in raw mode (no particular alignment is required). In write direction, 
everything seems ok: if I write a buffer like
char buf[] = {0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb};
on a fixed timeslot and then read the TXD pin signal with a scope, I can 
see the correct waveform at the correct place; I've also tried to write 
a tone with a fixed freqeuncy, and I've listened it correctly.
The problem comes with read direction: I've tried to make a loopback by 
copying the rxbuffer in the txbuffer, but I can't hear my voice back 
(instead I hear something like a continous buzz). I'm quite sure I read 
the rxbuffer in the correct way (I do the same when I write txbuffer, 
which works properly!). This is the ISR for HSS read-complete interrupt:

static void hss_chan_irq(void *pdev)
{
	struct port *port = pdev;
	int ch, bytes_received;
	unsigned int first, errors, tx_list, rx_offset, v;
	char *rx_buf, *tx_buf;

	spin_lock(&npe_lock);
	while ((v = qmgr_get_entry(queue_ids[port->id].chan))) {
		first = v >> 24;
		errors = (v >> 16) & 0xFF;
		tx_list = (v >> 8) & 0xFF;
		rx_offset = v & 0xFF;

		BUG_ON(rx_offset % CHAN_RX_TRIGGER);
		BUG_ON(rx_offset >= CHAN_RX_FRAMES);
		BUG_ON(tx_list >= CHAN_TX_LISTS);

		bytes_received = rx_offset - port->chan_current_rx;
		if(bytes_received < 0)
			bytes_received += CHAN_RX_FRAMES;

		dma_sync_single(port->dev, port->chan_rx_buf_phys, 
chan_rx_buf_len(port), DMA_FROM_DEVICE);

		while(bytes_received >= CHAN_RX_TRIGGER) {
			if(port->chan_current_rx >= CHAN_RX_FRAMES)
				port->chan_current_rx = 0;
	
			if(port->chan_current_tx >= CHAN_TX_FRAMES)
				port->chan_current_tx = 0;

			for(ch = 0; ch < MAX_CHAN_DEVICES; ch++) {
				if(port->chan_devices[ch]->opened) {
					tx_buf = chan_tx_buf(port) + port->chan_current_tx + 
(CHAN_TX_FRAMES * port->chan_devices[ch]->timeslot);
					rx_buf = chan_rx_buf(port) + port->chan_current_rx + 
(CHAN_RX_FRAMES * port->chan_devices[ch]->timeslot);

					memcpy(tx_buf, rx_buf, CHAN_RX_TRIGGER);
				}
			}
			bytes_received -= CHAN_RX_TRIGGER;
			port->chan_current_rx += CHAN_RX_TRIGGER;
			port->chan_current_tx += CHAN_RX_TRIGGER;
		}
		dma_sync_single(port->dev, port->chan_tx_buf_phys, 
chan_tx_buf_len(port), DMA_TO_DEVICE);
	}
	spin_unlock(&npe_lock);
}

with buffers configuration as follow:

#define MIN_FRAME_SIZE		16
#define MAX_FRAME_SIZE		256
#define MAX_CHANNELS		(MAX_FRAME_SIZE / 8)
#define MAX_CHAN_DEVICES	32

#define CHAN_RX_TRIGGER		8
#define CHAN_RX_FRAMES		128
#define CHAN_TX_LIST_FRAMES	32
#define CHAN_TX_LISTS		4
#define CHAN_TX_FRAMES		(CHAN_TX_LIST_FRAMES * CHAN_TX_LISTS)

port->chan_current_rx is initialized as 0, port->chan_current_tx is 
initialized as 16; all 32 timeslots are configured as VOICE64K; the NPE 
configuration functions are the ones coded by Krzysztof Halasa.

Any suggestion would be really appreciated!
Thanks,

Davide Di Gesualdo

-- 
Davide Di Gesualdo
Kasko Networks S.r.l.
P.zza Regina Margherita, 7
L'Aquila (AQ) - CAP 67100 - Italy
Labs: +39 0862200460
Mobile: +39 3206203127
VoIP: +39 0857993233
Skype: davide.digesualdo

IXP425: help on HSS channelized service

[Juergen Schindele]

Am Dienstag, 24. November 2009 schrieb Davide Di Gesualdo:
> Hi all,
Dear Davide,
i am using ixp4xx-hss for an HDLC.X21 frontend in packetized mode
with all timeslots from kernel version 2.6.27.36
To receive correctly i had to modify the parameters 
in "hss_config_set_pcr" function. I compared to intel software stack
for IXP425 which was already working for us. 

in function static void hss_config_set_pcr(struct port *port)
....
-		msg.data32 = PCR_FRM_SYNC_OUTPUT_RISING | PCR_MSB_ENDIAN |
-			PCR_TX_DATA_ENABLE;
+		msg.data32 = PCR_FRM_SYNC_ACTIVE_HIGH | PCR_MSB_ENDIAN |
+			PCR_TX_DATA_ENABLE | PCR_FCLK_EDGE_RISING | PCR_FRM_PULSE_DISABLED;
....

Nevertheless i am receiving correct data but packet len is always zero!
Have you already encountered this ???

Bye 
> I'm writing a kernel module for a HSS channelized service on IXP425 
> processor, based on ixp4xx_hss. I'm developing on a IXDPG425 Intel 
> board, and the HSS bus is attached to four Si3210 ProSLIC chips.
> The purpose of this module is to read/write from/to HSS 8-byte buffers 
> in raw mode (no particular alignment is required). In write direction, 
> everything seems ok: if I write a buffer like
> char buf[] = {0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb};
> on a fixed timeslot and then read the TXD pin signal with a scope, I can 
> see the correct waveform at the correct place; I've also tried to write 
> a tone with a fixed freqeuncy, and I've listened it correctly.
> The problem comes with read direction: I've tried to make a loopback by 
> copying the rxbuffer in the txbuffer, but I can't hear my voice back 
> (instead I hear something like a continous buzz). I'm quite sure I read 
> the rxbuffer in the correct way (I do the same when I write txbuffer, 
> which works properly!). This is the ISR for HSS read-complete interrupt:
--------------------------------------------------------------
J?rgen Schindele  
Software-Entwicklung

NENTEC Netzwerktechnologie GmbH
Greschbachstr. 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
E-Mail:  schindele at nentec.de
WEB:     www.nentec.de
 
Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658

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

IXP425: help on HSS channelized service

[Krzysztof Halasa]

Juergen Schindele <schindele@nentec.de> writes:

> To receive correctly i had to modify the parameters 
> in "hss_config_set_pcr" function. I compared to intel software stack
> for IXP425 which was already working for us. 
>
> +		msg.data32 = PCR_FRM_SYNC_ACTIVE_HIGH | PCR_MSB_ENDIAN |
> +			PCR_TX_DATA_ENABLE | PCR_FCLK_EDGE_RISING | PCR_FRM_PULSE_DISABLED;
> ....

I'm currently using:

TX:
+       msg.data32 = PCR_DCLK_EDGE_RISING | PCR_FRM_SYNC_OUTPUT_RISING |
+               PCR_MSB_ENDIAN | PCR_TX_DATA_ENABLE | PCR_SOF_NO_FBIT;

RX:
+       msg.data32 &= ~(PCR_TX_DATA_ENABLE | PCR_DCLK_EDGE_RISING);

with possibility to change PCR_DCLK_EDGE_RISING in both directions
(reversing the clock edges used to send/sample data). The driver in the
official kernel has the edges reversed, it may be incompatible with
typical hardware (I'm going to fix it if my "test users" don't have
problems with it).

I don't use FRM sync signals, though. I think we should make it
configurable by the platform code somehow.

I've found that using PCR_FRM_PULSE_DISABLED creates a nasty problem -
packetized TX stops transmitting when it's brought up and down when
configured to use (IIRC) external clock, and without actual clock
available. I don't remember the exact details but it was something like
that. Perhaps I should try with Intel's settings once again to see if
the problems goes away. Theoretically it shouldn't matter since the
FRAME signal isn't used, but reality with HSS is a bit different -
especially when coupled with channelized traffic.

> Nevertheless i am receiving correct data but packet len is always zero!
> Have you already encountered this ???

Doesn't exactly look like using incorrect clock edge (though you may
want to check). Maybe inverted data signal?

You may also want to try the channelized mode and see what you're
getting in the buffers (hexdump /dev/hss*). The HDLC controller is not
used in channelized mode.
-- 
Krzysztof Halasa

IXP425: help on HSS channelized service

[Davide Di Gesualdo]

Hello Juergen,
I'm sure the configuration of PCR for my application is ok (it's ported 
from a kernel module which uses Intel Access Library).. anyway, it looks 
like the following:
		// tx
		msg.data32 = 	PCR_FRM_SYNC_OUTPUT_RISING |
				PCR_MSB_ENDIAN |
				PCR_FRM_SYNC_RISINGEDGE |
				PCR_TX_DATA_ENABLE |
				PCR_DCLK_EDGE_RISING |
				PCR_SYNC_CLK_DIR_OUTPUT |
				PCR_SOF_NO_FBIT;
		// rx
		msg.data32 =    PCR_FRM_SYNC_RISINGEDGE |
                                 PCR_MSB_ENDIAN |
                                 PCR_SOF_NO_FBIT;

Bye!

Juergen Schindele ha scritto:
> Am Dienstag, 24. November 2009 schrieb Davide Di Gesualdo:
>> Hi all,
> Dear Davide,
> i am using ixp4xx-hss for an HDLC.X21 frontend in packetized mode
> with all timeslots from kernel version 2.6.27.36
> To receive correctly i had to modify the parameters 
> in "hss_config_set_pcr" function. I compared to intel software stack
> for IXP425 which was already working for us. 
> 
> in function static void hss_config_set_pcr(struct port *port)
> ....
> -		msg.data32 = PCR_FRM_SYNC_OUTPUT_RISING | PCR_MSB_ENDIAN |
> -			PCR_TX_DATA_ENABLE;
> +		msg.data32 = PCR_FRM_SYNC_ACTIVE_HIGH | PCR_MSB_ENDIAN |
> +			PCR_TX_DATA_ENABLE | PCR_FCLK_EDGE_RISING | PCR_FRM_PULSE_DISABLED;
> ....
> 
> Nevertheless i am receiving correct data but packet len is always zero!
> Have you already encountered this ???
> 
> Bye 
>> I'm writing a kernel module for a HSS channelized service on IXP425 
>> processor, based on ixp4xx_hss. I'm developing on a IXDPG425 Intel 
>> board, and the HSS bus is attached to four Si3210 ProSLIC chips.
>> The purpose of this module is to read/write from/to HSS 8-byte buffers 
>> in raw mode (no particular alignment is required). In write direction, 
>> everything seems ok: if I write a buffer like
>> char buf[] = {0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb};
>> on a fixed timeslot and then read the TXD pin signal with a scope, I can 
>> see the correct waveform at the correct place; I've also tried to write 
>> a tone with a fixed freqeuncy, and I've listened it correctly.
>> The problem comes with read direction: I've tried to make a loopback by 
>> copying the rxbuffer in the txbuffer, but I can't hear my voice back 
>> (instead I hear something like a continous buzz). I'm quite sure I read 
>> the rxbuffer in the correct way (I do the same when I write txbuffer, 
>> which works properly!). This is the ISR for HSS read-complete interrupt:
> --------------------------------------------------------------
> J?rgen Schindele  
> Software-Entwicklung
> 
> NENTEC Netzwerktechnologie GmbH
> Greschbachstr. 12
> 76229 Karlsruhe
> Deutschland
> Telefon: +49 721 94249-51
> Telefax: +49 721 94249-10
> E-Mail:  schindele at nentec.de
> WEB:     www.nentec.de
>  
> Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim HRB 107658
> 
> --------------------------------------------------------------
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 


-- 
Davide Di Gesualdo
Kasko Networks S.r.l.
P.zza Regina Margherita, 7
L'Aquila (AQ) - CAP 67100 - Italy
Labs: +39 0862200460
Mobile: +39 3206203127
VoIP: +39 0857993233
Skype: davide.digesualdo

IXP425: help on HSS channelized service

[Krzysztof Halasa]

Davide Di Gesualdo <davide.digesualdo@kaskonetworks.it> writes:

> I'm writing a kernel module for a HSS channelized service on IXP425
> processor, based on ixp4xx_hss. I'm developing on a IXDPG425 Intel
> board, and the HSS bus is attached to four Si3210 ProSLIC chips.
> The purpose of this module is to read/write from/to HSS 8-byte buffers
> in raw mode (no particular alignment is required). In write direction,
> everything seems ok: if I write a buffer like
> char buf[] = {0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb, 0xcb};
> on a fixed timeslot and then read the TXD pin signal with a scope, I
> can see the correct waveform at the correct place; I've also tried to
> write a tone with a fixed freqeuncy, and I've listened it correctly.
> The problem comes with read direction: I've tried to make a loopback
> by copying the rxbuffer in the txbuffer, but I can't hear my voice
> back (instead I hear something like a continous buzz). I'm quite sure
> I read the rxbuffer in the correct way (I do the same when I write
> txbuffer, which works properly!).

The buffers have different structures for RX and TX.

> This is the ISR for HSS
> read-complete interrupt:

Looks like a modified code from one of my ixp4xx-[0-9][0-9] branch. Have
you tried using the original code in e.g. ixp4xx-31? You may need to
make some trivial changes related to "MVIP".

Not that my channelized HSS code is flawless or something, far from it,
but it works, both directions.
-- 
Krzysztof Halasa

IXP425: help on HSS channelized service

[Juergen Schindele]

Am Mittwoch, 25. November 2009 schrieb Krzysztof Halasa:
> The buffers have different structures for RX and TX.
This was a very good hint :-). I discovered that the 
"struct desc" used in the kernel mainline driver is quite 
different from the one used in INTEL code !?????.
When I replace the "struct desc" (see below) it works fine for me.
Isn't there a general problem with this driver when it works only 
for channelized mode (your case) ???
Has sombody made it working in HDLC_PIPE mode ????

here my changes:
I replaced 

struct desc {
        u32 next;               /* pointer to next buffer, unused */

#ifdef __ARMEB__
        u16 buf_len;            /* buffer length */
        u16 pkt_len;            /* packet length */
        u32 data;               /* pointer to data buffer in RAM */
        u8 status;
        u8 error_count;
        u16 __reserved;
#else
        u16 pkt_len;            /* packet length */
        u16 buf_len;            /* buffer length */
        u32 data;               /* pointer to data buffer in RAM */
        u16 __reserved;
        u8 error_count;
        u8 status;
#endif
        u32 __reserved1[4];
}

with 

struct desc {
#ifdef __ARMEB__
    u8   status;                /* status of packet desriptor */
    u8   error_count;           /* number of errors */
    u8   chain_count;           /* used for chained buffers otherwise 0 */
    u8   __reserved1;           /* reserved byte for word alignment */

    u16  pkt_len;               /* packet length payload */
    u16  __reserved2;           /* reserved short for word alignment */

    u32  head;                  /* pointer to first if chained buffers */
    u32  next;                  /* pointer to next if chained buffers */
    u32  data;                  /* pointer to data buffer in RAM */
    u32  buf_len;               /* total length of buffer in RAM */
#else
    u8   __reserved1;           /* reserved byte for word alignment */
    u8   chain_count;           /* used for chained buffers otherwise 0 */
    u8   error_count;           /* number of errors */
    u8   status;                /* status of packet desriptor */

    u16  __reserved2;           /* reserved short for word alignment */
    u16  pkt_len;               /* packet length payload */

    u32  head;                  /* pointer to first if chained buffers */
    u32  next;                  /* pointer to next if chained buffers */
    u32  data;                  /* pointer to data buffer in RAM */
    u32  buf_len;               /* total length of buffer in RAM */
#endif
    u32  __reserved3[2];        /* reserved to fill up */
}
 
--------------------------------------------------------------
J?rgen Schindele  
Software-Entwicklung

NENTEC Netzwerktechnologie GmbH
Greschbachstr. 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
E-Mail:  schindele at nentec.de
WEB:     www.nentec.de
 
Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658
--------------------------------------------------------------

IXP425: help on HSS channelized service

[Russell King - ARM Linux]

On Thu, Nov 26, 2009 at 04:43:07PM +0200, Juergen Schindele wrote:
> Am Mittwoch, 25. November 2009 schrieb Krzysztof Halasa:
> > The buffers have different structures for RX and TX.
> This was a very good hint :-). I discovered that the 
> "struct desc" used in the kernel mainline driver is quite 
> different from the one used in INTEL code !?????.
> When I replace the "struct desc" (see below) it works fine for me.
> Isn't there a general problem with this driver when it works only 
> for channelized mode (your case) ???
> Has sombody made it working in HDLC_PIPE mode ????
> 
> here my changes:
> I replaced 
> 
> struct desc {
>         u32 next;               /* pointer to next buffer, unused */
> 
> #ifdef __ARMEB__
>         u16 buf_len;            /* buffer length */
>         u16 pkt_len;            /* packet length */
>         u32 data;               /* pointer to data buffer in RAM */
>         u8 status;
>         u8 error_count;
>         u16 __reserved;
> #else
>         u16 pkt_len;            /* packet length */
>         u16 buf_len;            /* buffer length */
>         u32 data;               /* pointer to data buffer in RAM */
>         u16 __reserved;
>         u8 error_count;
>         u8 status;
> #endif
>         u32 __reserved1[4];

If these structures are sensitive to the byte-endian, they should be
defined using [bl]e(32|16|8) so that sparse can check that you're
using appropriate cpu_to_xxx() and xxx_to_cpu() endian conversions on
them.

IXP425: help on HSS channelized service

[Juergen Schindele]

Am Donnerstag, 26. November 2009 schrieb Russell King - ARM Linux:
> On Thu, Nov 26, 2009 at 04:43:07PM +0200, Juergen Schindele wrote:
> > Am Mittwoch, 25. November 2009 schrieb Krzysztof Halasa:
> > > The buffers have different structures for RX and TX.
> > This was a very good hint :-). I discovered that the 
> > "struct desc" used in the kernel mainline driver is quite 
> > different from the one used in INTEL code !?????.
> > When I replace the "struct desc" (see below) it works fine for me.
> > Isn't there a general problem with this driver when it works only 
> > for channelized mode (your case) ???
> > Has sombody made it working in HDLC_PIPE mode ????
> > 
> > here my changes:
> > I replaced 
> > 
> > struct desc {
> >         u32 next;               /* pointer to next buffer, unused */
> > 
> > #ifdef __ARMEB__
> >         u16 buf_len;            /* buffer length */
> >         u16 pkt_len;            /* packet length */
> >         u32 data;               /* pointer to data buffer in RAM */
> >         u8 status;
> >         u8 error_count;
> >         u16 __reserved;
> > #else
> >         u16 pkt_len;            /* packet length */
> >         u16 buf_len;            /* buffer length */
> >         u32 data;               /* pointer to data buffer in RAM */
> >         u16 __reserved;
> >         u8 error_count;
> >         u8 status;
> > #endif
> >         u32 __reserved1[4];
> 
> If these structures are sensitive to the byte-endian, they should be
> defined using [bl]e(32|16|8) so that sparse can check that you're
> using appropriate cpu_to_xxx() and xxx_to_cpu() endian conversions on
> them.
Thanks for your information. I can include "linux/types.h"
where are defined these typedefs (i think its what you mean):

typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;

but where are these ????
typedef __u8 __bitwise __le8;
typedef __u8 __bitwise __be8;

are they missing or am _I_ missing something ??? 

--------------------------------------------------------------
J?rgen Schindele  
Software-Entwicklung

NENTEC Netzwerktechnologie GmbH
Greschbachstr. 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
E-Mail:  schindele at nentec.de
WEB:     www.nentec.de
 
Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658
--------------------------------------------------------------

IXP425: help on HSS channelized service

[Russell King - ARM Linux]

On Thu, Nov 26, 2009 at 05:44:50PM +0200, Juergen Schindele wrote:
> Thanks for your information. I can include "linux/types.h"
> where are defined these typedefs (i think its what you mean):
> 
> typedef __u16 __bitwise __le16;
> typedef __u16 __bitwise __be16;
> typedef __u32 __bitwise __le32;
> typedef __u32 __bitwise __be32;

Yes.

> but where are these ????
> typedef __u8 __bitwise __le8;
> typedef __u8 __bitwise __be8;
> 
> are they missing or am _I_ missing something ??? 

Well, thinking about it, __le8/__be8 don't make that much sense...

IXP425: help on HSS channelized service

[Krzysztof Halasa]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

>> struct desc {
>>         u32 next;               /* pointer to next buffer, unused */
>> 
>> #ifdef __ARMEB__
>>         u16 buf_len;            /* buffer length */
>>         u16 pkt_len;            /* packet length */
>>         u32 data;               /* pointer to data buffer in RAM */
>>         u8 status;
>>         u8 error_count;
>>         u16 __reserved;
>> #else
>>         u16 pkt_len;            /* packet length */
>>         u16 buf_len;            /* buffer length */
>>         u32 data;               /* pointer to data buffer in RAM */
>>         u16 __reserved;
>>         u8 error_count;
>>         u8 status;
>> #endif
>>         u32 __reserved1[4];
>
> If these structures are sensitive to the byte-endian, they should be
> defined using [bl]e(32|16|8) so that sparse can check that you're
> using appropriate cpu_to_xxx() and xxx_to_cpu() endian conversions on
> them.

The values are in CPU order. I'll run sparse on this stuff, haven't done
that in a (too) long time.

It used to work in both LE and BE modes, though.
-- 
Krzysztof Halasa

IXP425: help on HSS channelized service

[Krzysztof Halasa]

Juergen Schindele <schindele@nentec.de> writes:

>> The buffers have different structures for RX and TX.
> This was a very good hint :-). I discovered that the 
> "struct desc" used in the kernel mainline driver is quite 
> different from the one used in INTEL code !?????.

Actually I meant the structures for channelized I/O RX and TX.

> When I replace the "struct desc" (see below) it works fine for me.
> Isn't there a general problem with this driver when it works only 
> for channelized mode (your case) ???

It most certainly works in packetized (HDLC) mode.

Perhaps you're using IXP46x/43x CPU and the new firmware (3.x)?
The driver works with fw 2.4 (and some older), i.e. the last firmware
which works with IXP42x and 46x/43x.
-- 
Krzysztof Halasa

IXP425: help on HSS channelized service

[Juergen Schindele]

Am Donnerstag, 26. November 2009 schrieb Krzysztof Halasa:
> Juergen Schindele <schindele@nentec.de> writes:
> 
> >> The buffers have different structures for RX and TX.
> > This was a very good hint :-). I discovered that the 
> > "struct desc" used in the kernel mainline driver is quite 
> > different from the one used in INTEL code !?????.
> 
> Actually I meant the structures for channelized I/O RX and TX.
> 
> > When I replace the "struct desc" (see below) it works fine for me.
> > Isn't there a general problem with this driver when it works only 
> > for channelized mode (your case) ???
> 
> It most certainly works in packetized (HDLC) mode.
> 
> Perhaps you're using IXP46x/43x CPU and the new firmware (3.x)?
> The driver works with fw 2.4 (and some older), i.e. the last firmware
> which works with IXP42x and 46x/43x.
Thanks for your info. I thing thats the problem about it. I am using 
an 2.0 firmware from INTEL and that could be the problem.
Investigating......

--------------------------------------------------------------
J?rgen Schindele  
Software-Entwicklung

NENTEC Netzwerktechnologie GmbH
Greschbachstr. 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
E-Mail:  schindele at nentec.de
WEB:     www.nentec.de
 
Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658
--------------------------------------------------------------

IXP425: help on HSS channelized service

[Krzysztof Halasa]

Juergen Schindele <schindele@nentec.de> writes:

>> Perhaps you're using IXP46x/43x CPU and the new firmware (3.x)?
>> The driver works with fw 2.4 (and some older), i.e. the last firmware
>> which works with IXP42x and 46x/43x.
> Thanks for your info. I thing thats the problem about it. I am using 
> an 2.0 firmware from INTEL and that could be the problem.

If that's really 2.0 and not 3.0 then you can upgrade to 2.4 which is
compatible with the HSS driver.
-- 
Krzysztof Halasa

IXP425: help on HSS channelized service

[Juergen Schindele]

Am Samstag, 28. November 2009 schrieben Sie:
> Juergen Schindele <schindele@nentec.de> writes:
> 
> >> Perhaps you're using IXP46x/43x CPU and the new firmware (3.x)?
> >> The driver works with fw 2.4 (and some older), i.e. the last firmware
> >> which works with IXP42x and 46x/43x.
> > Thanks for your info. I thing thats the problem about it. I am using 
> > an 2.0 firmware from INTEL and that could be the problem.
> 
> If that's really 2.0 and not 3.0 then you can upgrade to 2.4 which is
> compatible with the HSS driver.
Yes i have already tried with 2.4 and it works without modification.
With the modification i posted it work also with 2.0. 
Thanks for your help !

--------------------------------------------------------------
J?rgen Schindele  
Software-Entwicklung

NENTEC Netzwerktechnologie GmbH
Greschbachstr. 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
E-Mail:  schindele at nentec.de
WEB:     www.nentec.de
 
Gesch?ftsf?hrung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658
--------------------------------------------------------------