Driver for tightly coupled memory

Driver for tightly coupled memory

[Alessio Sangalli]

Hi, the platform I am working on right now (ARM) has a so called 'TCM'
(tightly coupled memory) that is some 8 to 32kB of SRAM in the chip, no
waitstates, very high bandwidth, and it is possible to access it *while*
accessing main memory. It may be a very good thing (for example) to
implement a software FIFO to be used in ISRs or such.

Do you know of any implementation of such software FIFO or any other
kernel driver for TCMs?

bye
Alessio

Re: Driver for tightly coupled memory

[Ben Dooks]

On Mon, Sep 15, 2008 at 01:35:43PM -0700, Alessio Sangalli wrote:
> Hi, the platform I am working on right now (ARM) has a so called 'TCM'
> (tightly coupled memory) that is some 8 to 32kB of SRAM in the chip, no
> waitstates, very high bandwidth, and it is possible to access it *while*
> accessing main memory. It may be a very good thing (for example) to
> implement a software FIFO to be used in ISRs or such.

This isn't the right list to be discussing this on, try looking for
linux-arm-kernel instead. It will get your question to the attention
of more people knowledgable about the ARM specifics.

> Do you know of any implementation of such software FIFO or any other
> kernel driver for TCMs?

IIRC, there's no current support for using TCMs.
 
> bye
> Alessio
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: Driver for tightly coupled memory

[Alessio Sangalli]

Ben Dooks wrote:

> This isn't the right list to be discussing this on, try looking for
> linux-arm-kernel instead. It will get your question to the attention
> of more people knowledgable about the ARM specifics.

I disagree, something like a TCM can very well be present in any
architecture, after all it's some kind of fast memory mapped to an
address, nothing special from a software point of view. I will ask on
the ARM mailing list however.


> IIRC, there's no current support for using TCMs.

I think I will write a module that implements a software FIFO. One
function to allocate a FIFO n words deep, a "push" and a "pop" and
similar. The calling module will have to setup the FIFO and use it
probably in ISRs or similar (the policy will totally remain in the
caller module). Any comments on such approach?

bye
Alessio

Re: Driver for tightly coupled memory

[Ben Nizette]

On Tue, 2008-09-16 at 10:39 -0700, Alessio Sangalli wrote:
> Ben Dooks wrote:
> > IIRC, there's no current support for using TCMs.
> 
> I think I will write a module that implements a software FIFO. One
> function to allocate a FIFO n words deep, a "push" and a "pop" and
> similar. The calling module will have to setup the FIFO and use it
> probably in ISRs or similar (the policy will totally remain in the
> caller module). Any comments on such approach?

I'd feel uncomfortable about picking an arbitrary function for the TCM
to accomplish.  Why don't you just set up a genalloc on that RAM and let
the user use it for what they will?

If a driver needs a quick FIFO it can attempt to get the RAM for said
FIFO from the genalloc and fall back to main memory otherwise.  Simple,
flexible, easy :-)

	--Ben.

Re: Driver for tightly coupled memory

[Alessio Sangalli]

Ben Nizette wrote:

> If a driver needs a quick FIFO it can attempt to get the RAM for said
> FIFO from the genalloc and fall back to main memory otherwise.  Simple,
> flexible, easy :-)

Well, interesting, that is why I asked here before writing code.

In this case however, do you imply that a device driver will just do all
the genalloc stuff? In this case it has to know about the TCM details,
and problems may arise if more than one driver wants to use this
feature. Or, are you suggesting to write a small TCM driver that will do
the gen_pool_create() and gen_pool_add() and then export the struct
gen_pool for use by other drivers that may require it?

I mentioned implementing a FIFO because I already have a couple of
examples where this FIFO thing would be used.

Bye bye, thank you
Alessio

Re: Driver for tightly coupled memory

[Ben Nizette]

