Skip to content

L
linux
Switch branch/tag
  1. 11 Jan, 2017 4 commits
  3. 09 Jan, 2017 5 commits
    • Nishanth Menon's avatar
      pinctrl: Introduce TI IOdelay configuration driver · 003910eb
      Nishanth Menon authored 
      SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), a separate
hardware module called IODelay which is also expected to be configured.
The "IODelay" module has it's own register space that is independent
of the control module and the padconf register area.

With recent changes to the pinctrl framework, we can now support
this hardware with a reasonably minimal driver by using #pinctrl-cells,
GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.

It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).

NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.

Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.

In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.

IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
to 0x0 at all times, even when configuring Manual IO Timing Modes.
This is done by eliminating the LOCK_BIT=1 setting from Step
of the Manual IO timing Mode configuration procedure. This option
leaves the CFG_* registers unprotected from unintended writes to the
CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.

This approach is taken to allow for a generic driver to exist in kernel
world that has to be used carefully in required usecases.
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
[tony@atomide.com: updated to use generic pinctrl functions, added
 binding documentation, updated comments]
Acked-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      003910eb
    • Tony Lindgren's avatar
      pinctrl: core: Make dt_free_map optional · 92c2b671
      Tony Lindgren authored 
      If the pin controller driver is using devm_kzalloc, there may not be
anything to do for dt_free_map. Let's make it optional to avoid
unncessary boilerplate code.
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      92c2b671
    • Maxime Ripard's avatar
      pinctrl: sunxi: Remove old sun5i pinctrl drivers · d83bb5a4
      Maxime Ripard authored 
      Now that we have a common pinctrl driver for all the sun5i SoCs, we can
remove the old, separate drivers.
Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d83bb5a4
    • Maxime Ripard's avatar
      pinctrl: sunxi: Add common sun5i pinctrl driver · 858f559f
      Maxime Ripard authored 
      The sun5i SoCs (A10s, A13, GR8) are all based on the same die fit in
different packages. Hence, the pins and functions available are just the
based on the same set, each SoC having a different subset.

Introduce a common pinctrl driver that supports multiple variants to allow
to put as much as we can in common.
Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      858f559f
    • Maxime Ripard's avatar
      pinctrl: sunxi: Add pinctrl variants · 578db85f
      Maxime Ripard authored 
      Some SoCs are either supposed to be pin compatible (A10 and A20 for
example), or are just repackaged versions of the same die (A10s, A13, GR8).

In those case, having a full blown pinctrl driver just introduces
duplication in both data size and maintainance effort.

Add a variant option to both pins and functions to be able to limit the
pins and functions described only to a subset of the SoC we support with a
given driver.
Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      578db85f
  5. 05 Jan, 2017 1 commit
    • Jon Hunter's avatar
      pinctrl: Fix panic when pinctrl devices with hogs are unregistered · 3429fb3c
      Jon Hunter authored 
      Commit df61b366af26 ('pinctrl: core: Use delayed work for hogs')
deferred part of the registration for pinctrl devices if the pinctrl
device has hogs. This introduced a window where if the pinctrl device
with hogs was sucessfully registered, but then unregistered again
(which could be caused by parent device being probe deferred) before
the delayed work has chanced to run, then this will cause a kernel
panic to occur because:

1. The 'pctldev->p' has not yet been initialised and when unregistering
   the pinctrl device we only check to see if it is an error value, but
   now it could also be NULL.
2. The pinctrl device may not have been added to the 'pinctrldev_list'
   list and we don't check to see if it was added before removing.

Fix up the above by checking to see if the 'pctldev->p' pointer is an
error value or NULL before putting the pinctrl device and verifying
that the pinctrl device is present in 'pinctrldev_list' before removing.

Fixes: df61b366af26 ('pinctrl: core: Use delayed work for hogs')
Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3429fb3c
  7. 03 Jan, 2017 11 commits
  9. 30 Dec, 2016 9 commits
  11. 28 Dec, 2016 3 commits
  13. 27 Dec, 2016 3 commits
  15. 26 Dec, 2016 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc1 · 7ce7d89f
      Linus Torvalds authored
      7ce7d89f
    • Larry Finger's avatar
      powerpc: Fix build warning on 32-bit PPC · 8ae679c4
      Larry Finger authored 
      I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:

    AS      arch/powerpc/kernel/misc_32.o
  arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]

This problem is evident after commit 989cea5c ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created.  That was with commit 9994a338 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").

The offending line does not make a lot of sense.  This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.

Thanks to Nicholas Piggin for suggesting this solution.

Fixes: 9994a338 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ae679c4
  17. 25 Dec, 2016 2 commits
    • Linus Torvalds's avatar
      avoid spurious "may be used uninitialized" warning · d33d5a6c
      Linus Torvalds authored 
      The timer type simplifications caused a new gcc warning:

  drivers/base/power/domain.c: In function ‘genpd_runtime_suspend’:
  drivers/base/power/domain.c:562:14: warning: ‘time_start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));

despite the actual use of "time_start" not having changed in any way.
It appears that simply changing the type of ktime_t from a union to a
plain scalar type made gcc check the use.

The variable wasn't actually used uninitialized, but gcc apparently
failed to notice that the conditional around the use was exactly the
same as the conditional around the initialization of that variable.

Add an unnecessary initialization just to shut up the compiler.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d33d5a6c
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 3ddc76df
      Linus Torvalds authored 
      Pull timer type cleanups from Thomas Gleixner:
 "This series does a tree wide cleanup of types related to
  timers/timekeeping.

   - Get rid of cycles_t and use a plain u64. The type is not really
     helpful and caused more confusion than clarity

   - Get rid of the ktime union. The union has become useless as we use
     the scalar nanoseconds storage unconditionally now. The 32bit
     timespec alike storage got removed due to the Y2038 limitations
     some time ago.

     That leaves the odd union access around for no reason. Clean it up.

  Both changes have been done with coccinelle and a small amount of
  manual mopping up"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  ktime: Get rid of ktime_equal()
  ktime: Cleanup ktime_set() usage
  ktime: Get rid of the union
  clocksource: Use a plain u64 instead of cycle_t
      3ddc76df
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7