ixp4xx_hss MAX_CHAN_DEVICES

ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi

I am interested in modifying ixp4xx_hss so that 4*32 channels can be
used for each hss device.

My first option is to modify the "defines" placed in the driver, but I
wonder if it would be useful to modify hss_plat_info to set this kind
of info.

Any comments on this?

Thanks

Miguel Ángel Álvarez

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa]

Hi,

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

> I am interested in modifying ixp4xx_hss so that 4*32 channels can be
> used for each hss device.

I assume you mean 4 multiplexed E1 (with an external multiplexer/framer).

> My first option is to modify the "defines" placed in the driver, but I
> wonder if it would be useful to modify hss_plat_info to set this kind
> of info.

I think we should add some "physical mode" parameter - single channel
(such as E1, T1 etc), 4 * E1, and any other (4 * T1 which is IIRC
special) when needed.

It can go into hss_plat_info - a fixed(?) HSS port property.
-- 
Krzysztof Halasa

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi

2008/11/21 Krzysztof Halasa <khc@pm.waw.pl>:
> Hi,
>
> "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:
>
>> I am interested in modifying ixp4xx_hss so that 4*32 channels can be
>> used for each hss device.
>
> I assume you mean 4 multiplexed E1 (with an external multiplexer/framer).
>

Sure. Sorry for not having stated it properly.

>> My first option is to modify the "defines" placed in the driver, but I
>> wonder if it would be useful to modify hss_plat_info to set this kind
>> of info.
>
> I think we should add some "physical mode" parameter - single channel
> (such as E1, T1 etc), 4 * E1, and any other (4 * T1 which is IIRC
> special) when needed.
>

This is a great idea. Lots of parameters are related, so setting this
"physical mode" should be enough to configure the rest. I will try to
prepare a simple patch in order to comment if the ideas are correct.

> It can go into hss_plat_info - a fixed(?) HSS port property.

Yes... I think it could be enough to make it a fixed property at the
moment. Maybe it could be added to sysfs in the future.

Miguel Ángel Álvarez

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi

I show you here the first steps of the adding of a physical_mode
configuration for ixp4xx_hss. The changes are not complete at all, but
I wanted to send this just to get some initial impressions.

diff -urN linux-2.6.26.7_hssorig/arch/arm/mach-ixp4xx/ixdp425-setup.c
linux-2.6.26.7/arch/arm/mach-ixp4xx/ixdp425-setup.c
--- linux-2.6.26.7_hssorig/arch/arm/mach-ixp4xx/ixdp425-setup.c	2008-11-24
11:21:07.000000000 +0100
+++ linux-2.6.26.7/arch/arm/mach-ixp4xx/ixdp425-setup.c	2008-11-24
11:29:05.000000000 +0100
@@ -350,11 +350,13 @@
 		.open		= hss_open,
 		.close		= hss_close,
 		.txreadyq	= 2,
+		.physical_mode = IXP4XX_HSS_4_E1,
 	}, {
 		.set_clock	= hss_set_clock,
 		.open		= hss_open,
 		.close		= hss_close,
 		.txreadyq	= 19,
+		.physical_mode = IXP4XX_HSS_4_E1,
 	}
 };

diff -urN linux-2.6.26.7_hssorig/drivers/net/wan/ixp4xx_hss.c
linux-2.6.26.7/drivers/net/wan/ixp4xx_hss.c
--- linux-2.6.26.7_hssorig/drivers/net/wan/ixp4xx_hss.c	2008-11-24
11:22:09.000000000 +0100
+++ linux-2.6.26.7/drivers/net/wan/ixp4xx_hss.c	2008-11-24
12:55:26.000000000 +0100
@@ -302,6 +302,7 @@
 	/* assigned channels, may be invalid with given frame length or mode */
 	u8 channels[MAX_CHANNELS];
 	int msg_count;
+	u8 phmode_pos;
 };

 /* NPE message structure */
@@ -388,6 +389,21 @@
 		  HSS1_PKT_RXFREE0_QUEUE, HSS1_CHL_RXTRIG_QUEUE},
 };

