[lkml]   [2011]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC 5/8] remoteproc: add davinci implementation
    > From: Nori, Sekhar
    > Sent: Friday, June 24, 2011 8:44 AM
    > Hi Mark,

    Sekhar, thanks for your feedback and ideas. Comments below.


    > Since procedure to set the boot address varies across DaVinci
    > platforms, you could have a callback populated in platform data
    > which will be implemented differently for original DaVinci and
    > DA8xx devices.

    I looked at DM6467 and it's the same as OMAPL13x, except at a different
    address. Rather than a callback, it could be just an address in the
    platform data.

    > Also, all PSC accesses are better off going through clock
    > framework to ensure proper locking and modularity.
    > To assert/de-assert local reset when enabling or disabling PSC,
    > you could use a flag in the clock structure to indicate the need
    > for this. This way, if there is any other module needing a local
    > reset, it can just define the same flag. Similarly, if the DSP
    > does not need a local reset on a particular platform, that
    > platform can simply skip the flag.
    > This can be done in a manner similar to how the support for
    > a forced transition PSC was added here:

    Yes, I like this idea - much cleaner. For example, the start() method
    becomes (pseudo-code):

    /* bootaddrreg derived from platform data */
    bootaddrreg = boot_address;


    Referring to your patch above, would it be better to just pass
    the flags into the davinci_psc_config() function rather than breaking out more
    arguments for each flag?


     \ /
      Last update: 2011-06-27 20:35    [W:0.024 / U:0.564 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site