• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 1138 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.

I2C Sharing between M3 and A8 cores?

Steven DuTemple
Intellectual 350 points

Hi,

We're in development of a product based on the DM8148 and for performance reasons have a software module running on the M3 core that accesses external devices on the I2C[0] interface. Several devices are attached to this interface, some of which are accessed by kernel drivers.

We're having a problem in that when the kernel-based drivers for the external devices are enabled we can no longer access the device used by the M3 core - we can see the external access being performed on the physical interface, but the M3 core does not receive the returned data. It turns out that *both* the M3 and A8 processes are receiving internal interrupts, causing the drivers to lock up and preventing the system from functioning as it should.

My question is the following: Is there a documented method for synchronizing access to the I2C modules between the internal cores of the DM8148? Is there a way to get the hardware to do this job, or does it need to be done via S/W semaphors/mutexes?

Any guidance would be appreciated - we haven't had much luck finding documentation about this functionality...

Cheers!

Steve Dutemple

H/W Designer / Matrox Graphics Inc.

  • 0
    TI__Mastermind 20245 points

    Hi,

    There are multiple I2C master busses on DM8148, I2C master drivers are not designed for multi core access like same master can be used from M3 as well as A8, instead what we have done on EVM  is that dedicating one I2C master per core, so on EVM, I2C0 is connected to slaves which requires control from A8, and I2C2 is connected t o slave which requires programming from M3 cores, you can also do same thing.

  • 0 in reply to HardikShah
    Guru 31670 points

    Steven,

    Are you very particular about sharing the bus between M3 and A8? You can get it done by writing some amount of code in either doing access protection, or by sharing the A8 driver from M3.

  • 0 in reply to HardikShah
    Intellectual 350 points

    Hardik,

    Thank you for your response - it certainly helps explain why we are seeing this issue in the first place. Our problem is we have several I2C devices and in a couple of cases require that the devices be alone on their bus. As a result, I2C[0] has ended up with 4 devices, one of which requires a high-performance driver, which is why the M3 core is being used for operations involving that particular device.

    Ideally, I was hoping for some mechanism that would allow me to effectively "share" the I2C module between the 2 cores without too much of an impact on performance. It may be possible for us to perform a hardware modification to re-assign the devices, but this is a more costly and time-consuming alternative.

    Thanks very much for your input. I appreciate the clarification.

    Regards,

    Steve Dutemple

  • 0 in reply to Renjith Thomas
    Intellectual 350 points

    Renjith,

    Thanks for your response. I find your suggestions intriguing.

    How does one go about "sharing" a driver between cores?

    Regards,

    Steve Dutemple

     

  • 0 in reply to Steven DuTemple
    Guru 31670 points

    Steve,

    You can get this done by writing a stub I2C driver in M3 and at Linux side write another wrapper over I2C driver. The stub i2c driver should call the methods in the Linux driver and perform the read/write. You need to use syslink to achieve this.

    There are other ways of also achieving this, without really writing a wrapper. You can have I2C driver at two places, but you should have an access control mechanism implemented using syslink or you can have a hardcoded access control mechanism as well. Both will require some changes in the I2C driver. 

    My point is that it is possible to do it theoretically. Since hardware modifications are expensive, this kind of workarounds/modifications also serve the purpose.