All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra
Date: Fri, 9 Dec 2011 09:07:22 -0800	[thread overview]
Message-ID: <20111209170722.GO31337@atomide.com> (raw)
In-Reply-To: <CACRpkdYDn0V7SeQuFiFDMxGkybvg6PGf7jxid8ECGB7Azkj3zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [111209 05:29]:
> On Thu, Dec 8, 2011 at 11:13 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > This adds a driver for the Tegra pinmux, and required parameterization
> > data for Tegra20 and Tegra30.
> >
> > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> This is looking good from a framework point of view (obviously,
> since you've designed the framework with me you sure know what
> you're doing).
> 
> What we could worry about is the amount of hard-coded chip data
> which sort of correlates with the discussion with Tony on how to
> provide DT info for pin control drivers.
> 
> If say this same controller appear in Tegra 4 with no changes but
> different pin names, it makes sense to try to push this into the
> DT as soon as possible, so as to avoid the situation Tony is
> having with the OMAP muxes. If Tegra 4 will be all-new and not even
> related, it doesn't.
> 
> So, just think a bit about it.
> 
> It will fit way better here than any place under
> arch/arm/* in any case, so it's a great achievement!

Sorry I still need some more time with pinmux-simple.c, will have
to get pending omap patches merged first. Just want to recap the
findings so far:

- We can have automatically generated device to pinmux driver
  mapping from DT, so that's nice

- Describing pins for each driver in DT is still open.. And
  using mixed-property arrays in DT won't nicely as the data
  gets unaligned easily with string properties..

- We currently have hard time supporting pin groups with pins
  coming from multiple pinmux driver instances

- Mixing pinmux data from various sources is still open; Some
  pinmux data may need to be static, some come from DT, some
  come from loadable modules or even /lib/firmware if the data
  gets insanely big. Basically we may not always have a phandle
  in DT data for the pinmux function, and should somehow allow
  also using names there

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra
Date: Fri, 9 Dec 2011 09:07:22 -0800	[thread overview]
Message-ID: <20111209170722.GO31337@atomide.com> (raw)
In-Reply-To: <CACRpkdYDn0V7SeQuFiFDMxGkybvg6PGf7jxid8ECGB7Azkj3zw@mail.gmail.com>

* Linus Walleij <linus.walleij@linaro.org> [111209 05:29]:
> On Thu, Dec 8, 2011 at 11:13 PM, Stephen Warren <swarren@nvidia.com> wrote:
> 
> > This adds a driver for the Tegra pinmux, and required parameterization
> > data for Tegra20 and Tegra30.
> >
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> 
> This is looking good from a framework point of view (obviously,
> since you've designed the framework with me you sure know what
> you're doing).
> 
> What we could worry about is the amount of hard-coded chip data
> which sort of correlates with the discussion with Tony on how to
> provide DT info for pin control drivers.
> 
> If say this same controller appear in Tegra 4 with no changes but
> different pin names, it makes sense to try to push this into the
> DT as soon as possible, so as to avoid the situation Tony is
> having with the OMAP muxes. If Tegra 4 will be all-new and not even
> related, it doesn't.
> 
> So, just think a bit about it.
> 
> It will fit way better here than any place under
> arch/arm/* in any case, so it's a great achievement!

Sorry I still need some more time with pinmux-simple.c, will have
to get pending omap patches merged first. Just want to recap the
findings so far:

- We can have automatically generated device to pinmux driver
  mapping from DT, so that's nice

- Describing pins for each driver in DT is still open.. And
  using mixed-property arrays in DT won't nicely as the data
  gets unaligned easily with string properties..

- We currently have hard time supporting pin groups with pins
  coming from multiple pinmux driver instances

- Mixing pinmux data from various sources is still open; Some
  pinmux data may need to be static, some come from DT, some
  come from loadable modules or even /lib/firmware if the data
  gets insanely big. Basically we may not always have a phandle
  in DT data for the pinmux function, and should somehow allow
  also using names there

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@nvidia.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org
Subject: Re: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra
Date: Fri, 9 Dec 2011 09:07:22 -0800	[thread overview]
Message-ID: <20111209170722.GO31337@atomide.com> (raw)
In-Reply-To: <CACRpkdYDn0V7SeQuFiFDMxGkybvg6PGf7jxid8ECGB7Azkj3zw@mail.gmail.com>

* Linus Walleij <linus.walleij@linaro.org> [111209 05:29]:
> On Thu, Dec 8, 2011 at 11:13 PM, Stephen Warren <swarren@nvidia.com> wrote:
> 
> > This adds a driver for the Tegra pinmux, and required parameterization
> > data for Tegra20 and Tegra30.
> >
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> 
> This is looking good from a framework point of view (obviously,
> since you've designed the framework with me you sure know what
> you're doing).
> 
> What we could worry about is the amount of hard-coded chip data
> which sort of correlates with the discussion with Tony on how to
> provide DT info for pin control drivers.
> 
> If say this same controller appear in Tegra 4 with no changes but
> different pin names, it makes sense to try to push this into the
> DT as soon as possible, so as to avoid the situation Tony is
> having with the OMAP muxes. If Tegra 4 will be all-new and not even
> related, it doesn't.
> 
> So, just think a bit about it.
> 
> It will fit way better here than any place under
> arch/arm/* in any case, so it's a great achievement!

Sorry I still need some more time with pinmux-simple.c, will have
to get pending omap patches merged first. Just want to recap the
findings so far:

- We can have automatically generated device to pinmux driver
  mapping from DT, so that's nice

- Describing pins for each driver in DT is still open.. And
  using mixed-property arrays in DT won't nicely as the data
  gets unaligned easily with string properties..

- We currently have hard time supporting pin groups with pins
  coming from multiple pinmux driver instances

- Mixing pinmux data from various sources is still open; Some
  pinmux data may need to be static, some come from DT, some
  come from loadable modules or even /lib/firmware if the data
  gets insanely big. Basically we may not always have a phandle
  in DT data for the pinmux function, and should somehow allow
  also using names there

Regards,

Tony

  parent reply	other threads:[~2011-12-09 17:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-08 22:13 [RFC 0/3] pinctrl: add a driver for NVIDIA Tegra Stephen Warren
2011-12-08 22:13 ` Stephen Warren
2011-12-08 22:13 ` Stephen Warren
2011-12-08 22:13 ` [RFC 1/3] " Stephen Warren
     [not found]   ` <1323382390-14892-2-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-12-09 14:01     ` Linus Walleij
2011-12-09 14:01       ` Linus Walleij
2011-12-09 14:01       ` Linus Walleij
     [not found]       ` <CACRpkdYDn0V7SeQuFiFDMxGkybvg6PGf7jxid8ECGB7Azkj3zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-09 17:07         ` Tony Lindgren [this message]
2011-12-09 17:07           ` Tony Lindgren
2011-12-09 17:07           ` Tony Lindgren
2011-12-09 23:49           ` Linus Walleij
2011-12-09 23:49             ` Linus Walleij
     [not found]             ` <CACRpkdaco=967cKHUcj9VNKc_HyT7Mw30Z9HVdfgsUsHbps8bQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-11 19:36               ` Tony Lindgren
2011-12-11 19:36                 ` Tony Lindgren
2011-12-11 19:36                 ` Tony Lindgren
2011-12-09 17:28         ` Stephen Warren
2011-12-09 17:28           ` Stephen Warren
2011-12-09 17:28           ` Stephen Warren
     [not found]           ` <74CDBE0F657A3D45AFBB94109FB122FF17518604D7-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-12-09 18:00             ` Tony Lindgren
2011-12-09 18:00               ` Tony Lindgren
2011-12-09 18:00               ` Tony Lindgren
2011-12-09 23:55             ` Linus Walleij
2011-12-09 23:55               ` Linus Walleij
2011-12-09 23:55               ` Linus Walleij
     [not found]               ` <CACRpkdahqb0qMVcKF9NBT5pwRgK4FOob5ABtb7ids9Bhh5XbZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-12 18:06                 ` Stephen Warren
2011-12-12 18:06                   ` Stephen Warren
2011-12-12 18:06                   ` Stephen Warren
     [not found]                   ` <74CDBE0F657A3D45AFBB94109FB122FF17518607C1-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-12-13  0:27                     ` Linus Walleij
2011-12-13  0:27                       ` Linus Walleij
2011-12-13  0:27                       ` Linus Walleij
     [not found] ` <1323382390-14892-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-12-08 22:13   ` [RFC 2/3] arm/tegra: Select PINMUX Kconfig variables Stephen Warren
2011-12-08 22:13     ` Stephen Warren
2011-12-08 22:13   ` [RFC 3/3] New pinmux testing hacks Stephen Warren
2011-12-08 22:13     ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111209170722.GO31337@atomide.com \
    --to=tony-4v6ys6ai5vpbdgjk7y7tuq@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.