Driver for tightly coupled memory - Kernel

This is a discussion on Driver for tightly coupled memory - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Driver for tightly coupled memory

  1. Driver for tightly coupled memory

    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

    --
    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/

  2. Re: Driver for tightly coupled memory

    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'
    --
    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/

  3. Re: Driver for tightly coupled memory

    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
    --
    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/

  4. Re: Driver for tightly coupled memory


    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.
    --
    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/

  5. Re: Driver for tightly coupled memory

    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


    --
    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/

  6. Re: Driver for tightly coupled memory


    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.
    --
    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/

  7. Re: Driver for tightly coupled memory

    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

    --
    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/

  8. Re: Driver for tightly coupled memory

    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?

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFI0G6OcC3lWbTT17ARAhptAKCOV5mp70Srgqm0lXuXQD u+e1kzGACfSl8E
    l25HSi9AaUOH9Lu8oG/mUcU=
    =3VeX
    -----END PGP SIGNATURE-----


  9. Re: Driver for tightly coupled memory

    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

    --
    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/

  10. Re: Driver for tightly coupled memory

    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...

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFI0JgacC3lWbTT17ARAhgQAKDd8Xt4X7g/QCoKYlev+AvTBFiCBwCeJEi0
    xpQH1wGOOEYXOdhy3dMwLiQ=
    =KjLG
    -----END PGP SIGNATURE-----


  11. Re: Driver for tightly coupled memory

    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

    --
    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/

+ Reply to Thread