Skip to content

L
linux
Switch branch/tag
  1. 31 Dec, 2015 1 commit
  3. 22 Dec, 2015 5 commits
  5. 19 Dec, 2015 1 commit
  7. 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
  9. 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
  11. 12 Dec, 2015 4 commits
  13. 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
  15. 10 Dec, 2015 8 commits
  17. 04 Dec, 2015 2 commits
  19. 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
  21. 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
  23. 30 Nov, 2015 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7