1. 22 Dec, 2015 5 commits
  2. 19 Dec, 2015 1 commit
  3. 17 Dec, 2015 2 commits
    • Felipe Balbi's avatar
      ARM: OMAP2+: AM43xx: select ARM TWD timer · 54011103
      Felipe Balbi authored
      Make sure to tell the kernel that AM437x devices have ARM TWD timer.
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [grygorii.strashko@ti.com: drop ARM Global timer selection, because
       it's incompatible with PM (cpuidle/cpufreq). So, it's unsafe to enable
       it unconditionally]
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      54011103
    • Grygorii Strashko's avatar
      ARM: OMAP2+: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST · 0b3e6fca
      Grygorii Strashko authored
      System will misbehave in the following case:
      - AM43XX only build (UP);
      - CONFIG_CPU_IDLE=y
      - ARM TWD timer enabled and selected as clockevent device.
      
      In the above case, It's expected that broadcast timer will be used as
      backup timer when CPUIdle will put MPU in low power states where ARM
      TWD will stop and lose its context. But, the CONFIG_SMP might not be
      selected when kernel is built for AM43XX SoC only and, as result,
      GENERIC_CLOCKEVENTS_BROADCAST option will not be selected also. This
      will break CPUIdle and System will stuck in low power states.
      
      Hence, fix it by selecting GENERIC_CLOCKEVENTS_BROADCAST option for
      AM43XX SoCs always and add empty tick_broadcast() function
      implementation - no need to send any IPI on UP. After this change
      timer1 will be selected as broadcast timer the same way as for SMP,
      and CPUIdle will work properly.
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      0b3e6fca
  4. 15 Dec, 2015 4 commits
    • Lijun Pan's avatar
      fsl-ifc: add missing include on ARM64 · c4aa1937
      Lijun Pan authored
      Need to include sched.h to fix the following compilation error
      if FSL_IFC is enabled on ARM64 machine.
      
      In file included from include/linux/mmzone.h:9:0,
                       from include/linux/gfp.h:5,
                       from include/linux/kmod.h:22,
                       from include/linux/module.h:13,
                       from drivers/memory/fsl_ifc.c:22:
      drivers/memory/fsl_ifc.c: In function ‘check_nand_stat’:
      include/linux/wait.h:165:35: error: ‘TASK_NORMAL’ undeclared (first use in this function)
       #define wake_up(x)   __wake_up(x, TASK_NORMAL, 1, NULL)
                                         ^
      drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
         wake_up(&ctrl->nand_wait);
         ^
      include/linux/wait.h:165:35: note: each undeclared identifier is reported only once for each function it appears in
       #define wake_up(x)   __wake_up(x, TASK_NORMAL, 1, NULL)
                                         ^
      drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
         wake_up(&ctrl->nand_wait);
         ^
      
      Analysis is as follows:
      I put some instrumental code and get the
      following .h files inclusion sequence:
      
      In file included from ./arch/arm64/include/asm/compat.h:25:0,
                       from ./arch/arm64/include/asm/stat.h:23,
                       from include/linux/stat.h:5,
                       from include/linux/module.h:10,
                       from drivers/memory/fsl_ifc.c:23:
      include/linux/sched.h:113:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘struct’
       struct sched_attr {
       ^
      
      CONFIG_COMPAT=y is enabled while 39 and 48 bit VA is selected.
      When 42 bit VA is selected, it does not enable CONFIG_COMPAT=y
      
      In ./arch/arm64/include/asm/stat.h:23, it has
      "#ifdef CONFIG_COMPAT"
      "#include <asm/compat.h>"
      "..."
      "#endif"
      
      Since ./arch/arm64/include/asm/stat.h does not
      include ./arch/arm64/include/asm/compat.h,
      then it will not include include/linux/sched.h
      Hence we have to manually add "#include <linux/sched.h>"
      in drivers/memory/fsl_ifc.c
      Signed-off-by: default avatarLijun Pan <Lijun.Pan@freescale.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c4aa1937
    • Krzysztof Hałasa's avatar
      ARM: dts: imx6: Fix Ethernet PHY mode on Ventana boards · 3a35e470
      Krzysztof Hałasa authored
      Gateworks Ventana boards seem to need "RGMII-ID" (internal delay)
      PHY mode, instead of simple "RGMII", for their Marvell 88E1510
      transceiver. Otherwise, the Ethernet MAC doesn't work with Marvell PHY
      driver (TX doesn't seem to work correctly).
      
      Tested on GW5400 rev. C.
      
      This bug affects ARM Fedora 23.
      Signed-off-by: default avatarKrzysztof Hałasa <khalasa@piap.pl>
      Acked-by: default avatarTim Harvey <tharvey@gateworks.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      3a35e470
    • Bai Ping's avatar
      ARM: dts: imx: Fix the assigned-clock mismatch issue on imx6q/dl · 13fdae1a
      Bai Ping authored
      The 'assigned-clock-parents' and 'assigned-clock-rates' list
      should corresponding to the 'assigned-clocks' property clock list.
      Signed-off-by: default avatarBai Ping <b51503@freescale.com>
      Fixes: ed339363 ("ARM: dts: imx6qdl-sabreauto: Allow HDMI and LVDS to work simultaneously")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      13fdae1a
    • Kevin Hilman's avatar
      Merge tag 'sunxi-fixes-for-4.4' of... · 8fcacc03
      Kevin Hilman authored
      Merge tag 'sunxi-fixes-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
      
      Merge "Allwinner fixes for 4.4" from Maxime Ripard:
      
      Allwinner fixes for 4.4
      
      Two patches, one to fix the touchscreen axis on one Allwinner board, and
      the other one fixing a mutex unlocking issue on one error path in the RSB
      driver.
      
      * tag 'sunxi-fixes-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
        bus: sunxi-rsb: unlock on error in sunxi_rsb_read()
        ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property
      8fcacc03
  5. 12 Dec, 2015 4 commits
  6. 11 Dec, 2015 1 commit
    • Stefan Agner's avatar
      ARM: dts: vf610: use reset values for L2 cache latencies · 9c171905
      Stefan Agner authored
      Linux on Vybrid used several different L2 latencies so far, none
      of them seem to be the right ones. According to the application note
      AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
      on CPU clock and is inside the L2 cache controller, whereas the data
      portion is stored in the external SRAM running on platform clock.
      Hence it is likely that the correct value requires a higher data
      latency then tag latency.
      
      These are the values which have been used so far:
      - The mainline values:
        arm,data-latency = <1 1 1>;
        arm,tag-latency = <2 2 2>;
        Those values have lead to problems on higher clocks. They look
        like a poor translation from the reset values (missing +1 offset
        and a mix up between tag/latency values).
      - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
        arm,data-latency = <4 2 3>
        arm,tag-latency = <4 2 3>
        The cache initialization function along with the value matches the
        i.MX6 code from the same kernel, so it seems that those values have
        just been copied.
      - The Colibri values:
        arm,data-latency = <2 1 2>;
        arm,tag-latency = <3 2 3>;
        Those were a mix between the values of the Linux 3.0 based BSP and
        the mainline values above.
      - The SoC Reset values (converted to DT notation):
        arm,data-latency = <3 3 3>;
        arm,tag-latency = <2 2 2>;
      
      So far there is no official statement on what the correct values are.
      See also the related Freescale community thread:
      https://community.freescale.com/message/579785#579785
      
      For now, the reset values seem to be the best bet. Remove all other
      "bogus" values and use the reset value on vf610.dtsi level.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      9c171905
  7. 10 Dec, 2015 8 commits
  8. 04 Dec, 2015 2 commits
  9. 02 Dec, 2015 2 commits
    • Stefan Agner's avatar
      ARM: dts: vf610: fix clock definition for SAI2 · 531ee1f4
      Stefan Agner authored
      So far, only the bus clock has been assigned, but in reality the
      SAI IP has for clock inputs. The driver has been updated to
      make use of the additional clock inputs by c3ecef21 ("ASoC:
      fsl_sai: add sai master mode support"). Due to a bug in the
      clock tree, the audio clock has been enabled none the less by
      the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
      clock tree"), which made master mode even without the proper
      clock assigned working.
      
      This patch completes the clock definition for SAI2. On Vybrid,
      only two MCLK out of the four options are available (the first
      being the bus clock itself). See chapter 8.10.1.2.3 of the
      Vybrid Reference manual ("SAI transmitter and receiver options
      for MCLK selection"). Note: The audio clocks are only required
      in master mode.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      531ee1f4
    • Stefan Agner's avatar
      ARM: imx: clk-vf610: fix SAI clock tree · 3b60a26f
      Stefan Agner authored
      The Synchronous Audio Interface (SAI) instances are clocked by
      independent clocks: The bus clock and the audio clock (as shown in
      Figure 51-1 in the Vybrid Reference Manual). The clock gates in
      CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
      tests to the registers with/without gating those clocks have shown.
      The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
      followed by a clock divider (SAIx_DIV). Currently, the parent of
      the bus clock gates has been assigned to SAIx_DIV, which is not
      involved in the bus clock path for the SAI instances (see chapter
      9.10.12, SAI clocking in the Vybrid Reference Manual).
      
      Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
      clock.
      
      If the driver needs the audio clock (when used in master mode), a
      fixed device tree is required which assign the audio clock properly
      to VF610_CLK_SAIx_DIV.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Acked-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      3b60a26f
  10. 01 Dec, 2015 2 commits
    • Arnd Bergmann's avatar
      ARM: ixp4xx: fix read{b,w,l} return types · d66e5139
      Arnd Bergmann authored
      On ixp4xx, the readl() function returns an 'unsigned long' output
      when indirect I/O is used. This is unlike any other platform, and
      it causes lots of harmless compiler warnings, such as:
      
      drivers/ata/libahci.c: In function 'ahci_show_host_version':
      drivers/ata/libahci.c:254:22: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
      drivers/block/mtip32xx/mtip32xx.c: In function 'mtip_hw_read_registers':
      drivers/block/mtip32xx/mtip32xx.c:2602:31: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
      drivers/block/cciss.c: In function 'print_cfg_table':
      drivers/block/cciss.c:3845:25: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
      
      This changes all six of the ixp4xx specific I/O read functions
      to return the same types that we have in the normal asm/io.h,
      to avoid the warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      d66e5139
    • Guillaume Delbergue's avatar
      irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB · d5d4fdd8
      Guillaume Delbergue authored
      This patch is specifically for PCI support on the Versatile PB board using
      a DT. Currently, the dynamic IRQ mapping is broken when using DTs. For
      example, on QEMU, the SCSI driver is unable to request the IRQ. To fix
      this issue, this patch replaces the current dynamic mechanism with a
      static value as is done in the non-DT case.
      Signed-off-by: default avatarGuillaume Delbergue <guillaume.delbergue@greensocs.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: stable@vger.kernel.org
      d5d4fdd8
  11. 30 Nov, 2015 9 commits