lkml.org 
[lkml]   [2013]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/3 v3] pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x.
    From
    Hi Linus,

    On Thu, Aug 29, 2013 at 4:19 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
    > On Thu, Aug 22, 2013 at 10:48 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
    >> On 08/22/2013 01:07 AM, Sonic Zhang wrote:
    >>>
    >>> There are 6 to 9 GPIO HW blocks in one Blackfin SoC. Function
    >>> pinmux_enable_setting() in current pinctrl framework assumes the
    >>> function mux setting of one peripheral pin group is configured in one
    >>> pinctrl device. But, the function mux setting of one blackfin
    >>> peripheral may be done among different GPIO HW blocks. So, I have to
    >>> separate the pinctrl driver from the GPIO block driver add the ranges
    >>> of all GPIO blocks into one pinctrl device for Blackfin.
    >>
    >> I don't think you need separate device; the pin control mapping table
    >> entries for a particular state simply needs to include entries for
    >> multiple pin controllers.
    >
    > So splitting each block into a separate pin control device is definately
    > one way to skin the cat.
    >
    > The ux500 would then have 9 pin controller instances (after a
    > big fat refactoring, but whatever) instead of 9 GPIO instances
    > and one pinctrl instance referencing them. Also this solves
    > the problem of registering GPIO ranges from the wrong end
    > of the pin controller.
    >
    > Hm, I should try this and see where it goes... What do you
    > think about this Sonic?

    As I discussed with Stephen:

    To separate the pinctrl_settings of one peripheral to multiple pinctrl
    devices, multiple pinctrl group arrays and function arrays should be
    defined in the soc data file. This change increases the code size of
    the soc data file a lot without get any real benefits.

    The pin controller device can be defined as a logic device to cover
    many gpio devices, which are mapped into the same pin id space without
    collision. All overhead in the soc data file can be removed in this
    way. GPIO devices with pin id region collision should be put into
    different pin controller devices.

    So, I think it is fine to either binding pinctrl device to gpio device
    or leave it as a logic device.

    Regards,

    Sonic


    \
     
     \ /
      Last update: 2013-08-29 14:01    [W:6.890 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site