23 Jul, 2012

1 commit


18 Jun, 2012

1 commit

  • Devices with register paging or indirectly accessed registers can configure
    register mapping to map those on virtual address range. During access to
    virtually mapped register range, indirect addressing is processed
    automatically, in following steps:
    1. selector for page or indirect register is updated (when needed);
    2. register in data window is accessed.

    Configuration should provide minimum and maximum register for virtual range,
    details of selector field for page selection, minimum and maximum register of
    data window for indirect access.

    Virtual range registers are managed by cache as well as direct access
    registers. In order to make indirect access more efficient, selector register
    should be declared as non-volatile, if possible.

    struct regmap_config is extended with the following:
    struct regmap_range_cfg *ranges;
    unsigned int n_ranges;

    [Also reordered debugfs init to later on since the cleanup code was
    conflicting with the new cleanup code for ranges anyway -- broonie]

    Signed-off-by: Krystian Garbaciak
    Signed-off-by: Mark Brown

    Krystian Garbaciak
     

13 Jun, 2012

1 commit


05 Jun, 2012

1 commit


03 Jun, 2012

2 commits


15 May, 2012

1 commit


14 May, 2012

2 commits


09 May, 2012

1 commit

  • Use devres to implement dev_get_regmap(). This should mean that in almost
    all cases devices wishing to take advantage of framework features based on
    regmap shouldn't need to explicitly pass the regmap into the framework.
    This simplifies device setup a bit.

    Signed-off-by: Mark Brown

    Mark Brown
     

01 May, 2012

1 commit


10 Apr, 2012

3 commits

  • regmap_config.reg_stride is introduced. All extant register addresses
    are a multiple of this value. Users of serial-oriented regmap busses will
    typically set this to 1. Users of the MMIO regmap bus will typically set
    this based on the value size of their registers, in bytes, so 4 for a
    32-bit register.

    Throughout the regmap code, actual register addresses are used. Wherever
    the register address is used to index some array of values, the address
    is divided by the stride to determine the index, or vice-versa. Error-
    checking is added to all entry-points for register address data to ensure
    that register addresses actually satisfy the specified stride. The MMIO
    bus ensures that the specified stride is large enough for the register
    size.

    Signed-off-by: Stephen Warren
    Signed-off-by: Mark Brown

    Stephen Warren
     
  • Mark Brown
     
  • Some devices have multiple separate register regions. Logically, one
    regmap would be created per region. One issue that prevents this is that
    each instance will attempt to create the same debugfs files. Avoid this
    by allowing regmaps to be named, and use the name to construct the
    debugfs directory name.

    Signed-off-by: Stephen Warren
    Signed-off-by: Mark Brown

    Stephen Warren
     

06 Apr, 2012

3 commits

  • This is a basic memory-mapped-IO bus for regmap. It has the following
    features and limitations:

    * Registers themselves may be 8, 16, 32, or 64-bit. 64-bit is only
    supported on 64-bit platforms.
    * Register offsets are limited to precisely 32-bit.
    * IO is performed using readl/writel, with no provision for using the
    __raw_readl or readl_relaxed variants.

    Signed-off-by: Stephen Warren
    Signed-off-by: Mark Brown

    Stephen Warren
     
  • Some bus types have very fast IO. For these, acquiring a mutex for every
    IO operation is a significant overhead. Allow busses to indicate their IO
    is fast, and enhance regmap to use a spinlock for those busses.

    [Currently limited to native endian registers -- broonie]

    Signed-off-by: Stephen Warren
    Signed-off-by: Mark Brown

    Stephen Warren
     
  • The only context needed by I2C and SPI bus definitions is the device
    itself; this can be converted to an i2c_client or spi_device in order
    to perform IO on the device. However, other bus types may need more
    context in order to perform IO. Enable this by having regmap_init accept
    a bus_context parameter, and pass this to all bus callbacks. The
    existing callbacks simply pass the struct device here. Future bus types
    may pass something else.

    Signed-off-by: Stephen Warren
    Signed-off-by: Mark Brown

    Stephen Warren
     

25 Mar, 2012

