lkml.org 
[lkml]   [2012]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code
    On Thu, Oct 25, 2012 at 03:26:02PM -0700, Andrey Smirnov wrote:
    > On 10/25/2012 12:45 PM, Mark Brown wrote:

    > > This really makes little sense to me, why are you doing this? Does the
    > > device *really* layer a byte stream on top of I2C for sending messages
    > > that look like marshalled register reads and writes?

    > The SI476x chips has a concept of a "property". Each property having
    > 16-bit address and 16-bit value. At least a portion of a chip
    > configuration is done by modifying those properties. In order to

    Right, that's what I remembered from previous code. There's no way this
    should be a regmap bus - a bus is something that gets data serialised by
    the core into a byte stream, having the data rendered down into a byte
    stream and then reparsing it is a bit silly. The device should be
    hooking in before the data gets marshalled which we can't currently do
    but it shouldn't be too hard to make it so that we can have register
    read and write functions supplied in the regmap config.

    > Also due to the way the driver uses the chip it is only powered up when
    > the corresponding file in devfs(e.g. /dev/radio0) is opened at least by
    > one user which means that unless there is a user who opened the file all
    > the SET/GET_PROPERTY commands sent to it will be lost. The codec driver
    > for that chip does not have any say in the power management policy(while
    > all the audio configuration is done via "properties") if the chip is not
    > powered up the driver has to cache the configuration values it has so
    > that they can be applied later.

    This is very normal, indeed modern CODEC drivers can leave the chip
    powered down whenever it's not performing some function.

    > So, since I have to implement a caching functionality in the driver, in
    > order to avoid reinventing the wheel I opted for using 'regmap' API for
    > this.

    > Of course, It is possible that I misunderstood the purpose and
    > capabilities of the 'regmap' framework, which would make my code look
    > very silly indeed. If that is the case I'll just re-implement it using
    > some sort of ad-hoc version of caching.

    No, what you're doing is totally sensible. It needs a bit of extension
    to the framework before you can do it though.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2012-10-28 00:21    [W:3.188 / U:1.580 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site