1. 14 Jul, 2016 6 commits
    • Jon Hunter's avatar
      drm/tegra: sor: Prepare for generic PM domain support · f8c79120
      Jon Hunter authored
      The SOR driver for Tegra requires the SOR power partition to be enabled.
      Now that Tegra supports the generic PM domain framework we manage the
      SOR power partition via this framework. However, the sequence for
      gating/ungating the SOR power partition requires that the SOR reset is
      asserted/de-asserted at the time the SOR power partition is
      gated/ungated, respectively. Now that the reset control core assumes
      that resets are exclusive, the Tegra generic PM domain code and the SOR
      driver cannot request the same reset unless we mark the reset as shared.
      Sharing resets will not work in this case because we cannot guarantee
      that the reset will be asserted/de-asserted at the appropriate time.
      Therefore, given that the Tegra generic PM domain code will handle the
      resets, do not request the reset in the SOR driver if the SOR device has
      a PM domain associated.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      f8c79120
    • Jon Hunter's avatar
      drm/tegra: dsi: Prepare for generic PM domain support · 64230aa0
      Jon Hunter authored
      The DSI driver for Tegra requires the SOR power partition to be enabled.
      Now that Tegra supports the generic PM domain framework we manage the
      SOR power partition via this framework. However, the sequence for
      gating/ungating the SOR power partition requires that the DSI reset is
      asserted/de-asserted at the time the SOR power partition is
      gated/ungated, respectively. Now that the reset control core assumes
      that resets are exclusive, the Tegra generic PM domain code and the DSI
      driver cannot request the same reset unless we mark the reset as shared.
      Sharing resets will not work in this case because we cannot guarantee
      that the reset will be asserted/de-asserted at the appropriate time.
      Therefore, given that the Tegra generic PM domain code will handle the
      resets, do not request the reset in the DSI driver if the DSI device has
      a PM domain associated.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      64230aa0
    • Thierry Reding's avatar
      drm/tegra: sor: Make XBAR configurable per SoC · 30b49435
      Thierry Reding authored
      Provide a per-SoC mapping of lanes which can be used to configure the
      XBAR.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      30b49435
    • Thierry Reding's avatar
      drm/tegra: sor: Use sor1_src clock to set parent for HDMI · 618dee39
      Thierry Reding authored
      When running in HDMI mode, the sor1 IP block needs to use the sor1_src
      as parent clock, and in turn configure the sor1_src to use pll_d2_out0
      as its parent.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      618dee39
    • Thierry Reding's avatar
      dt-bindings: display: tegra: Add source clock for SOR · 5d2304c1
      Thierry Reding authored
      The SOR clock can have various sources, with the most commonly used
      being the sor_safe, pll_d2_out0, pll_dp and sor_brick clocks. These
      are configured using a three level mux, of which the first 2 levels
      can be treated as one. The direct parents of the SOR clock are the
      sor_safe, sor_brick and sor_src clocks, whereas the pll_d2_out0 and
      pll_dp clocks can be selected as parents of the sor_src clock via a
      second mux.
      
      Previous generations of Tegra have only supported eDP and LVDS with
      the SOR, where LVDS was never used on publicly available hardware.
      Clocking for this only ever required the first level mux (to select
      between sor_safe and sor_brick).
      
      Tegra210 has a new revision of the SOR that supports HDMI and hence
      needs to support the second level mux to allow selecting pll_d2_out0
      as the SOR clock's parent. This second mux is knows as sor_src, and
      operating system software needs a reference to it in order to select
      the proper parent.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      5d2304c1
    • Thierry Reding's avatar
      drm/tegra: sor: Implement sor1_brick clock · b299221c
      Thierry Reding authored
      sor1_brick is a clock that can be used as a source for the sor1 clock.
      The registers to control the clock output are part of the sor1 IP block
      and hence the sor driver is the best place to implement it.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      b299221c
  2. 04 Jul, 2016 7 commits
  3. 01 Jul, 2016 3 commits
  4. 30 Jun, 2016 6 commits
    • Jon Hunter's avatar
      drm/tegra: dpaux: Add pinctrl support · 0751bb5c
      Jon Hunter authored
      The DPAUX pins are shared with an internal I2C controller. To allow
      these pins to be muxed to the I2C controller, register a pinctrl device
      for the DPAUX device.
      
      This is based upon work by Thierry Reding <treding@nvidia.com>.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      0751bb5c
    • Jon Hunter's avatar
      dt-bindings: Add bindings for Tegra DPAUX pinctrl driver · 6cb68e46
      Jon Hunter authored
      On Tegra124, Tegra132 and Tegra210 devices the pads used by the Display
      Port Auxiliary (DPAUX) channel are multiplexed such that they can also
      be used by one of the internal I2C controllers. Note that this is
      different from I2C-over-AUX supported by the DPAUX controller. The
      register that configures these pads is part of the DPAUX controllers
      register set and so a pinctrl driver is being added for the DPAUX device
      to share these pads. Add the device-tree binding documentation for the
      DPAUX pad controller.
      
      Although there is only one group of pads associated with the DPAUX that
      can be multiplexed, the group still needs to be described by the binding.
      If the 'groups' property is not present in the binding, then the pads
      will not be allocated by the pinctrl core for a client and this would
      allow another client to re-configure the same pads that may already be
      in-use.
      
      Please note that although the "off" function for the DPAUX pads is not
      technically a pin-mux setting but more of a pin-conf setting it is
      simpler to expose these as a function so that the user can simply select
      either "aux", "i2c" or "off" as the current function/mode.
      
      Update the main DPAUX binding documentation to reference the DPAUX pad
      controller binding document and add the 'i2c-bus' subnode. The 'i2c-bus'
      subnode is used for populating I2C slaves for the DPAUX device so that
      the I2C driver core does not attempt to add the DPAUX pad controller
      nodes as I2C slaves.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      6cb68e46
    • Jon Hunter's avatar
      drm/tegra: Prepare DPAUX for supporting generic PM domains · 9b99044a
      Jon Hunter authored
      To utilise the DPAUX on Tegra, the SOR power partition must be enabled.
      Now that Tegra supports the generic PM domain framework we manage the
      SOR power partition via this framework for DPAUX. However, the sequence
      for gating/ungating the SOR power partition requires that the DPAUX
      reset is asserted/de-asserted at the time the SOR power partition is
      gated/ungated, respectively. Now that the reset control core assumes
      that resets are exclusive, the Tegra generic PM domain code and the
      DPAUX driver cannot request the same reset unless we mark the resets as
      shared. Sharing resets will not work in this case because we cannot
      guarantee that the reset will be asserted/de-asserted at the appropriate
      time. Therefore, given that the Tegra generic PM domain code will handle
      the DPAUX reset, do not request the reset in the DPAUX driver if the
      DPAUX device has a PM domain associated.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      9b99044a
    • Jon Hunter's avatar
      dt-bindings: display: Update Tegra DPAUX documentation · caf8a6c4
      Jon Hunter authored
      Update the DPAUX compatibility string information for Tegra124, Tegra132
      and Tegra210.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      caf8a6c4
    • Jon Hunter's avatar
      drm/tegra: dpaux: Add helpers for setting up pads · 9d0e09c1
      Jon Hunter authored
      In preparation for adding pinctrl support for the DPAUX pads, add a
      couple of helpers functions to configure the pads and control their
      power.
      
      Please note that although a simple if-statement could be used instead
      of a case statement for configuring the pads as there are only two
      possible modes, a case statement is used because when integrating with
      the pinctrl framework, we need to be able to handle invalid modes that
      could be passed.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      9d0e09c1
    • Jon Hunter's avatar
      drm/tegra: dpaux: Clean-up on probe failure · bcbd63df
      Jon Hunter authored
      If the probing of the DPAUX fails, then clocks are left enabled and the
      DPAUX reset de-asserted. Add code to perform the necessary clean-up on
      probe failure by disabling clocks and asserting the reset.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      bcbd63df
  5. 23 Jun, 2016 13 commits
  6. 29 May, 2016 3 commits
  7. 28 May, 2016 2 commits
    • Mikulas Patocka's avatar
      hpfs: implement the show_options method · 037369b8
      Mikulas Patocka authored
      The HPFS filesystem used generic_show_options to produce string that is
      displayed in /proc/mounts.  However, there is a problem that the options
      may disappear after remount.  If we mount the filesystem with option1
      and then remount it with option2, /proc/mounts should show both option1
      and option2, however it only shows option2 because the whole option
      string is replaced with replace_mount_options in hpfs_remount_fs.
      
      To fix this bug, implement the hpfs_show_options function that prints
      options that are currently selected.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      037369b8
    • Mikulas Patocka's avatar
      affs: fix remount failure when there are no options changed · 01d6e087
      Mikulas Patocka authored
      Commit c8f33d0b ("affs: kstrdup() memory handling") checks if the
      kstrdup function returns NULL due to out-of-memory condition.
      
      However, if we are remounting a filesystem with no change to
      filesystem-specific options, the parameter data is NULL.  In this case,
      kstrdup returns NULL (because it was passed NULL parameter), although no
      out of memory condition exists.  The mount syscall then fails with
      ENOMEM.
      
      This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
      
      The patch also changes the call to replace_mount_options - if we didn't
      pass any filesystem-specific options, we don't call
      replace_mount_options (thus we don't erase existing reported options).
      
      Fixes: c8f33d0b ("affs: kstrdup() memory handling")
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org	# v4.1+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      01d6e087