<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/include/linux/pinctrl, branch v3.8</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=v3.8</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=v3.8'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2012-11-21T07:55:26+00:00</updated>
<entry>
<title>pinctrl: generic: add input schmitt disable parameter</title>
<updated>2012-11-21T07:55:26+00:00</updated>
<author>
<name>Haojian Zhuang</name>
<email>haojian.zhuang@gmail.com</email>
</author>
<published>2012-11-15T08:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=2ccb0bcfb0dd2001b1a40048c1e407cd9a78bd3d'/>
<id>urn:sha1:2ccb0bcfb0dd2001b1a40048c1e407cd9a78bd3d</id>
<content type='text'>
In Marvell PXA/MMP silicons, input schmitt disable value is 0x40, not 0.
So append new config parameter -- input schmitt disable.

Signed-off-by: Haojian Zhuang &lt;haojian.zhuang@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: add function to retrieve range from pin</title>
<updated>2012-11-21T07:55:12+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2012-11-20T13:25:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=9afbefb227792a3c195085d662050dcca748f521'/>
<id>urn:sha1:9afbefb227792a3c195085d662050dcca748f521</id>
<content type='text'>
This adds a function to the pinctrl core to retrieve the GPIO
range associated with a certain pin for a certain controller.
This is needed when a pinctrl driver want to look up the
corresponding struct gpio_chip for a certain pin. As the
GPIO drivers can now create these ranges themselves, the
pinctrl driver no longer knows about all its associated GPIO
chips.

Reviewed-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: rename find_pinctrl_*</title>
<updated>2012-11-21T07:55:10+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2012-11-20T13:03:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=192c369c6165dff233f22aa70209a92b030d233d'/>
<id>urn:sha1:192c369c6165dff233f22aa70209a92b030d233d</id>
<content type='text'>
Rename the function find_pinctrl_and_add_gpio_range()
to pinctrl_find_and_add_gpio_range() so as to be consistent
with the rest of the functions.

Reviewed-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: separation of pin concerns</title>
<updated>2012-11-11T18:06:07+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2012-11-06T15:03:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=1e63d7b9363f0c57d00991f9f2e0af374dfc591a'/>
<id>urn:sha1:1e63d7b9363f0c57d00991f9f2e0af374dfc591a</id>
<content type='text'>
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.

So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.

This is done by:

- Adding a return code to gpiochip_add_pin_range() so we can
  reliably check whether this succeeds.

- Get rid of the custom of_pinctrl_add_gpio_range() from
  pinctrl. Instead create of_pinctrl_get() to just retrive the
  pin controller per se from an OF node. This composite
  function was just begging to be deleted, it was way to
  purpose-specific.

- Use pinctrl_dev_get_name() to get the name of the retrieved
  pin controller and use that to call back into the generic
  gpiochip_add_pin_range().

Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: provide provision to register pin ranges</title>
<updated>2012-11-11T18:06:00+00:00</updated>
<author>
<name>Shiraz Hashim</name>
<email>shiraz.hashim@st.com</email>
</author>
<published>2012-10-27T09:51:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=f23f1516b6757c326cc638bed8c402c77e2a596e'/>
<id>urn:sha1:f23f1516b6757c326cc638bed8c402c77e2a596e</id>
<content type='text'>
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.

As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.

After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

Cc: Grant Likely &lt;grant.likely@secretlab.ca&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Shiraz Hashim &lt;shiraz.hashim@st.com&gt;
[Edited documentation a bit]
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>Revert "pinctrl: remove pinctrl_remove_gpio_range"</title>
<updated>2012-11-11T18:05:59+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2012-10-27T09:51:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=7e10ee68f8ccc62e0934ff02f39ce541f3879844'/>
<id>urn:sha1:7e10ee68f8ccc62e0934ff02f39ce541f3879844</id>
<content type='text'>
This reverts earlier commit which removed
pinctrl_remove_gpio_range(), because at that time there
weren't any more users of that routine. It was removed as the
removal of ranges was done in unregister of pinctrl.

