1. 07 5月, 2015 2 次提交
  2. 31 3月, 2015 1 次提交
    • N
      mtd: pxa3xx_nand: cleanup wait_for_completion handling · e5860c18
      Nicholas Mc Guire 提交于
      return type of wait_for_completion_timeout is unsigned long not int, this
      patch uses the return value of wait_for_completion_timeout in the condition
      directly rather than assigning it to an incorrect type variable.
      
      The variable used for handling the return of wait_for_cmpletion_timeout
      was int but should be unsigned long, where it was not in use for
      anything else and the return value in case of completion (>0) is not
      used it was removed and wait_for_completion_timeout() used directly in
      the if condition.
      
      To make the timeout values a bit simpler to read and also handle all of
      the corner cases correctly the declarations are moved to
      msecs_to_jiffies().
      
      The timeout declaration cleanup is just for readability
      Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      e5860c18
  3. 28 2月, 2015 4 次提交
    • A
      mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0 · 7c2f7176
      Antoine Ténart 提交于
      pxa3xx_flash_ids wasn't initialized to 0, which in certain cases could
      end up containing corrupted values in its members. Fix this to avoid
      possible issues.
      Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      7c2f7176
    • R
      mtd: pxa3xx_nand: fix driver when num_cs is 0 · e423c90a
      Robert Jarzmik 提交于
      As the devicetree binding doesn't require num_cs to exist or be strictly
      positive, and neither does the platform data case, a bug appear when
      num_cs is set to 0 and panics the kernel.
      
      The issue is that in alloc_nand_resource(), chip is dereferenced without
      having a value assigned when num_cs == 0.
      
      Fix this by returning ENODEV is num_cs == 0.
      
      The panic seen is :
      Unable to handle kernel NULL pointer dereference at virtual address 000002b8
      pgd = c0004000
      [000002b8] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT ARM
      Modules linked in:
      Hardware name: Marvell PXA3xx (Device Tree Support)
      task: c3822aa0 ti: c3826000 task.ti: c3826000
      PC is at alloc_nand_resource+0x180/0x4a8
      LR is at alloc_nand_resource+0xa0/0x4a8
      pc : [<c0275b90>]    lr : [<c0275ab0>]    psr: 68000013
      sp : c3827d90  ip : 00000000  fp : 00000000
      r10: c3862200  r9 : 0000005e  r8 : 00000000
      r7 : c3865610  r6 : c3862210  r5 : c3924210  r4 : c3862200
      r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 0000397f  Table: 80004018  DAC: 00000035
      Process swapper (pid: 1, stack limit = 0xc3826198)
      Stack: (0xc3827d90 to 0xc3828000)
      ...zip...
      [<c0275b90>] (alloc_nand_resource) from [<c0275ff8>] (pxa3xx_nand_probe+0x140/0x978)
      [<c0275ff8>] (pxa3xx_nand_probe) from [<c0258c40>] (platform_drv_probe+0x48/0xa4)
      [<c0258c40>] (platform_drv_probe) from [<c0257650>] (driver_probe_device+0x80/0x21c)
      [<c0257650>] (driver_probe_device) from [<c0257878>] (__driver_attach+0x8c/0x90)
      [<c0257878>] (__driver_attach) from [<c0255ec4>] (bus_for_each_dev+0x58/0x88)
      [<c0255ec4>] (bus_for_each_dev) from [<c0256ec8>] (bus_add_driver+0xd8/0x1d4)
      [<c0256ec8>] (bus_add_driver) from [<c0257f14>] (driver_register+0x78/0xf4)
      [<c0257f14>] (driver_register) from [<c00088a8>] (do_one_initcall+0x80/0x1e4)
      [<c00088a8>] (do_one_initcall) from [<c048ed08>] (kernel_init_freeable+0xec/0x1b4)
      [<c048ed08>] (kernel_init_freeable) from [<c0377d8c>] (kernel_init+0x8/0xe4)
      [<c0377d8c>] (kernel_init) from [<c00095f8>] (ret_from_fork+0x14/0x3c)
      Code: e503b234 e5953008 e1530001 caffffd1 (e59002b8)
      ---[ end trace a5770060c8441895 ]---
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      e423c90a
    • R
      mtd: pxa3xx-nand: handle PIO in threaded interrupt · 24542257
      Robert Jarzmik 提交于
      Change the handling of the data stage in the driver : don't pump data in
      the top-half interrupt, but rather schedule a thread for non dma cases.
      
      This will enable latencies in the data pumping, especially if delays are
      required. Moreover platform shall be more reactive as other interrupts
      can be served while pumping data.
      
      No throughput degradation was observed, at least on the zylonite
      platform, while a slight degradation was being expected.
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Tested-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      24542257
    • M
      mtd: nand: pxa3xx: Fix PIO FIFO draining · 8dad0386
      Maxime Ripard 提交于
      The NDDB register holds the data that are needed by the read and write
      commands.
      
      However, during a read PIO access, the datasheet specifies that after each 32
      bytes read in that register, when BCH is enabled, we have to make sure that the
      RDDREQ bit is set in the NDSR register.
      
      This fixes an issue that was seen on the Armada 385, and presumably other mvebu
      SoCs, when a read on a newly erased page would end up in the driver reporting a
      timeout from the NAND.
      
      Cc: <stable@vger.kernel.org> # v3.14
      Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      8dad0386
  4. 29 5月, 2014 1 次提交
    • T
      mtd: pxa3xx_nand: make the driver work on big-endian systems · b7e46062
      Thomas Petazzoni 提交于
      The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl()
      to access I/O registers. However, those functions do not do any
      endianness swapping, which means that they won't work when the CPU
      runs in big-endian but the I/O registers are little endian, which is
      the common situation for ARM systems running big endian.
      
      Since __raw_writel() and __raw_readl() do not include any memory
      barriers and the pxa3xx_nand driver can only be compiled for ARM
      platforms, the closest I/o accessors functions that do endianess
      swapping are writel_relaxed() and readl_relaxed().
      
      This patch has been verified to work on Armada XP GP: without the
      patch, the NAND is not detected when the kernel runs big endian while
      it is properly detected when the kernel runs little endian. With the
      patch applied, the NAND is properly detected in both situations
      (little and big endian).
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: <stable@vger.kernel.org> # v3.13+
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      b7e46062
  5. 22 5月, 2014 2 次提交
  6. 21 5月, 2014 1 次提交
  7. 11 3月, 2014 2 次提交
  8. 21 1月, 2014 1 次提交
  9. 13 1月, 2014 1 次提交
  10. 04 1月, 2014 25 次提交