Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 13 1月, 2015 4 次提交
    • G
      mtd: denali: fix incorrect bitmask error in denali_setup_dma · 7c272ac5
      由 Graham Moore 提交于 
      commit 3157d1ed ("mtd: denali: remove unnecessary casts") introduced
an error by using a wrong bitmask.

A uint16_t cast was replaced with & 0xff, should be & 0xffff.
Signed-off-by: NGraham Moore <grmoore@opensource.altera.com>
Signed-off-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      7c272ac5
    • L
      mtd: st_spi_fsm: Fix [-Wsign-compare] build warning · a9b679bf
      由 Lee Jones 提交于 
      drivers/mtd/devices/st_spi_fsm.c:1647:17:
  warning: comparison between signed and unsigned integer expressions
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      a9b679bf
    • L
      mtd: st_spi_fsm: Obtain and use EMI clock · 69d5af8d
      由 Lee Jones 提交于 
      ST's Common Clk Framework is now available. This patch ensures the FSM
makes use of it by obtaining and enabling the EMI clock. If system fails
to provide the EMI clock, we bomb out.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      69d5af8d
    • L
      mtd: st_spi_fsm: Extend fsm_clear_fifo to handle unwanted bytes · 5ecd3ea1
      由 Lee Jones 提交于 
      Under certain conditions, the SPI-FSM Controller can be left in a state where
the data FIFO is not entirely empty.  This can lead to problems where subsequent
data transfers appear to have been shifted by a number of unidentified bytes.

One simple example would be an errant FSM sequence which loaded more data to the
FIFO than was read by the host.  Another more interesting case results from an
obscure artefact in the FSM Controller.  When switching from data transfers in
x4 or x2 mode to data transfers in x1 mode, extraneous bytes will appear in the
FIFO, unless the previous data transfer was a multiple of 32 cycles (i.e. 8
bytes for x2, and 16 bytes for x4).  This applies equally whether FSM is being
operated directly by a S/W driver, or by the SPI boot-controller in FSM-Boot
mode.  Furthermore, data in the FIFO not only survive a transition between
FSM-Boot and FSM, but also a S/W reset of IP block [1].

By taking certain precautions, it is possible to prevent the driver from causing
this type of problem (e.g. ensuring that the host and programmed sequence
agree on the transfer size, and restricting transfer sizes to multiples of
32-cycles [2]).  However, at the point the driver is loaded, no assumptions can be
made regarding the state of the FIFO.  Even if previous S/W drivers have behaved
correctly, it is impossible to control the number of transactions serviced by
the controller operating in FSM-Boot.

To address this problem, we ensure the FIFO is cleared during initialisation,
before performing any FSM operations.  Previously, the fsm_clear_fifo() code was
capable of detecting and clearing any unwanted 32-bit words from the FIFO.  This
patch extends the capability to handle an arbitrary number of bytes present in
the FIFO [3].  Now that the issue is better understood, we also remove the calls
to fsm_clear_fifo() following the fsm_read() and fsm_write() operations.

The process of actually clearing the FIFO deserves a mention.  While the FIFO
may contain any number of bytes, the SPI_FAST_SEQ_STA register only reports the
number of complete 32-bit words present.  Furthermore, data can only be drained
from the FIFO by reading complete 32-bit words.  With this in mind, a two stage
process is used to the clear the FIFO:

    1. Read any complete 32-bit words from the FIFO, as reported by the
           SPI_FAST_SEQ_STA register.

    2. Mop up any remaining bytes.  At this point, it is not known if there
           are 0, 1, 2, or 3 bytes in the FIFO.  To handle all cases, a dummy
           FSM sequence is used to load one byte at a time, until a complete
           32-bit word is formed; at most, 4 bytes will need to be loaded.

[1] Although this issue has existed since early versions of the SPI-FSM
    controller, its full extent only emerged recently as a consequence of the
    targetpacks starting to use FSM-Boot(x4) as the default configuration.

[2] The requirement to restrict transfers to multiples of 32 cycles was found
    empirically back when DUAL and QUAD mode support was added.  The current
    analysis now gives a satisfactory explanation for this requirement.

[3] Theoretically, it is possible for the FIFO to contain an arbitrary number of
    bits.  However, since there are no known use-cases that leave incomplete
    bytes in the FIFO, only words and bytes are considered here.
Signed-off-by: NAngus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      5ecd3ea1
  3. 10 1月, 2015 5 次提交
  5. 08 1月, 2015 7 次提交
  7. 23 12月, 2014 2 次提交
  9. 20 12月, 2014 4 次提交
  11. 19 12月, 2014 8 次提交
  13. 18 12月, 2014 9 次提交
    • F
      watchdog: imx2_wdt: Fix the argument of watchdog_active() · ba90f261
      由 Fabio Estevam 提交于 
      Fix the following build warning by passing the expected argument type to
watchdog_active():

drivers/watchdog/imx2_wdt.c: In function 'imx2_wdt_suspend':
drivers/watchdog/imx2_wdt.c:340:2: warning: passing argument 1 of 'watchdog_active' from incompatible pointer type [enabled by default]
In file included from drivers/watchdog/imx2_wdt.c:38:0:
include/linux/watchdog.h:104:20: note: expected 'struct watchdog_device *' but argument is of type 'struct watchdog_device **'
Reported-by: NOlof's autobuilder <build@lixom.net>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      ba90f261
    • X
      watchdog: imx2_wdt: Add power management support. · aefbaf3a
      由 Xiubo Li 提交于 
      Add power management operations(suspend and resume) as part of
dev_pm_ops for IMX2 watchdog driver.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      aefbaf3a
    • G
      i2c: sh_mobile: I2C_SH_MOBILE should depend on HAS_DMA · f16ea4f0
      由 Geert Uytterhoeven 提交于 
      If NO_DMA=y:

