1. 17 1月, 2015 2 次提交
  2. 14 1月, 2015 1 次提交
    • S
      net: fec: fix MDIO bus assignement for dual fec SoC's · 3d125f9c
      Stefan Agner 提交于
      On i.MX28, the MDIO bus is shared between the two FEC instances.
      The driver makes sure that the second FEC uses the MDIO bus of the
      first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
      However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
      has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
      is not an option since other logic, triggered by this quirk, is
      still needed.
      
      Furthermore, there are board designs which use the same MDIO bus
      for both PHY's even though the second bus would be available on the
      SoC side. Such layout are popular since it saves pins on SoC side.
      Due to the above quirk, those boards currently do work fine. The
      boards in the mainline tree with such a layout are:
      - Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
      - Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)
      
      This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
      makes sure that the MDIO bus of the first FEC is used in any case.
      
      However, the boards above do have a SoC with a MDIO bus for each FEC
      instance. But the PHY's are not connected in a 1:1 configuration. A
      proper device tree description is needed to allow the driver to
      figure out where to find its PHY. This patch fixes that shortcoming
      by adding a MDIO bus child node to the first FEC instance, along
      with the two PHY's on that bus, and making use of the phy-handle
      property to add a reference to the PHY's.
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d125f9c
  3. 12 1月, 2015 3 次提交
  4. 09 1月, 2015 1 次提交
  5. 07 1月, 2015 4 次提交
  6. 06 1月, 2015 2 次提交
    • F
      ARM: dts: imx51-babbage: Fix ULPI PHY reset modelling · 7a9f0604
      Fabio Estevam 提交于
      GPIO2_5 is the reset GPIO for the USB3317 ULPI PHY. Instead of modelling it as
      a regulator, the correct approach is to use the 'reset_gpios' property of the
      "usb-nop-xceiv" node.
      
      GPIO1_7 is the reset GPIO for the USB2517 USB hub. As we currently don't have
      dt bindings to describe a HUB reset, let's keep using the regulator approach.
      
      Rename the regulator to 'reg_hub_reset' to better describe its function and bind
      it with the USB host1 port instead.
      
      USB host support has been introduced by commit 9bf206a9 ("ARM: dts:
      imx51-babbage: Add USB Host1 support"), which landed in 3.16 and it seems that
      USB has only been functional due to previous bootloader initialization.
      
      With this patch applied we can get USB host to work without relying on the
      bootloader.
      
      Cc: <stable@vger.kernel.org> # 3.16+
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      7a9f0604
    • M
      ARM: dts: dra7-evm: fix qspi device tree partition size · 69d2626f
      Mugunthan V N 提交于
      64KiB is allocated for qspi dtb partition which is not
      sufficient, so updating the partition table size to 512KiB
      for device tree partition.
      
      This also aligns the QSPI partition definitions between
      kernel and U-Boot.
      
      Fixes: dc2dd5b8 ("ARM: dts: dra7: Add qspi device")
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      69d2626f
  7. 29 12月, 2014 3 次提交
  8. 21 12月, 2014 2 次提交
    • D
      ARM: dts: rockchip: bump sd card pin drive strength up on rk3288-evb · 6618e478
      Doug Anderson 提交于
      It seems that ever since (536f6b91 mmc: dw_mmc: Reset DMA before
      enabling IDMAC) landed upstream that SD cards have been very unhappy
      on rk3288-evb.  They were a little unhappy before that change, but
      after that change they're REALLY unhappy.
      
      It turns out that the above fix happens to fix a corruption when
      reading card information during probe time.  Without the fix we didn't
      detect that high speed SD cards could actually support high speed.
      With the fix we suddenly detect that they're high speed and we try to
      use them at 50MHz.  That doesn't work so well on EVB with the default
      drive strength (maybe because there are two physical SD card slots
      hooked up to the same pin?).
      
      Fix the problem by bumping up the drive strength of the sdmmc lines.
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Fixes: 536f6b91 ("mmc: dw_mmc: Reset DMA before enabling IDMAC")
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      6618e478
    • G
      ARM: mvebu: Fix pinctrl configuration for Armada 370 DB · d4b0833a
      Gregory CLEMENT 提交于
      The commit b4607572 (ARM: mvebu: remove conflicting muxing on
      Armada 370 DB) removes the hog pins muxing. As it is explained in the
      commit log it solves a warning a boot time, but more important it also
      allows using the Giga port 0 of the board.
      
      Unfortunately in the same time the commit 4904a82a (arm: mvebu:
      move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was
      merged and it introduced again the hog pins muxing. Because of it, the
      Giga port 0 of the board is no more usable.
      
      This commit remove again the conflicting muxing (hopefully for the
      last time).
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      [andrew@lunn.ch: Correct commit IDs]
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Fixes: 4904a82a ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
      d4b0833a
  9. 11 12月, 2014 8 次提交
  10. 06 12月, 2014 1 次提交
  11. 05 12月, 2014 6 次提交
  12. 04 12月, 2014 7 次提交