Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 7月, 2017 1 次提交
    • A
      ARM: pxa: select both FB and FB_W100 for eseries · 1d20d8a9
      由 Arnd Bergmann 提交于 
      We get a link error trying to access the w100fb_gpio_read/write
functions from the platform when the driver is a loadable module
or not built-in, so the platform already uses 'select' to hard-enable
the driver.

However, that fails if the framebuffer subsystem is disabled
altogether.

I've considered various ways to fix this properly, but they
all seem like too much work or too risky, so this simply
adds another 'select' to force the subsystem on as well.

Fixes: 82427de2 ("ARM: pxa: PXA_ESERIES depends on FB_W100.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      1d20d8a9
  3. 27 7月, 2017 1 次提交
  5. 14 6月, 2017 4 次提交
  7. 23 5月, 2017 2 次提交
  9. 19 4月, 2017 1 次提交
  11. 05 4月, 2017 2 次提交
  13. 04 4月, 2017 1 次提交
  15. 28 2月, 2017 1 次提交
  17. 13 2月, 2017 1 次提交
  19. 19 1月, 2017 2 次提交
  21. 06 11月, 2016 1 次提交
  23. 03 11月, 2016 1 次提交
  25. 30 10月, 2016 1 次提交
  27. 29 10月, 2016 2 次提交
  29. 19 10月, 2016 1 次提交
  31. 18 10月, 2016 3 次提交
  33. 29 9月, 2016 1 次提交
  35. 12 9月, 2016 1 次提交
  37. 10 9月, 2016 5 次提交
    • R
      ARM: pxa: pxa_cplds: fix interrupt handling · 9ba63e3c
      由 Robert Jarzmik 提交于 
      Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.

This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.

For the record, the hardware is working as follows.

The interrupt mechanism relies on :
 - one status register
 - one mask register

Let's suppose the input irq lines are called :
 - i_sa1111
 - i_lan91x
 - i_mmc_cd
Let's suppose the status register for each irq line is called :
 - status_sa1111
 - status_lan91x
 - status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
 - irqen_sa1111
 - irqen_lan91x
 - irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
 - o_gpio0

The behavior is as follows :
 - o_gpio0 = not((status_sa1111 & irqen_sa1111) |
		 (status_lan91x & irqen_lan91x) |
		 (status_mmc_cd & irqen_mmc_cd))
   => this is a N-to-1 NOR gate and multiple AND gates
 - irqen_* is exactly as programmed by a write to the FPGA
 - status_* behavior is governed by a bi-stable D flip-flop
   => on next FPGA clock :
     - if i_xxx is high, status_xxx becomes 1
     - if i_xxx is low, status_xxx remains as it is
     - if software sets status_xxx to 0, the D flip-flop is reset
       => status_xxx becomes 0
       => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
	  1 again

Fixes: fc9e38c0 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      9ba63e3c
    • R
      ARM: pxa: remove irq init from dt machines · 32f17997
      由 Robert Jarzmik 提交于 
      The init_irq and handle_irq can be declared through standard irqchip
declaration and are not necessary in machine descriptions.

This is another step towards the generic kernel for the pxa
architecture.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      32f17997
    • M
      ARM: pxa: Use kmalloc_array() in pxa_pm_init() · 85711105
      由 Markus Elfring 提交于 
      * A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus use the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      85711105
    • P
      ARM: pxa: magician: Remove duplicated I2C pins declaration · e572f649
      由 Petr Cvek 提交于 
      Magician has GPIO117_I2C_SCL and GPIO118_I2C_SDA pins declared twice.
Signed-off-by: NPetr Cvek <petr.cvek@tul.cz>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      e572f649
    • R
      ARM: pxa: fix GPIO double shifts · ca26475b
      由 Robert Jarzmik 提交于 
      The commit 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register") from Oct 17, 2011, leads to the following static checker
warning:
  arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup()
  warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT)
        << (1 << ((SPITZ_GPIO_KEY_INT) & 31))'

As Dan reported, the value is shifted three times :
 - once by gpio_get_value(), which returns either 0 or BIT(gpio)
 - once by the shift operation '<<'
 - a last time by GPIO_bit(gpio) which is BIT(gpio)

Therefore the calculation lead to a chained or operator of :
 - (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio)

It is be sheer luck the former statement works, only because each gpio
used is strictly smaller than 6, and therefore 2^(gpio^2) never
overflows a 32 bits value, and because it is used as a boolean value to
check a gpio activation.

As the xxx_charger_wakeup() functions are used as a true/false detection
mechanism, take that opportunity to change their prototypes from integer
return value to boolean one.

Fixes: 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      ca26475b
  39. 29 8月, 2016 1 次提交
    • R
      net: smc91x: fix SMC accesses · 2fb04fdf
      由 Russell King 提交于 
      Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
machines") broke some ARM platforms through several mistakes.  Firstly,
the access size must correspond to the following rule:

(a) at least one of 16-bit or 8-bit access size must be supported
(b) 32-bit accesses are optional, and may be enabled in addition to
    the above.

Secondly, it provides no emulation of 16-bit accesses, instead blindly
making 16-bit accesses even when the platform specifies that only 8-bit
is supported.

Reorganise smc91x.h so we can make use of the existing 16-bit access
emulation already provided - if 16-bit accesses are supported, use
16-bit accesses directly, otherwise if 8-bit accesses are supported,
use the provided 16-bit access emulation.  If neither, BUG().  This
exactly reflects the driver behaviour prior to the commit being fixed.

Since the conversion incorrectly cut down the available access sizes on
several platforms, we also need to go through every platform and fix up
the overly-restrictive access size: Arnd assumed that if a platform can
perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
size needed to be specified - not so, all available access sizes must
be specified.

This likely fixes some performance regressions in doing this: if a
platform does not support 8-bit accesses, 8-bit accesses have been
emulated by performing a 16-bit read-modify-write access.

Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
accesses, which was broken by the original commit.

Fixes: b70661c7 ("net: smc91x: use run-time configuration on all ARM machines")
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fb04fdf
  41. 11 8月, 2016 1 次提交
  43. 09 8月, 2016 3 次提交
  45. 09 7月, 2016 1 次提交
  47. 27 6月, 2016 1 次提交
  49. 06 5月, 2016 1 次提交