1. 04 6月, 2015 2 次提交
  2. 12 5月, 2015 3 次提交
    • E
      thermal: of-thermal: add support for reading coefficients property · a46dbae8
      Eduardo Valentin 提交于
      In order to avoid having each driver adding their own
      specific DT property to specify slope and offset,
      this patch adds a basic coefficient reading from
      DT thermal zone node. Right now, as the thermal
      framework does not support multiple sensors,
      the current coefficients apply only to the only
      sensor in the thermal zone.
      
      The supported equation is a simple linear model:
      	slope * <sensor reading> + offset.
      
      slope and offset are read from the coefficients
      DT property. In the same way as it is described in
      the DT thermal binding.
      
      So, as of today, the thermal framework will support
      only cases like:
                      /* hotspot = 1 * adc + 6000 */
      		coefficients =          <1      6000>;
      Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      a46dbae8
    • E
      thermal: support slope and offset coefficients · 9d0be7f4
      Eduardo Valentin 提交于
      It is common to have a linear extrapolation from
      the current sensor readings and the actual temperature
      value. This is specially the case when the sensor
      is in use to extrapolate hotspots.
      
      This patch adds slope and offset constants for
      single sensor linear extrapolation equation. Because
      the same sensor can be use in different locations,
      from board to board, these constants are added
      as part of thermal_zone_params.
      
      The constants are available through sysfs.
      
      It is up to the device driver to determine
      the usage of these values.
      Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      9d0be7f4
    • J
      thermal: power_allocator: round the division when divvying up power · ea54cac9
      Javi Merino 提交于
      In situations where there is an uneven number of cooling devices, the
      division of power among them can lead to a milliwatt being dropped on
      the floor due to rounding errors.  This doesn't sound like a lot, but
      some devices only grant the lowest cooling device state for their
      maximum power.  So for instance, if the granted_power is the maximum
      power and all devices are getting their maximum power, one would get
      max_power - 1, making it choose cooling device state 1, instead of 0.
      
      Round the division to make the calculation more accurate.
      
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Signed-off-by: NJavi Merino <javi.merino@arm.com>
      Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      ea54cac9
  3. 05 5月, 2015 24 次提交
  4. 04 5月, 2015 8 次提交
  5. 03 5月, 2015 3 次提交
    • J
      ext4: fix growing of tiny filesystems · 2c869b26
      Jan Kara 提交于
      The estimate of necessary transaction credits in ext4_flex_group_add()
      is too pessimistic. It reserves credit for sb, resize inode, and resize
      inode dindirect block for each group added in a flex group although they
      are always the same block and thus it is enough to account them only
      once. Also the number of modified GDT block is overestimated since we
      fit EXT4_DESC_PER_BLOCK(sb) descriptors in one block.
      
      Make the estimation more precise. That reduces number of requested
      credits enough that we can grow 20 MB filesystem (which has 1 MB
      journal, 79 reserved GDT blocks, and flex group size 16 by default).
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      2c869b26
    • D
      ext4: move check under lock scope to close a race. · 280227a7
      Davide Italiano 提交于
      fallocate() checks that the file is extent-based and returns
      EOPNOTSUPP in case is not. Other tasks can convert from and to
      indirect and extent so it's safe to check only after grabbing
      the inode mutex.
      Signed-off-by: NDavide Italiano <dccitaliano@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      280227a7
    • L
      ext4: fix data corruption caused by unwritten and delayed extents · d2dc317d
      Lukas Czerner 提交于
      Currently it is possible to lose whole file system block worth of data
      when we hit the specific interaction with unwritten and delayed extents
      in status extent tree.
      
      The problem is that when we insert delayed extent into extent status
      tree the only way to get rid of it is when we write out delayed buffer.
      However there is a limitation in the extent status tree implementation
      so that when inserting unwritten extent should there be even a single
      delayed block the whole unwritten extent would be marked as delayed.
      
      At this point, there is no way to get rid of the delayed extents,
      because there are no delayed buffers to write out. So when a we write
      into said unwritten extent we will convert it to written, but it still
      remains delayed.
      
      When we try to write into that block later ext4_da_map_blocks() will set
      the buffer new and delayed and map it to invalid block which causes
      the rest of the block to be zeroed loosing already written data.
      
      For now we can fix this by simply not allowing to set delayed status on
      written extent in the extent status tree. Also add WARN_ON() to make
      sure that we notice if this happens in the future.
      
      This problem can be easily reproduced by running the following xfs_io.
      
      xfs_io -f -c "pwrite -S 0xaa 4096 2048" \
                -c "falloc 0 131072" \
                -c "pwrite -S 0xbb 65536 2048" \
                -c "fsync" /mnt/test/fff
      
      echo 3 > /proc/sys/vm/drop_caches
      xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff
      
      This can be theoretically also reproduced by at random by running fsx,
      but it's not very reliable, though on machines with bigger page size
      (like ppc) this can be seen more often (especially xfstest generic/127)
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      d2dc317d