1 commit

  • Pull avoidance patches from Paul Gortmaker:
    "Nearly every subsystem has some kind of header with a proto like:

    void foo(struct device *dev);

    and yet there is no reason for most of these guys to care about the
    sub fields within the device struct. This allows us to significantly
    reduce the scope of headers including headers. For this instance, a
    reduction of about 40% is achieved by replacing the include with the
    simple fact that the device is some kind of a struct.

    Unlike the much larger module.h cleanup, this one is simply two
    commits. One to fix the implicit users, and then one
    to delete the device.h includes from the linux/include/ dir wherever
    possible."

    * tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    device.h: audit and cleanup users in main include dir
    device.h: cleanup users outside of linux/include (C files)

    Linus Torvalds
     

16 Mar, 2012

1 commit

  • The header includes a lot of stuff, and
    it in turn gets a lot of use just for the basic "struct device"
    which appears so often.

    Clean up the users as follows:

    1) For those headers only needing "struct device" as a pointer
    in fcn args, replace the include with exactly that.

    2) For headers not really using anything from device.h, simply
    delete the include altogether.

    3) For headers relying on getting device.h implicitly before
    being included themselves, now explicitly include device.h

    4) For files in which doing #1 or #2 uncovers an implicit
    dependency on some other header, fix by explicitly adding
    the required header(s).

    Any C files that were implicitly relying on device.h to be
    present have already been dealt with in advance.

    Total removals from #1 and #2: 51. Total additions coming
    from #3: 9. Total other implicit dependencies from #4: 7.

    As of 3.3-rc1, there were 110, so a net removal of 42 gives
    about a 38% reduction in device.h presence in include/*

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

14 Mar, 2012

5 commits


11 Mar, 2012

1 commit


01 Mar, 2012

1 commit


24 Feb, 2012

1 commit

  • Provide a regcache_sync_region() operation which allows drivers to
    write only part of the cache back to the hardware. This is intended
    for use in cases like power domains or DSP memories where part of the
    device register map may be reset without fully resetting the device.

    Fully supporting these devices is likely to require additional work to
    make specific regions of the register map cache only while they are in
    reset, but this is enough for most devices.

    Signed-off-by: Mark Brown

    Mark Brown
     

21 Feb, 2012

2 commits


18 Feb, 2012

1 commit

  • Make life easier for subsystems which build infrastructure on top of the
    regmap API by providing stub definitions for most of the API so that users
    can at least build even if the regmap API is not enabled without having to
    add ifdefs if they don't want to.

    These stubs are not expected to be useful and should never actually get
    called, they just exist so that we can link so there are WARN_ONCE()s in
    the stubs.

    Signed-off-by: Mark Brown

    Mark Brown
     

15 Feb, 2012

1 commit

  • The bulk_write() supports the data transfer to multi
    register which takes the data into cpu_endianness format
    and does formatting of data to device format before
    sending to device.
    The transfer can be completed in single transfer or multiple
    transfer based on data formatting.

    Signed-off-by: Laxman Dewangan
    Signed-off-by: Mark Brown

    Laxman Dewangan
     

31 Jan, 2012

1 commit


23 Jan, 2012

1 commit

  • Device manufacturers frequently provide register sequences, usually not
    fully documented, to be run at startup in order to provide better defaults
    for devices (for example, improving performance in the light of silicon
    evaluation). Support such updates by allowing drivers to register update
    sets with the core. These updates will be written to the device immediately
    and will also be rewritten when the cache is synced.

    The assumption is that the reason for resyncing the cache will always be
    that the device has been powered off. If this turns out to not be the case
    then a separate operation can be provided.

    Currently the implementation only allows a single set of updates to be
    specified for a device, this could be extended in future.

    Signed-off-by: Mark Brown

    Mark Brown
     

20 Jan, 2012

1 commit


06 Dec, 2011

2 commits


05 Dec, 2011

2 commits


30 Nov, 2011

1 commit

  • Some users of regmap_update_bits() would like to be able to tell their
    users if they actually did an update so provide a variant which also
    returns a flag indicating if an update took place. We could return a
    tristate in the return value of regmap_update_bits() but this makes the
    API more cumbersome to use and doesn't fit with the general zero for
    success idiom we have.

    Signed-off-by: Mark Brown

    Mark Brown
     

21 Nov, 2011

1 commit