lkml.org 
[lkml]   [2012]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
    On Fri, Jan 13, 2012 at 10:16:36AM -0800, Stephen Warren wrote:
    ...
    > For reference, that message is:
    >
    > Linusw wrote:
    > > On Mon, Dec 5, 2011 at 3:43 AM, Dong Aisheng <dongas86 <at> gmail.com> wrote:
    > > > My current plan is to define all (might be frequently) used functoin
    > > > and groups for the exist upstreamed board like 53 Loco and etc, is
    > > > that ok?
    > >
    > > Yes, but do it in respective board file, so if we say, one day
    > > stops to support a certain board we can just delete that board
    > > file and be done with it.
    > >
    > > Plus this gives us a nice separation as we move toward
    > > device trees. (I think.)
    >
    > My interpretation of what Dong wrote there is "I'm only going to define
    > the functions and groups that are actually in use by upstream boards,
    > not everything the SoC supports". However, your (Shawn's) references to
    > the email, it sounds like you're interpreting what Dong wrong as "I'm
    > going to define some virtual groups that don't exist in HW but represent
    > common use-cases of the HW".
    >
    Then what does the word 'groups' in Dong's sentence means with your
    understanding, considering there is no HW level pingroup on imx?

    > Admittedly, the wording of Linusw's actually seems to agree more with how
    > you're interpreting what Dong said, but in that case, I don't think his
    > reply makes sense - the whole purpose of the mux mapping table is to
    > represent the board-specific configuration. If we're going to circumvent
    > it, we should completely remove it from the pinctrl subsystem, rather than
    > having some boards avoid using it by creating virtual pin groups instead.
    >
    IMO, it's a compromise. It still makes sense to have concept of
    pingroup in pinctrl subsystem, because platforms like Tegra have
    the HW pingroup.

    > > > > For imx6q example, we have 193 pins as the muxable entities, and for
    > > > > each of those pin, there are 8 alternative functions. Let's see what
    > > > > we will have if we enumerate all the available functions for each pin.
    > ...
    > > > > We simply do not want to over bloat imx6q pinctrl driver with such
    > > > > enumeration.
    > > >
    > > > Yes, I see you'd end up with a huge number of function definitions here.
    > > >
    > > > You may be able to avoid this by changing the way you name/number the
    > > > functions though.
    > > >
    > > > The example above has a unique function name for every individual signal.
    > > > instead, can you name functions based on the controller they connect to?
    > > >
    > > > So, instead of having:
    > > >
    > > > IMX6Q_PAD_SD2_DAT1__USDHC2_DAT1
    > > > IMX6Q_PAD_SD2_DAT2__USDHC2_DAT2
    > > > IMX6Q_PAD_SD2_DAT3__USDHC2_DAT3
    > > > IMX6Q_PAD_SD2_DAT4__USDHC2_DAT4
    > > >
    > > > Can you replace this with a single:
    > > >
    > > > IMX_FUNC_USDHC2
    > >
    > > So all 'enum imx6q_pad_*' goes away, and instead, we define macros
    > > IMX_FUNC_* at controller basis, correct?
    >
    > Yes, something like that. The best set to choose probably differs based
    > on the SoC and its mux capabilities. But thinking more, if you're going
    > along this kind of route, I'd prefer to just define the "func0", "func1",
    > ... "func7" functions that represent the raw HW selection instead.
    >
    In this case, I do not see any point to define them, since it does not
    make too much difference than integer 0, 1, ..., 7.

    --
    Regards,
    Shawn


    \
     
     \ /
      Last update: 2012-01-14 02:13    [W:8.310 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site