1. 22 8月, 2013 1 次提交
  2. 16 8月, 2013 13 次提交
  3. 15 7月, 2013 4 次提交
    • S
      ARM: imx: fix vf610 enet module clock selection · 4f71612e
      Shawn Guo 提交于
      The fec/enet driver calculates MDC rate with the formula below.
      
        ref_freq / ((MII_SPEED + 1) x 2)
      
      The ref_freq here is the fec internal module clock, which is missing
      from clk-vf610 clock driver right now.  And clk-vf610 driver mistakenly
      supplies RMII clock (50 MHz) as the source to fec.  This results in the
      situation that fec driver gets ref_freq as 50 MHz, while physically it
      runs at 66 MHz (fec module clock physically sources from ipg which runs
      at 66 MHz).  That's why software expects MDC runs at 2.5 MHz, while the
      measurement tells it runs at 3.3 MHz.  And this causes the PHY KSZ8041
      keeps swithing between Full and Half mode as below.
      
        libphy: 400d0000.etherne:00 - Link is Up - 100/Full
        libphy: 400d0000.etherne:00 - Link is Up - 100/Half
        libphy: 400d0000.etherne:00 - Link is Up - 100/Full
        libphy: 400d0000.etherne:00 - Link is Up - 100/Half
        libphy: 400d0000.etherne:00 - Link is Up - 100/Full
        libphy: 400d0000.etherne:00 - Link is Up - 100/Half
      
      Add the missing module clock for ENET0 and ENET1, and correct the clock
      supplying in device tree to fix above issue.
      
      Thanks to Alison Wang <b18965@freescale.com> for debugging the issue.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      4f71612e
    • L
      ARM: i.MX6Q: correct emi_sel clock muxing · 3b79cd15
      Liu Ying 提交于
      The correct muxing for emi_sel clock should be
      2b'00 - 396M PFD
      2b'01 - PLL3
      2b'10 - AXI clk root
      2b'11 - 352M PFD
      
      This patch corrects the muxing in the clock driver.
      Signed-off-by: NLiu Ying <Ying.Liu@freescale.com>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
      3b79cd15
    • A
      ARM: i.MX27: Typo fix · 0d5ca6d9
      Alexander Shiyan 提交于
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      0d5ca6d9
    • P
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the ARM uses of the __cpuinit macros from C code,
      and all __CPUINIT from assembly code.  It also had two ".previous"
      section statements that were paired off against __CPUINIT
      (aka .section ".cpuinit.text") that also get removed here.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  4. 10 7月, 2013 1 次提交
  5. 27 6月, 2013 1 次提交
  6. 24 6月, 2013 2 次提交
  7. 21 6月, 2013 1 次提交
  8. 17 6月, 2013 17 次提交