+struct physical_modes {
+	u8 id;
+	unsigned int frame_size;
+	unsigned int clock_rate;
+	u32 clock_config;
+};
+
+static const struct physical_modes phmodes[] = {
+	{IXP4XX_HSS_T1, 193, 1544000, CLK42X_SPEED_1544KHZ},
+	{IXP4XX_HSS_E1, 256, 2048000, CLK42X_SPEED_2048KHZ},
+	{IXP4XX_HSS_2_E1, 512, 4096000, CLK42X_SPEED_4096KHZ},
+	{IXP4XX_HSS_4_E1, 1024, 8192000, CLK42X_SPEED_8192KHZ},
+	{0, 256, 2048000, CLK42X_SPEED_2048KHZ}
+};
+
 /*****************************************************************************
  * utility functions
  ****************************************************************************/
@@ -624,7 +640,7 @@
 	msg.cmd = PORT_CONFIG_WRITE;
 	msg.hss_port = port->id;
 	msg.index = HSS_CONFIG_CLOCK_CR;
-	msg.data32 = CLK42X_SPEED_2048KHZ /* FIXME */;
+	msg.data32 = phmodes[port->phmode_pos].clock_config;
 	hss_npe_send(port, &msg, "HSS_SET_CLOCK_CR");

 	memset(&msg, 0, sizeof(msg));
@@ -2459,6 +2475,7 @@
 	return -EINVAL; /* FIXME not yet supported */
 }

+#if 0
 static ssize_t show_frame_size(struct device *dev,
 			       struct device_attribute *attr, char *buf)
 {
@@ -2499,6 +2516,7 @@
 	spin_unlock_irqrestore(&npe_lock, flags);
 	return ret;
 }
+#endif

 static ssize_t show_frame_offset(struct device *dev,
 				 struct device_attribute *attr, char *buf)
@@ -2635,7 +2653,7 @@
 	__ATTR(hdlc_chan, 0644, show_hdlc_chan, set_hdlc_chan),
 	__ATTR(clock_type, 0644, show_clock_type, set_clock_type),
 	__ATTR(clock_rate, 0644, show_clock_rate, set_clock_rate),
-	__ATTR(frame_size, 0644, show_frame_size, set_frame_size),
+	//__ATTR(frame_size, 0644, show_frame_size, set_frame_size),
 	__ATTR(frame_offset, 0644, show_frame_offset, set_frame_offset),
 	__ATTR(loopback, 0644, show_loopback, set_loopback),
 	__ATTR(mode, 0644, show_mode, set_mode),
@@ -2651,6 +2669,7 @@
 	struct net_device *dev;
 	hdlc_device *hdlc;
 	int i, err;
+	struct physical_modes* mode;

 	if ((port = kzalloc(sizeof(*port), GFP_KERNEL)) == NULL)
 		return -ENOMEM;
@@ -2669,6 +2688,17 @@
 		goto err_plat;
 	}

+	i = 0;
+	mode = &phmodes[0];
+	while (mode->id != 0) {
+		if (mode->id == port->plat->physical_mode) {
+			port->phmode_pos = i;
+			break;
+		}
+		i++;
+		mode = &phmodes[i];
+	}
+
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	hdlc = dev_to_hdlc(dev);
 	hdlc->attach = hss_hdlc_attach;
@@ -2678,8 +2708,8 @@
 	dev->do_ioctl = hss_hdlc_ioctl;
 	dev->tx_queue_len = 100;
 	port->clock_type = CLOCK_EXT;
-	port->clock_rate = 2048000;
-	port->frame_size = 256; /* E1 */
+	port->clock_rate = mode->clock_rate;
+	port->frame_size = mode->frame_size;
 	memset(port->channels, CHANNEL_UNUSED, sizeof(port->channels));
 	init_waitqueue_head(&port->chan_tx_waitq);
 	init_waitqueue_head(&port->chan_rx_waitq);