On Tue, 2008-09-16 at 15:49 -0700, Alessio Sangalli wrote:
> Ben Nizette wrote:
> 
> > If a driver needs a quick FIFO it can attempt to get the RAM for said
> > FIFO from the genalloc and fall back to main memory otherwise.  Simple,
> > flexible, easy :-)
> 
> Well, interesting, that is why I asked here before writing code.
> 
> In this case however, do you imply that a device driver will just do all
> the genalloc stuff? In this case it has to know about the TCM details,
> and problems may arise if more than one driver wants to use this
> feature. Or, are you suggesting to write a small TCM driver that will do
> the gen_pool_create() and gen_pool_add() and then export the struct
> gen_pool for use by other drivers that may require it?

Generally the genalloc pool will be set up exactly once, at boot, by the
platform code.  Then yes indeed the pool can be exported for driver use.

	--Ben.

Re: Driver for tightly coupled memory

[Alessio Sangalli]

Ben Nizette wrote:

> Generally the genalloc pool will be set up exactly once, at boot, by the
> platform code.  Then yes indeed the pool can be exported for driver use.


Oh thanks now it's clear.

bye
as

Re: Driver for tightly coupled memory

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On Tue, 16 Sep 2008 15:49:53 PDT, Alessio Sangalli said:

> In this case however, do you imply that a device driver will just do all
> the genalloc stuff? In this case it has to know about the TCM details,

What sort of hardware/software interface does the TCM provide?  You mentioned
that it could be accessed even while main memory is being accessed - what does
that look like from the software level?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Driver for tightly coupled memory

[Alessio Sangalli]

Valdis.Kletnieks@vt.edu wrote:

> What sort of hardware/software interface does the TCM provide?  You mentioned
> that it could be accessed even while main memory is being accessed - what does
> that look like from the software level?

Well I should ask the details to the hardware engineers but it's like a
separate channel than the one used for main memory. It is not cacheable
either. To the CPU, it just appears to be mapped at some location on the
addressable space. Accessing this TCM will not have any impact on main
memory access, so bursts etc won't be interrupted; other than that, TCM
has double the bandwidth than standard memory - but it's tiny in size,
something like 8 to 32kB as I mentioned earlier.

Hope I was clear enough, feel free to ask me more details if you need

bye
as

Re: Driver for tightly coupled memory

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Tue, 16 Sep 2008 22:27:41 PDT, Alessio Sangalli said:

> Well I should ask the details to the hardware engineers but it's like a
> separate channel than the one used for main memory. It is not cacheable
> either. To the CPU, it just appears to be mapped at some location on the
> addressable space. Accessing this TCM will not have any impact on main
> memory access, so bursts etc won't be interrupted; other than that, TCM
> has double the bandwidth than standard memory - but it's tiny in size,
> something like 8 to 32kB as I mentioned earlier.

Ah.  So it's basically just super-fast memory that can be accessed without
going through the usual memory bus.  Sounds like the cycle of reincarnation
strikes again - 30ish years ago, the DEC PDP10/20 processors implemented the
first few locations of memory in fast (for the time) chips, and then mapped
the general purpose registers onto it.  A favorite trick would be to copy a
small loop into locations 0-7 and then branch to it - basically executing
from the general registers.  The *real* fun started when people started doing
self-modifying code by doing arithmetic/logical operations on registers. ;)

Would it be more of a performance win to use the 8-32K to store speed-critical
code rather than a FIFO?  Just another idea for what to use it for, but that
would likely require a different API...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Driver for tightly coupled memory

[Alessio Sangalli]

Valdis.Kletnieks@vt.edu wrote:

> Would it be more of a performance win to use the 8-32K to store speed-critical
> code rather than a FIFO?  Just another idea for what to use it for, but that
> would likely require a different API...

Well... I have to check but I think the cache memory is anyway faster
than this, and this memory is not cacheable. But, you definitely have a
point. I'll check with some hardware guy tomorrow morning.

bye!
as