1. 15 3月, 2016 1 次提交
  2. 19 10月, 2015 1 次提交
  3. 18 10月, 2015 1 次提交
    • V
      misc: sram: extend usage of reserved partitions · b4c3fcb3
      Vladimir Zapolskiy 提交于
      This change adds functionality to operate on reserved SRAM partitions
      described in device tree file. Two partition properties are added,
      "pool" and "export", the first one allows to share a specific partition
      for usage by a kernel consumer in the same manner as it is done for
      the whole SRAM device, and "export" property provides access to some
      SRAM area from userspace over sysfs interface. Practically it is
      possible to specify both properties for an SRAM partition, however
      simultaneous access from a kernel consumer and from userspace is not
      serialized, but still the combination may be useful for debugging
      purpose.
      
      The change opens the following scenarios of SRAM usage:
      * updates in a particular SRAM area specified by offset and size are
        done by bootloader, then this information is utilized by the kernel,
      * a particular SRAM area is rw accessed from userspace, the stored
        data is persistent on soft reboots,
      * a device driver secures SRAM area for its purposes,
      * etc.
      
      Note, strictly speaking the added optional properties describe policy
      of SRAM usage, rather than hardware, but here the policy mostly
      resembles flash partitions in devicetree, which is undoubtedly
      a very popular option but it does not describe hardware.
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4c3fcb3
  4. 05 9月, 2015 1 次提交
    • V
      genalloc: add name arg to gen_pool_get() and devm_gen_pool_create() · 73858173
      Vladimir Zapolskiy 提交于
      This change modifies gen_pool_get() and devm_gen_pool_create() client
      interfaces adding one more argument "name" of a gen_pool object.
      
      Due to implementation gen_pool_get() is capable to retrieve only one
      gen_pool associated with a device even if multiple gen_pools are created,
      fortunately right at the moment it is sufficient for the clients, hence
      provide NULL as a valid argument on both producer devm_gen_pool_create()
      and consumer gen_pool_get() sides.
      
      Because only one created gen_pool per device is addressable, explicitly
      add a restriction to devm_gen_pool_create() to create only one gen_pool
      per device, this implies two possible error codes returned by the
      function, account it on client side (only misc/sram).  This completes
      client side changes related to genalloc updates.
      
      [akpm@linux-foundation.org: gen_pool_get() cleanup]
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      73858173
  5. 13 6月, 2015 7 次提交
  6. 17 3月, 2015 2 次提交
  7. 01 3月, 2014 1 次提交
  8. 08 2月, 2014 1 次提交
  9. 25 7月, 2013 1 次提交
  10. 18 6月, 2013 1 次提交
  11. 17 5月, 2013 1 次提交
  12. 30 4月, 2013 1 次提交
    • P
      misc: generic on-chip SRAM allocation driver · 4984c6f5
      Philipp Zabel 提交于
      This driver requests and remaps a memory region as configured in the
      device tree.  It serves memory from this region via the genalloc API.  It
      optionally enables the SRAM clock.
      
      Other drivers can retrieve the genalloc pool from a phandle pointing to
      this drivers' device node in the device tree.
      
      The allocation granularity is hard-coded to 32 bytes for now, to make the
      SRAM driver useful for the 6502 remoteproc driver.  There is overhead for
      bigger SRAMs, where only a much coarser allocation granularity is needed:
      At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap
      to track allocations.
      
      [akpm@linux-foundation.org: fix Kconfig text, make sram_init static]
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Tested-by: NMichal Simek <monstr@monstr.eu>
      Cc: Dong Aisheng <dong.aisheng@linaro.org>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Huang Shijie <shijie8@gmail.com>
      Cc: Javier Martin <javier.martin@vista-silicon.com>
      Cc: Matt Porter <mporter@ti.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4984c6f5