• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 551 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138 Linuxutils questions

Martin Ambrose
Intellectual 1510 points
Other Parts Discussed in Thread: OMAP-L138, OMAP-L137

Hello.

For reference here is the release notes page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/2_25_02_08/exports/linuxutils_2_25_02_08/linuxutils_2_25_02_08_ReleaseNotes.html

First question: For OMAP-L138, the notes mention the package was verified on ARM9 MV 5 Linux. I didn't know a MV5 linux package was available for the L138. Can someone confirm?

Second question:  The notes indicate that the edma package is only supported for the DM355 and DM365 devices. Will the L138 be supported in the future?

Regards,

Martin

 

  • 0
    TI__Intellectual 1510 points

    bumping since the thread was moved (to the same forum?) and resulted in a drop from the recent list.

    -Martin

  • 0
    TI__Mastermind 18260 points

    The validation section needs to be updated, it suffers bit-rot.

    Going by what we have installed here locally, there is an MV release for the DA830 (OMAP-L137) named LSP_02_20_00_07.tar.gz, but I don't see support for DA850 (OMAP-L138) there.

    As for the Linux Utils EDMA package, it is intended for non-DSP devices only.  DSP-based devices use the EDMA LLD (Low Level Driver) with DSP/BIOS to manage their EDMA resources.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    TI__Intellectual 1510 points

    Hi Rob,

    Thanks for the feedback.
    <blockquote>
    As for the Linux Utils EDMA package, it is intended for non-DSP devices only.  DSP-based devices use the EDMA LLD (Low Level Driver) with DSP/BIOS to manage their EDMA resources.     
    </blockquote> 
    What is then the recommended Linux user-space interface to QDMA channels?

    Regards,
    Martin 

  • 0 in reply to Martin Ambrose
    TI__Mastermind 18260 points

    Martin,

    I don't know of any user-space interface to QDMA (or any EDMA) channels.  QDMA usage would be encapsulated in a Linux device driver, and its usage by the device driver is generally hidden from the user.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    TI__Intellectual 1510 points

    Rob,

    Robert Tivy said:

    I don't know of any user-space interface to QDMA (or any EDMA) channels.  QDMA usage would be encapsulated in a Linux device driver, and its usage by the device driver is generally hidden from the user.

    That is my understanding as well. But if I end up needing such a user space interface I thought
    I could extend the current linuxutils package and push upstream. Rather than creating
    a separate package/code base.

    Regards,
    Martin 

  • 0 in reply to Martin Ambrose
    TI__Mastermind 18260 points

    I don't see anything that would prevent edmak.ko from being built for OMAP-L138, but I've never tried it.

    When you say "extend the current linuxutils package and push upstream", do you mean to the Davinci GIT?  We (TI) are eager to get Linux Utils kernel modules out of our camp and in to the mainline development, and any effort along those lines is encouraged.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    TI__Intellectual 1510 points

    Rob,

    Robert Tivy said:

    I don't see anything that would prevent edmak.ko from being built for OMAP-L138, but I've never tried it.

    I agree the structure is suitable just a question of the details (base address, config, etc.)

     

    Robert Tivy said:
    When you say "extend the current linuxutils package and push upstream", do you mean to the Davinci GIT?  We (TI) are eager to get Linux Utils kernel modules out of our camp and in to the mainline development, and any effort along those lines is encouraged.


    Actually I was thinking "upstream" here meant back to the TI team but can see this suitable for the community.
    At the moment our team is not sure this functionality is needed for our current project. If we do end up resourcing
    this work, then I'll talk with you and others about how to upstream. E.g. is there a similar architecture in place for other
    (non-TI) devices, and related, what is the appropriate subsystem mailing list the work should be published to. 

    Regards,
    Martin 

  • 0 in reply to Martin Ambrose
    TI__Mastermind 18260 points

    Martin,

    Pushing Linux Utils kernel modules to the Davinci mainline will certainly run into resistance from the kernel maintainers.  They would argue against the need for it altogether, and it would need to conform to Linux coding standards.  I'm not suggesting you fight that fight, just presenting a forecast.

    As for porting it to OMAP-L138, customers can do what they want with the Linux Utils source code, but to get TI to state official support for it would require a business justification for it on that platform, and I'm not sure that case can be made for OMAP-L138.

    Can you relate to me your team's use-case for it?

    Thanks & Regards,

    - Rob

  • 0 in reply to Robert Tivy
    TI__Intellectual 1510 points

    Rob,

    Robert Tivy said:
    Pushing Linux Utils kernel modules to the Davinci mainline will certainly run into resistance from the kernel maintainers.  They would argue against the need for it altogether, and it would need to conform to Linux coding standards.  I'm not suggesting you fight that fight, just presenting a forecast.

    Thanks for the heads up. I guess the community expectation is that DMA channels are not generally needed by user space applications.
    But I'm a bit surprised this level of generality hasn't been need prior. I'll have to do some more googling to determine the current community stance.

    Robert Tivy said:
     As for porting it to OMAP-L138, customers can do what they want with the Linux Utils source code, but to get TI to state official support for it would require a business justification for it on that platform, and I'm not sure that case can be made for OMAP-L138.

    Can you relate to me your team's use-case for it?

    .

    We're still yet determine the actual need. The customer has indicated that memory-to-memory copy
    acceleration would be needed/useful for efficient UI rendering. Yet to get benchmarks though...

    -Martin