All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Miguel Ángel Álvarez" <gotzoncabanes@gmail.com>
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: ixp4xx_hss MAX_CHAN_DEVICES
Date: Mon, 24 Nov 2008 17:14:36 +0100	[thread overview]
Message-ID: <m3prkl14pf.fsf@maximus.localdomain> (raw)
In-Reply-To: <b0438a630811240415n6a1a0b23lf7ac37925d04a6b3@mail.gmail.com> ("Miguel Ángel Álvarez"'s message of "Mon\, 24 Nov 2008 13\:15\:54 +0100")

"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

  reply	other threads:[~2008-11-24 16:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 11:17 ixp4xx_hss MAX_CHAN_DEVICES Miguel Ángel Álvarez
2008-11-21 22:52 ` Krzysztof Halasa
2008-11-24 10:03   ` Miguel Ángel Álvarez
2008-11-24 12:15     ` Miguel Ángel Álvarez
2008-11-24 16:14       ` Krzysztof Halasa [this message]
2008-11-24 17:12         ` Miguel Ángel Álvarez
2008-11-24 23:52           ` Krzysztof Halasa
2008-11-25 16:51             ` Miguel Ángel Álvarez
2008-11-26  0:09               ` Krzysztof Halasa
2008-11-26 10:02                 ` Miguel Ángel Álvarez
2008-11-26 11:19                   ` Krzysztof Halasa
2008-11-26 12:08                     ` Miguel Ángel Álvarez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3prkl14pf.fsf@maximus.localdomain \
    --to=khc@pm.waw.pl \
    --cc=gotzoncabanes@gmail.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.