But as we are now registering stuff from gpiolib, we may
remove and insert a gpio module multiple times. So, we
need this routine again.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'uapi-prep-20121002' of git://git.infradead.org/users/dhowells/linux-headers</title>
<updated>2012-10-03T20:45:43+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-10-03T20:45:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=9b2e077c42a97fcbdc0dd71edb1fc9d15c74ad29'/>
<id>urn:sha1:9b2e077c42a97fcbdc0dd71edb1fc9d15c74ad29</id>
<content type='text'>
Pull preparatory patches for user API disintegration from David Howells:
 "The patches herein prepare for the extraction of the Userspace API
  bits from the various header files named in the Kbuild files.

  New subdirectories are created under either include/uapi/ or
  arch/x/include/uapi/ that correspond to the subdirectory containing
  that file under include/ or arch/x/include/.

  The new subdirs under the uapi/ directory are populated with Kbuild
  files that mostly do nothing at this time.  Further patches will
  disintegrate the headers in each original directory and fill in the
  Kbuild files as they do it.

  These patches also:

   (1) fix up #inclusions of "foo.h" rather than &lt;foo.h&gt;.

   (2) Remove some redundant #includes from the DRM code.

   (3) Make the kernel build infrastructure handle Kbuild files both in
       the old places and the new UAPI place that both specify headers
       to be exported.

   (4) Fix some kernel tools that #include kernel headers during their
       build.

  I have compile tested this with allyesconfig against x86_64,
  allmodconfig against i386 and a scattering of additional defconfigs of
  other arches.  Prepared for main script

  Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
  Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
  Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
  Acked-by: Michael Kerrisk &lt;mtk.manpages@gmail.com&gt;
  Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
  Acked-by: Dave Jones &lt;davej@redhat.com&gt;
  Acked-by: H. Peter Anvin &lt;hpa@zytor.com&gt;"

* tag 'uapi-prep-20121002' of git://git.infradead.org/users/dhowells/linux-headers:
  UAPI: Plumb the UAPI Kbuilds into the user header installation and checking
  UAPI: x86: Differentiate the generated UAPI and internal headers
  UAPI: Remove the objhdr-y export list
  UAPI: Move linux/version.h
  UAPI: Set up uapi/asm/Kbuild.asm
  UAPI: x86: Fix insn_sanity build failure after UAPI split
  UAPI: x86: Fix the test_get_len tool
  UAPI: (Scripted) Set up UAPI Kbuild files
  UAPI: Partition the header include path sets and add uapi/ header directories
  UAPI: (Scripted) Convert #include "..." to #include &lt;path/...&gt; in kernel system headers
  UAPI: (Scripted) Convert #include "..." to #include &lt;path/...&gt; in drivers/gpu/
  UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
  UAPI: Refer to the DRM UAPI headers with &lt;...&gt; and from certain headers only
</content>
</entry>
<entry>
<title>UAPI: (Scripted) Convert #include "..." to #include &lt;path/...&gt; in kernel system headers</title>
<updated>2012-10-02T17:01:25+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2012-10-02T17:01:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=a1ce39288e6fbefdd8d607021d02384eb4a20b99'/>
<id>urn:sha1:a1ce39288e6fbefdd8d607021d02384eb4a20b99</id>
<content type='text'>
Convert #include "..." to #include &lt;path/...&gt; in kernel system headers.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Acked-by: Dave Jones &lt;davej@redhat.com&gt;
</content>
</entry>
<entry>
<title>pinctrl: clarify idle vs sleep states</title>
<updated>2012-10-01T06:04:52+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2012-09-26T12:59:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=b0e181d0944e858ae0cacf808752e791894c5651'/>
<id>urn:sha1:b0e181d0944e858ae0cacf808752e791894c5651</id>
<content type='text'>
This pure documentation fix tries to align the "idle" and
"sleep" pin states to the idle and suspend states from
runtime PM.

Cc: Patrice Chotard &lt;patrice.chotard@st.com&gt;
Acked-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: use ERR_CAST instead of ERR_PTR(PTR_ERR(...))</title>
<updated>2012-09-03T11:21:37+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2012-07-30T16:38:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=e60bc2df9ba5574af87a8d0fa249ceac9fa1d3bd'/>
<id>urn:sha1:e60bc2df9ba5574af87a8d0fa249ceac9fa1d3bd</id>
<content type='text'>
This doesn't change semantics, just looks nicer.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
</feed>
