Lennert Buytenhek <[EMAIL PROTECTED]> writes:
> The way I see it, that means that you do want to scale back your
> other SRAM allocations if you know that you're going to need a lot
> of SRAM (say, for ethernet RX/TX queues.)
Yep, I will then add "queue_size" parameter to the platform data.
Or so
On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote:
> >> There may be up to 6 Ethernet ports (not sure about hardware
> >> status, not yet supported even by Intel) - 7 queues * 128 entries
> >> each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something
> >> for TX, and then crypto
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
> See for example arch/arm/mach-ep93xx/core.c, handling of the A/B/F
> port GPIO interrupts.
>
> In a nutshell, it goes like this.
Thanks, I will investigate.
>> There may be up to 6 Ethernet ports (not sure about hardware
>> status, not yet supporte
On Tue, May 08, 2007 at 04:12:17PM +0200, Krzysztof Halasa wrote:
> > The queue manager interrupts should probably be implemented as an
> > irqchip, in the same way that GPIO interrupts are implemented. (I.e.
> > allocate 'real' interrupt numbers for them, and use the interrupt
> > cascade mechan
Lennert Buytenhek <[EMAIL PROTECTED]> writes:
> The queue manager interrupts should probably be implemented as an
> irqchip, in the same way that GPIO interrupts are implemented. (I.e.
> allocate 'real' interrupt numbers for them, and use the interrupt
> cascade mechanism.) You probably want to
Michael-Luke Jones <[EMAIL PROTECTED]> writes:
> Already in mach-ixp4xx, so can just be called qmgr.c
Same here.
>> +#define QUEUE_IRQ_SRC_NEARLY_FULL 2
>> +#define QUEUE_IRQ_SRC_FULL 3
>> +#define QUEUE_IRQ_SRC_NOT_EMPTY 4
>> +#define QUEUE_IRQ_SRC_NOT_NEARLY_EMPTY 5
On Tue, May 08, 2007 at 04:47:31PM +0400, Alexey Zaytsev wrote:
> > As with Christian's driver, I don't know whether an SRAM allocator
> > makes much sense. We can just set up a static allocation map for the
> > in-tree drivers and leave out the allocator altogether. I.e. I don't
> > think it's
On 5/8/07, Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
...
As with Christian's driver, I don't know whether an SRAM allocator
makes much sense. We can just set up a static allocation map for the
in-tree drivers and leave out the allocator altogether. I.e. I don't
think it's worth the complexit
I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.
On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:
> +struct qmgr_regs __iomem *qmgr_regs;
> +static struct resource *mem_res;
> +static spinlock_t qmgr_lock;
> +stat
On 8 May 2007, at 01:46, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-
ixp4xx/ixp4xx_qmgr.c
new file mode 100644
index 000..b9
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 9715ef5..71ef55f 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -176,6 +176
11 matches
Mail list logo