drivers/built-in.o: In function `sh_mobile_i2c_dma_unmap':
i2c-sh_mobile.c:(.text+0x60de42): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sh_mobile_i2c_xfer_dma':
i2c-sh_mobile.c:(.text+0x60df22): undefined reference to `dma_map_single'
i2c-sh_mobile.c:(.text+0x60df2e): undefined reference to `dma_mapping_error'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      f16ea4f0
    • W
      i2c: sh_mobile: rework deferred probing · 55f5f986
      由 Wolfram Sang 提交于 
      DMA is opt-in for this driver. So, we can't use deferred probing for
requesting DMA channels in probe, because our driver would get endlessly
deferred if DMA support is compiled in AND the DMA driver is missing.
Because we can't know when the DMA driver might show up, we always try
again when a DMA transfer would be possible. The downside is that there
is more overhead for setting up PIO transfers under the above scenario.
But well, having DMA enabled and the proper DMA driver missing looks
like a broken or test config anyhow.
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      55f5f986
    • W
      i2c: sh_mobile: refactor DMA setup · e844a799
      由 Wolfram Sang 提交于 
      Refactor DMA setup to keep the errno so we can implement better
deferred probe support in the next step.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      e844a799
    • T
      i2c: mv64xxx: rework offload support to fix several problems · 00d8689b
      由 Thomas Petazzoni 提交于 
      Originally, the I2C controller supported by the i2c-mv64xxx driver
requires a lot of software support: an interrupt is generated at each
step of an I2C transaction (after the start bit, after sending the
address, etc.) and the driver is in charge of re-programming the I2C
controller to do the next step of the I2C transaction. This explains
the fairly complex state machine that the driver has.

On Marvell Armada XP and later processors (Armada 375, 38x, etc.), the
I2C controller was extended with a part called the "I2C Bridge", which
allows to offload the I2C transaction completely to the
hardware. Initial support for this mechanism was added in commit
930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support").

However, the implementation done in this commit has two related
issues, which this commit fixes by completely changing how the offload
implementation is done:

 * SMBus read transfers, where there is one write to select the
   register immediately followed in the same transaction by one read,
   were making the processor hang. This was easier visible on the
   Marvell Armada XP WRT1900AC platform using a driver for an I2C LED
   controller, or on other Armada XP platforms by using a simple
   'i2cget' command to read an I2C EEPROM.

 * The implementation was based on the fact that the offload engine
   was re-programmed to transfer each message of an I2C xfer: this
   meant that each message sent with the offload engine was starting
   with a normal I2C start sequence. However, the I2C subsystem
   assumes that all messages belonging to the same xfer will use the
   so-called "repeated start" so that the entire I2C xfer is seen as
   one transfer by the I2C devices and cannot be interrupt by other
   I2C masters on the same bus.

In fact, the "I2C Bridge" allows to offload three types of xfer:

 - xfer of one write message
 - xfer of one read message
 - xfer of one write message followed by one read message

For all other situations, we have to fallback to not using the "I2C
Bridge" in order to get proper I2C semantics.

Therefore, this commit reworks the offload implementation to put it
not at the message level, but at the xfer level: in the
mv64xxx_i2c_xfer() function, we decide if the transaction can be
offloaded (in which case it is handled by the
mv64xxx_i2c_offload_xfer() function), or otherwise it is handled by
the slow path (implemented in the existing mv64xxx_i2c_execute_msg()).

This allows to simplify the state machine, which no longer needs to
have any state related to the offload implementation: the offload
implementation is now completely separated from the slow path (with
the exception of the interrupt handler, of course).

In summary:

 - mv64xxx_i2c_can_offload() will analyze an I2C xfer and decided of
   the "I2C Bridge" can be used to offload it or not.

 - mv64xxx_i2c_offload_xfer() will actually program the "I2C Bridge"
   to offload one xfer (of either one or two messages), and block
   using mv64xxx_i2c_wait_for_completion() until the xfer completes.

 - The interrupt handler mv64xxx_i2c_intr() is modified to push the
   offload related code to a separate function,
   mv64xxx_i2c_intr_offload(). It will take care of reading the
   received data if needed.

This commit was tested on:

 - Armada XP OpenBlocks AX3-4 (EEPROM on I2C and RTC on I2C)
 - Armada XP WRT1900AC (LED controller on I2C)
 - Armada XP GP (EEPROM on I2C)

Fixes: 930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support")
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[wsa: fixed checkpatch warnings]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      00d8689b
    • T
      i2c: mv64xxx: use BIT() macro for register value definitions · 12598695
      由 Thomas Petazzoni 提交于 
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      12598695
    • I
      rbd: don't treat CEPH_OSD_OP_DELETE as extent op · 7e868b6e
      由 Ilya Dryomov 提交于 
      CEPH_OSD_OP_DELETE is not an extent op, stop treating it as such.  This
sneaked in with discard patches - it's one of the three osd ops (the
other two are CEPH_OSD_OP_TRUNCATE and CEPH_OSD_OP_ZERO) that discard
is implemented with.
Signed-off-by: NIlya Dryomov <idryomov@redhat.com>
Reviewed-by: NAlex Elder <elder@linaro.org>
      7e868b6e
    • S
      ceph, rbd: delete unnecessary checks before two function calls · e96a650a
      由 SF Markus Elfring 提交于 
      The functions ceph_put_snap_context() and iput() test whether their
argument is NULL and then return immediately. Thus the test around the
call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
[idryomov@redhat.com: squashed rbd.c hunk, changelog]
Signed-off-by: NIlya Dryomov <idryomov@redhat.com>
      e96a650a
  15. 17 12月, 2014 1 次提交