diff -urN linux-2.6.26.7_hssorig/include/asm-arm/arch-ixp4xx/platform.h
linux-2.6.26.7/include/asm-arm/arch-ixp4xx/platform.h
--- linux-2.6.26.7_hssorig/include/asm-arm/arch-ixp4xx/platform.h	2008-11-24
11:22:42.000000000 +0100
+++ linux-2.6.26.7/include/asm-arm/arch-ixp4xx/platform.h	2008-11-24
12:06:42.000000000 +0100
@@ -103,6 +103,11 @@
 	u8 hwaddr[6];
 };

+#define IXP4XX_HSS_T1     0x10
+#define IXP4XX_HSS_E1     0x11
+#define IXP4XX_HSS_2_E1   0x21
+#define IXP4XX_HSS_4_E1   0x41
+
 /* Information about built-in HSS (synchronous serial) interfaces */
 struct hss_plat_info {
 	int (*set_clock)(int port, unsigned int clock_type);
@@ -110,6 +115,7 @@
 		    void (*set_carrier_cb)(void *pdev, int carrier));
 	void (*close)(int port, void *pdev);
 	u8 txreadyq;
+	u8 physical_mode;
 };

 /*

I have some questions to continue the changes:
- How should all these changes interact with show_frame_size and set_frame_size?
- I am a bit lost with MAX_CHANNELS and MAX_CHAN_DEVICES... Which are
the differences between both?
- As MAX_CHANNELS and MAX_CHAN_DEVICES should not be set by defines, I
am going to alloc memory for chan_devices... I am going to do it in
init_one... Is it OK?.

My first intention for all this is to set HSS into MVIP mode and have
4 HDLC channels in a packetized mode.
- How could I set this MVIP mode?
- How could I interface with generic HDLC so that hss_hdlc_xmit sends
the data for each stream to a different FIFO?

Thanks

Miguel Ángel Álvarez

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

> +++ linux-2.6.26.7/drivers/net/wan/ixp4xx_hss.c	2008-11-24

> +struct physical_modes {
> +	u8 id;
> +	unsigned int frame_size;
> +	unsigned int clock_rate;
> +	u32 clock_config;
> +};

I think the clock rate shouldn't be a part of the fixed port config.
I don't know much about 4E1 configs, but in the usual case (single
physical port connected directly to the HSS) you can use many clock
and frame size configurations.

IOW I think physical mode = only signal/timeslot routing topology.
The platform code could also optionally check if the specified clock
type and rate is valid.

> +static const struct physical_modes phmodes[] = {
> +	{IXP4XX_HSS_T1, 193, 1544000, CLK42X_SPEED_1544KHZ},
> +	{IXP4XX_HSS_E1, 256, 2048000, CLK42X_SPEED_2048KHZ},
> +	{IXP4XX_HSS_2_E1, 512, 4096000, CLK42X_SPEED_4096KHZ},
> +	{IXP4XX_HSS_4_E1, 1024, 8192000, CLK42X_SPEED_8192KHZ},
> +	{0, 256, 2048000, CLK42X_SPEED_2048KHZ}
> +};

If we need different internal clock rates (most framers/multiplexers
provide their own, don't they?) then I guess we need to calculate the
required settings ourselves. I don't exactly know how do they
calculate the register but it should be easy to find out. There was no
need yet.

> +#define IXP4XX_HSS_T1     0x10
> +#define IXP4XX_HSS_E1     0x11

T1 and E1 are the same WRT hardware connection to the port.

> - How should all these changes interact with show_frame_size and
> set_frame_size?

Perhaps the platform code should initialize the value and then check
changes for validity. Only matters with G.704 framers I think.
Otherwise the user should be able to select anything.

> - I am a bit lost with MAX_CHANNELS and MAX_CHAN_DEVICES... Which are
> the differences between both?

MAX_CHANNELS = (currenly) 32 = max for single channel (32 E1
channels).
MAX_CHAN_DEVICES = limit of /dev/hssXchY nodes (for one port).

> - As MAX_CHANNELS and MAX_CHAN_DEVICES should not be set by defines, I
> am going to alloc memory for chan_devices... I am going to do it in
> init_one... Is it OK?.

MAX_CHANNELS, I think so.
MAX_CHAN_DEVICES isn't directly related.

> My first intention for all this is to set HSS into MVIP mode and have
> 4 HDLC channels in a packetized mode.
> - How could I set this MVIP mode?
> - How could I interface with generic HDLC so that hss_hdlc_xmit sends
> the data for each stream to a different FIFO?

The HSS driver should initialize MVIP based on platform's
physical_config value, then it would have to register 4 HDLC devices.

The HDLC part (not the channelized one) should be quite trivial.
I think we now need the HSS HDLC driver upstream, will look at this.
-- 
Krzysztof Halasa

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi

2008/11/24 Krzysztof Halasa <khc@pm.waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:
>
>> +++ linux-2.6.26.7/drivers/net/wan/ixp4xx_hss.c       2008-11-24
>
>> +struct physical_modes {
>> +     u8 id;
>> +     unsigned int frame_size;
>> +     unsigned int clock_rate;
>> +     u32 clock_config;
>> +};
>
> I think the clock rate shouldn't be a part of the fixed port config.
> I don't know much about 4E1 configs, but in the usual case (single
> physical port connected directly to the HSS) you can use many clock
> and frame size configurations.
>
I am not quite sure about this. If we do not set the clock_rate as
part of the "physical_mode"... where should it be set? As a separate
variable? I do not have problems with that neither.

> IOW I think physical mode = only signal/timeslot routing topology.
> The platform code could also optionally check if the specified clock
> type and rate is valid.
>
Is this what you are stating? a separate variable for clock_rate in
the platform structure?

>> +static const struct physical_modes phmodes[] = {
>> +     {IXP4XX_HSS_T1, 193, 1544000, CLK42X_SPEED_1544KHZ},
>> +     {IXP4XX_HSS_E1, 256, 2048000, CLK42X_SPEED_2048KHZ},
>> +     {IXP4XX_HSS_2_E1, 512, 4096000, CLK42X_SPEED_4096KHZ},
>> +     {IXP4XX_HSS_4_E1, 1024, 8192000, CLK42X_SPEED_8192KHZ},
>> +     {0, 256, 2048000, CLK42X_SPEED_2048KHZ}
>> +};
>
> If we need different internal clock rates (most framers/multiplexers
> provide their own, don't they?) then I guess we need to calculate the
> required settings ourselves. I don't exactly know how do they
> calculate the register but it should be easy to find out. There was no
> need yet.
>
I agree... I think the precalculated values are enough for now.

>> +#define IXP4XX_HSS_T1     0x10
>> +#define IXP4XX_HSS_E1     0x11
>
> T1 and E1 are the same WRT hardware connection to the port.
>
I have done the difference for the clock_rates and the needing of a
framing bit in the case of T1.

>> - How should all these changes interact with show_frame_size and
>> set_frame_size?
>
> Perhaps the platform code should initialize the value and then check
> changes for validity. Only matters with G.704 framers I think.
> Otherwise the user should be able to select anything.
>
Yes... but the dynamic allocation makes it more difficult.

>> - I am a bit lost with MAX_CHANNELS and MAX_CHAN_DEVICES... Which are
>> the differences between both?
>
> MAX_CHANNELS = (currenly) 32 = max for single channel (32 E1
> channels).
> MAX_CHAN_DEVICES = limit of /dev/hssXchY nodes (for one port).
>
OK. Thanks... However... shouldn't they be the same value... I mean...
It could be possible to have a device for each channel in the frame,
not? So, for example if I had 128 channels (4*E1), it could be
required to deal with 128 devices, not? (In channelized mode).

>> - As MAX_CHANNELS and MAX_CHAN_DEVICES should not be set by defines, I
>> am going to alloc memory for chan_devices... I am going to do it in
>> init_one... Is it OK?.
>
> MAX_CHANNELS, I think so.
> MAX_CHAN_DEVICES isn't directly related.
>
I do not understand why are not they directly related.

>> My first intention for all this is to set HSS into MVIP mode and have
>> 4 HDLC channels in a packetized mode.
>> - How could I set this MVIP mode?
>> - How could I interface with generic HDLC so that hss_hdlc_xmit sends
>> the data for each stream to a different FIFO?
>
> The HSS driver should initialize MVIP based on platform's
> physical_config value, then it would have to register 4 HDLC devices.
>
Sure... Let me re-do the question. Do you know how MVIP is set if I
detect it is needed? And... good idea with the registering of four
devices.

> The HDLC part (not the channelized one) should be quite trivial.
> I think we now need the HSS HDLC driver upstream, will look at this.
> --
Sorry... I have not understood this.

Miguel Ángel

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

> I am not quite sure about this. If we do not set the clock_rate as
> part of the "physical_mode"... where should it be set? As a separate
> variable?

I think so. In most cases the external clock will be used anyway.

> Is this what you are stating? a separate variable for clock_rate in
> the platform structure?
>
>>> +static const struct physical_modes phmodes[] = {
>>> +     {IXP4XX_HSS_T1, 193, 1544000, CLK42X_SPEED_1544KHZ},
>>> +     {IXP4XX_HSS_E1, 256, 2048000, CLK42X_SPEED_2048KHZ},
>>> +     {IXP4XX_HSS_2_E1, 512, 4096000, CLK42X_SPEED_4096KHZ},
>>> +     {IXP4XX_HSS_4_E1, 1024, 8192000, CLK42X_SPEED_8192KHZ},
>>> +     {0, 256, 2048000, CLK42X_SPEED_2048KHZ}
>>> +};

No. The HSS driver already has code for the clock rate. Unfortunately
it doesn't yet know how to set the register.

There is IMHO one thing missing from the platform struct: the
physical mode, aka topology; a single integer. Possible values:
a) direct connection to HSS, b) HSS connected to a 4 * E1 MVIP framer,
c) 4 * T1 MVIP, d+) other similar variants (perhaps 2 * E1, 2 * T1).

>> T1 and E1 are the same WRT hardware connection to the port.
>>
> I have done the difference for the clock_rates and the needing of a
> framing bit in the case of T1.

Sure, but: clock rate is independent anyway, and the framing bit can be
requested by using 193 bits of frame (IIRC this is how the code
currently works but I'd have to check for sure).

> OK. Thanks... However... shouldn't they be the same value... I mean...
> It could be possible to have a device for each channel in the frame,
> not? So, for example if I had 128 channels (4*E1), it could be
> required to deal with 128 devices, not? (In channelized mode).

Sure (though I don't know how efficient would that be).

The truth is the HSS channelized code is quite experimental. It works,
and I actually use it, but I haven't yet decided about the API and
this is why it isn't still upstream.

HDLC HSS code is IMHO stable and could be submitted upstream, I will
do it sometime.

> Sure... Let me re-do the question. Do you know how MVIP is set if I
> detect it is needed? And... good idea with the registering of four
> devices.

The platform code should provide the "mode" (aka topology) = "4 * E1".
There is nothing to detect. The driver has to handle 4E1, that's all.
-- 
Krzysztof Halasa

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi

2008/11/25 Krzysztof Halasa <khc@pm.waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:
>
>> I am not quite sure about this. If we do not set the clock_rate as
>> part of the "physical_mode"... where should it be set? As a separate
>> variable?
>
> I think so. In most cases the external clock will be used anyway.
>
OK.

> The truth is the HSS channelized code is quite experimental. It works,
> and I actually use it, but I haven't yet decided about the API and
> this is why it isn't still upstream.
>
I understand.

>> Sure... Let me re-do the question. Do you know how MVIP is set if I
>> detect it is needed? And... good idea with the registering of four
>> devices.
>
> The platform code should provide the "mode" (aka topology) = "4 * E1".
> There is nothing to detect. The driver has to handle 4E1, that's all.
>
I think I do not make me understand myself... The question is: Do you
know which message should I send to the NPE to configure it for MVIP
mode?

I have another question though... It is very basic, but I am mixing things...
- If you have just one source of data, you can use packetized mode
(and it does not care which clock rate you are using...).
- If you have more than one sources of data and are working (for
example) with an E1, you create a channel for each source, and the
driver manages it.
- But... If I want four sources of unstructured data (one for each
"E1" in a 4E1), must I use a channelized mode, or a packetized mode?

Thanks

Miguel Ángel

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

> I think I do not make me understand myself... The question is: Do you
> know which message should I send to the NPE to configure it for MVIP
> mode?

You mean the low-level messages to NPE-A?

First you need to set the frame length (max is 1024 bits)
and fill the LUT (the slot mapping table) correctly (max 128 slots).

If I understand and remember this correctly, for HDLC you need to send
PKT_NUM_PIPES_WRITE = 4 (or 2 for 2E1), and I think
PKT_PIPE_FIFO_SIZEW_WRITE must be reduced (to 1 for 4 HDLC pipes and
2 for 2 pipes?).

For channelized mode you need CHAN_NUM_CHANS_WRITE (0 - 128, number of
active channels only).

Basically MVIP divides your entire frame into 2 or 4 parts.

> - If you have just one source of data, you can use packetized mode
> (and it does not care which clock rate you are using...).
> - If you have more than one sources of data and are working (for
> example) with an E1, you create a channel for each source, and the
> driver manages it.
> - But... If I want four sources of unstructured data (one for each
> "E1" in a 4E1), must I use a channelized mode, or a packetized mode?

These are unrelated.

a) all four E1s in 4E1 are completely independent. Their packetized
streams are, thus, independent as well. You may think about them as of
four (almost) separate physical interfaces. I think the NPE can do a
single HDLC stream over a 1024-bit frame, but this isn't technically
MVIP, it's a single logical interface with data rate up to 8 Mb/s.

b) packetized mode is mostly for HDLC. You need it if you want to have
Frame-Relay, X.25, Cisco HDLC, synchronous PPP etc. over some
channels (timeslots) (partial E1/T1 etc) or over the full frame (all
channels). The chip has only one HDLC controller per logical interface
(E1 etc) so you can only have one HDLC stream per (member of MVIP) E1.

If you need multiple streams of packets (per logical interface), you
can use Frame-Relay with multiple PVCs, or, for example,
Ethernet-alike VLANs.

c) Channelized mode is for bit-transparent data - mainly voice
communications (circuit-switched, e.g. ISDN with 64 kb/s per channel),
or when you don't care what's being transmitted because you are only
forwarding the traffic (and not terminating it with e.g. HDLC).



You can have both channelized and packetized timeslots on your
interfaces (logical and physical). For purely packetized data ("full"
physical interface used by a single HDLC stream) you don't even need a
framer, because you don't care when the frame starts, or if there is
frame at all. Otherwise, you need a framer (for a single E1/(T1) there
is an experimental software framer, for MVIP you need a hardware
chip).


The clock is yet another thing independent of the above. If you
connect a DCE to the HSS, the DCE will usually provide the clock. The
(hardware) framers and/or E1/T1 transceivers will do as well.
The internal clock is usually needed when the HSS acts as DCE itself,
usually when you connect two similar devices together (two DTEs).
That's why it's currently fixed at 2 Mb/s, it's mostly for tests.
-- 
Krzysztof Halasa

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Hi, and thanks a lot for all your help.

2008/11/26 Krzysztof Halasa <khc@pm.waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:
>
>> I think I do not make me understand myself... The question is: Do you
>> know which message should I send to the NPE to configure it for MVIP
>> mode?
>
> You mean the low-level messages to NPE-A?
>
Yes... That is one of the main problems... I do not find the
information about the low-level so I am not sure of what must I change
in your driver to fit my needs.

> First you need to set the frame length (max is 1024 bits)
> and fill the LUT (the slot mapping table) correctly (max 128 slots).
>
> If I understand and remember this correctly, for HDLC you need to send
> PKT_NUM_PIPES_WRITE = 4 (or 2 for 2E1), and I think
> PKT_PIPE_FIFO_SIZEW_WRITE must be reduced (to 1 for 4 HDLC pipes and
> 2 for 2 pipes?).
>
Yes... I think all these values are correct.

> For channelized mode you need CHAN_NUM_CHANS_WRITE (0 - 128, number of
> active channels only).
>
Not my case.

> Basically MVIP divides your entire frame into 2 or 4 parts.
>
Sure. But... It is automatically activated when the frame length is
greater than 256 or should it be explicitelly set?

>> - If you have just one source of data, you can use packetized mode
>> (and it does not care which clock rate you are using...).
>> - If you have more than one sources of data and are working (for
>> example) with an E1, you create a channel for each source, and the
>> driver manages it.
>> - But... If I want four sources of unstructured data (one for each
>> "E1" in a 4E1), must I use a channelized mode, or a packetized mode?
>
> These are unrelated.
>
You are true... I was being quite simplistic again.

> a) all four E1s in 4E1 are completely independent. Their packetized
> streams are, thus, independent as well. You may think about them as of
> four (almost) separate physical interfaces. I think the NPE can do a
> single HDLC stream over a 1024-bit frame, but this isn't technically
> MVIP, it's a single logical interface with data rate up to 8 Mb/s.
>
OK... I understand the concept, but I am not sure about how this is
integrated with your driver (or the NPE). I mean... When I use your
driver, I obtain two interfaces hdlc0 and hdlc1 (one per HSS). If I
had only a packetized stream, I could open a socket to the interface
and send the data. No problem (I think) in it.
But if I want to have four streams (one per E1), is your driver
prepare to deal with this, or should I manage to create four
interfaces per HSS?
In the first case... Is it related with set_hdlc_chan function? The
name could suggest this, but then it does nothing for MODE_HDLC but
MODE_RAW and MODE_G704.
In the second case... I understand that if I have to add the new
interfaces, they should be network interfaces. Where do you recommend
me to do it?
In both cases... How can the user direct his data to one E1 or the other?

> b) packetized mode is mostly for HDLC. You need it if you want to have
> Frame-Relay, X.25, Cisco HDLC, synchronous PPP etc. over some
> channels (timeslots) (partial E1/T1 etc) or over the full frame (all
> channels). The chip has only one HDLC controller per logical interface
> (E1 etc) so you can only have one HDLC stream per (member of MVIP) E1.
>
> If you need multiple streams of packets (per logical interface), you
> can use Frame-Relay with multiple PVCs, or, for example,
> Ethernet-alike VLANs.
>
In my case (bad luck...) we have a legacy mode of connection, so I
cannot use any of the methods described. I "just" need something
similar to the IxHssAccPktPortConnection in the Intel Software
Library... (I rather prefer to use your library by far... but this is
a point I understand in their library but not quite sure of how to use
it in yours).

> c) Channelized mode is for bit-transparent data - mainly voice
> communications (circuit-switched, e.g. ISDN with 64 kb/s per channel),
> or when you don't care what's being transmitted because you are only
> forwarding the traffic (and not terminating it with e.g. HDLC).
>
I agree.
>
> You can have both channelized and packetized timeslots on your
> interfaces (logical and physical). For purely packetized data ("full"
> physical interface used by a single HDLC stream) you don't even need a
> framer, because you don't care when the frame starts, or if there is
> frame at all. Otherwise, you need a framer (for a single E1/(T1) there
> is an experimental software framer, for MVIP you need a hardware
> chip).
>
We have one framer, thanks.

>
> The clock is yet another thing independent of the above. If you
> connect a DCE to the HSS, the DCE will usually provide the clock. The
> (hardware) framers and/or E1/T1 transceivers will do as well.
> The internal clock is usually needed when the HSS acts as DCE itself,
> usually when you connect two similar devices together (two DTEs).
> That's why it's currently fixed at 2 Mb/s, it's mostly for tests.

We are in that case... (more or less...), so we should act on the
clock. (No problem in that...)

Miguel Ángel

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

>> Basically MVIP divides your entire frame into 2 or 4 parts.
>>
> Sure. But... It is automatically activated when the frame length is
> greater than 256 or should it be explicitelly set?

You must set the number of (packetized) pipes.
For channelized data, there is apparently no difference.

> OK... I understand the concept, but I am not sure about how this is
> integrated with your driver (or the NPE). I mean... When I use your
> driver, I obtain two interfaces hdlc0 and hdlc1 (one per HSS). If I
> had only a packetized stream, I could open a socket to the interface
> and send the data. No problem (I think) in it.
> But if I want to have four streams (one per E1), is your driver
> prepare to deal with this, or should I manage to create four
> interfaces per HSS?

The driver is currently missing the MVIP code.

> In the first case... Is it related with set_hdlc_chan function? The
> name could suggest this, but then it does nothing for MODE_HDLC but
> MODE_RAW and MODE_G704.

That's for channelized data.

> In the second case... I understand that if I have to add the new
> interfaces, they should be network interfaces. Where do you recommend
> me to do it?

I'd have to look at it.

> In both cases... How can the user direct his data to one E1 or the other?

Each "member" E1 is connected to its respective HDLC controller
("packetized pipe"), and these have "TX" and "RX-free" queues (one set
per each HDLC).

> In my case (bad luck...) we have a legacy mode of connection, so I
> cannot use any of the methods described. I "just" need something
> similar to the IxHssAccPktPortConnection in the Intel Software
> Library...

Sure, you can use this raw HDLC + packet interface. One stream per
(member) E1/T1 (or, to be precise, one stream per 1, 1/2 or 1/4 of the
physical interface).
-- 
Krzysztof Halasa

Re: ixp4xx_hss MAX_CHAN_DEVICES

[Miguel Ángel Álvarez]

Again... thanks a lot for your answers.

2008/11/26 Krzysztof Halasa <khc@pm.waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:
>
>>> Basically MVIP divides your entire frame into 2 or 4 parts.
>>>
>> Sure. But... It is automatically activated when the frame length is
>> greater than 256 or should it be explicitelly set?
>
> You must set the number of (packetized) pipes.
> For channelized data, there is apparently no difference.
>
No problem in this.

>> OK... I understand the concept, but I am not sure about how this is
>> integrated with your driver (or the NPE). I mean... When I use your
>> driver, I obtain two interfaces hdlc0 and hdlc1 (one per HSS). If I
>> had only a packetized stream, I could open a socket to the interface
>> and send the data. No problem (I think) in it.
>> But if I want to have four streams (one per E1), is your driver
>> prepare to deal with this, or should I manage to create four
>> interfaces per HSS?
>
> The driver is currently missing the MVIP code.
>
That is what I supposed.

>> In the first case... Is it related with set_hdlc_chan function? The
>> name could suggest this, but then it does nothing for MODE_HDLC but
>> MODE_RAW and MODE_G704.
>
> That's for channelized data.
>
OK.

>> In the second case... I understand that if I have to add the new
>> interfaces, they should be network interfaces. Where do you recommend
>> me to do it?
>
> I'd have to look at it.
>
OK, thanks. If we add an HSS id in the platform driver, I think we
could create up to 4 hdlc interfaces for each HSS. As all of them are
independent, all your code could be useful for each one. The main
question would be then how to map each one with the correct FIFO, not?
(What does txreadyq represent? How are their values chosen?)

>> In both cases... How can the user direct his data to one E1 or the other?
>
> Each "member" E1 is connected to its respective HDLC controller
> ("packetized pipe"), and these have "TX" and "RX-free" queues (one set
> per each HDLC).
>
Sure... I suppose I have to modify queue_ids to use the correct queues
for tx and rx values. What should I do for txdone, rxfree and chan
values?

>> In my case (bad luck...) we have a legacy mode of connection, so I
>> cannot use any of the methods described. I "just" need something
>> similar to the IxHssAccPktPortConnection in the Intel Software
>> Library...
>
> Sure, you can use this raw HDLC + packet interface. One stream per
> (member) E1/T1 (or, to be precise, one stream per 1, 1/2 or 1/4 of the
> physical interface).
>
Yes... I think this raw HDLC (although we are talking of raw HDLC we
are refering to MODE_HDLC with "sethdlc hdlc0 hdlc" and not MODE_RAW,
not?) is the answer if I found a way to create and interconnect
correctly 4*2 interfaces (hdlc0-hdlc7?).

Thanks a lot

Miguel Ángel