Linus (W),
Some more thoughts on pinmux:
== GPIO/pinmux API interactions
I'd like to understand how the gpio and pinmux subsystems are intended
to interact.
Quoting from Documentation/gpio.txt:
Note that requesting a GPIO does NOT cause it to be configured in any
way; it just marks
Linus Walleij wrote at Thursday, June 16, 2011 6:47 AM:
> On Wed, Jun 15, 2011 at 12:11 AM, Stephen Warren wrote:
> > [Me]
> >> Can't you just send some patch or example .h file for the API
> >> you would like to see so I understand how you think about
> >&
Linus Walleij wrote at Thursday, June 16, 2011 9:07 AM:
> On Wed, Jun 15, 2011 at 11:48 PM, Stephen Warren wrote:
>
> > Some more thoughts on pinmux:
>
> Thanks!
>
> Keep it coming until you get tired of me :-)
>
> > == GPIO/pinmux API interactions
>
a2.c
new file mode 100644
index 000..d010f9c
--- /dev/null
+++ b/drivers/pinctrl/pinmux-tegra2.c
@@ -0,0 +1,85 @@
+/*
+ * pinctrl driver for NVIDIA Tegra 2
+ *
+ * Author: Stephen Warren
+ * Copyright (C) 2011 NVIDIA, Inc.
+ *
+ * License terms: GNU General Public License (GPL) version 2
+
Linus Walleij wrote at Monday, June 27, 2011 8:35 AM:
> On Thu, Jun 16, 2011 at 9:10 PM, Stephen Warren wrote:
...
> > Now, we can have multiple entries with the same .map_name:
> >
> > static struct pinmux_map pmx_mapping[] = {
> > {
> >
Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
> From: Linus Walleij
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
Sorry to keep harping on about this, but I'm still not convinced the data
model is
Linus Walleij wrote at Thursday, August 25, 2011 4:13 AM:
> On Wed, Aug 24, 2011 at 8:29 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
> >>
> >> This creates a subsystem for handling of pin control devices.
> >> Thes
Barry Song wrote at Thursday, August 25, 2011 7:59 PM:
> 2011/8/22 Linus Walleij :
> > On Sun, Aug 21, 2011 at 4:42 PM, Barry Song <21cn...@gmail.com> wrote:
> >
> >> it seems there is not an actual example that gpio requests pin from
> >> pinctrl yet. i might give one on SiRFprimaII.
> >
> > No go
Linus Walleij wrote at Friday, August 26, 2011 2:35 AM:
> On Thu, Aug 25, 2011 at 9:13 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Thursday, August 25, 2011 4:13 AM:
> >
> >> So this is radically different in that it requires the pin control
> >> system
s a function in a certain position, and the pinmux maps define
> what position you want the function in. (Feedback from Stephen
> Warren and Sascha Hauer).
My thoughts:
I guess "positions" can be used to represent the muxing capabilities of
Tegra. However, I still don'
Linus Walleij wrote at Thursday, September 01, 2011 3:13 AM:
...
> I will need Arnds or similars advice on it so we don't
> grow a lib/mysql into the kernel with this kind of
> schemes and get slammed for overcomplicating
> things when trying to merge the beast.
I /think/ the whole multi-row thing
Linus Walleij wrote at Thursday, September 01, 2011 3:32 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
Overall, I think this is beginning to look very good. Thanks for taking
care of my requests.
I want to
Linus Walleij wrote at Thursday, September 01, 2011 3:33 AM:
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.
> diff
Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
> On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren wrote:
>
> >> +static const struct u300_pmx_func u300_pmx_functions[] = {
> >> + {
> >> + .name = "power",
&g
Linus Walleij wrote at Friday, September 02, 2011 6:59 AM:
> > I would imagine treating GPIOs as just another function. I'll repeat
> > some text I wrote previously (https://lkml.org/lkml/2011/8/26/298) about
> > how I see this working:
> >
> >>SW For reference, here's how I'd imagine modeling thos
} triplet, attempts
> to map the same device to multiple pin controllers will
> for example fail. This is hopefully the crucial feature
> requested by Stephen Warren.
I've been viewing the map table as:
input: (device, device's function)
output: list of (controller, con
Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
I've read through the documentation and header files, but not the .c files,
and this looks almost perfect
Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.
...
> dif
Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
> On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren wrote:
> > Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
> >> + for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
> >> +
Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM:
> On Tue, Sep 20, 2011 at 11:58 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> >> This creates a subsystem for handling of pin control devices.
> >> These are dev
Linus Walleij wrote at Tuesday, September 27, 2011 1:51 AM:
> On Wed, Sep 21, 2011 at 9:45 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM:
> >> To abstract things the stuff we can do with the group should be
> >> s
Linus Walleij wrote at Tuesday, September 27, 2011 2:01 AM:
> On Wed, Sep 21, 2011 at 9:39 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
> >> On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren
> >> wrote:
> >
Linus Walleij wrote at Wednesday, September 28, 2011 5:59 AM:
> On Wed, Sep 28, 2011 at 2:15 AM, Stephen Warren wrote:
>
> > But can't debugfs just get its information from the device name field in
> > the mapping table? I'm not sure why the need to use that informat
but they look good to me now, so:
Acked-by: Stephen Warren
--
nvpublic
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Linus, (and other people interested in pinmux!)
I've started to look at porting the Tegra pinmux driver to your pinctrl
subsystem. In order to replace the existing pinmux driver, I need a way
to support configuring options such as tri-state, pull-up/down, drive-
strength, etc.
At this point, I ha
here have been discussed.
>
> On Thu, Oct 13, 2011 at 01:59:55PM -0700, Stephen Warren wrote:
> > Linus, (and other people interested in pinmux!)
> >
> > I've started to look at porting the Tegra pinmux driver to your pinctrl
> > subsystem. In order to replace the e
Shawn Guo wrote at Friday, October 14, 2011 9:12 PM:
> On Fri, Oct 14, 2011 at 08:53:33AM -0700, Stephen Warren wrote:
...
> > Having the driver expose a list of all possible combinations of pin
> > configurations seems impractical, for the same reason as I objected to
> >
ng, driving,
> load capacitance ... whatever
>
> 2) The need to handle state transitions of pinmux settings.
Yes, that's true.
> I prefer that we try to keep these two separate and not conflate
> them too much.
>
> On Thu, Oct 13, 2011 at 10:59 PM, Stephen Warren wrote
Linus Walleij wrote at Wednesday, October 19, 2011 10:21 AM:
> Now also the core needs to look up pin groups so move the lookup
> function there and expose it in the internal header.
>
> Signed-off-by: Linus Walleij
Acked-by: Stephen Warren
s the hard-coded maximum pin name length.
Signed-off-by: Stephen Warren
---
drivers/pinctrl/core.c |5 ++---
drivers/pinctrl/core.h |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 97a4eeb..15d7e5a 100644
---
ff-by: Stephen Warren
---
drivers/pinctrl/core.h |3 +--
drivers/pinctrl/pinmux.c | 36 +++-
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index a493ba6..783c075 100644
--- a/drivers/pinctrl/c
pinmux
drivers.
Signed-off-by: Stephen Warren
---
drivers/pinctrl/core.c |2 +-
drivers/pinctrl/pinmux-sirf.c |6 +++---
drivers/pinctrl/pinmux-u300.c |6 +++---
drivers/pinctrl/pinmux.c|4 ++--
include/linux/pinctrl/pinctrl.h |4 ++--
5 files changed
A pin controller's pin definitions are used both during pinctrl_register()
and pinctrl_unregister(). The latter happens outside of __init/__devinit
time, and hence it is unsafe to mark the pin array as __refdata.
Signed-off-by: Stephen Warren
---
drivers/pinctrl/pinmux-sirf.c |2 +-
dr
Linus Walleij wrote at Wednesday, October 19, 2011 10:21 AM:
> This add per-pin and per-group pin control interfaces for biasing,
> driving and other such electronic properties. The intention is
> clearly to enumerate all things you can do with pins, hoping that
> these are enumerable.
>
> Signed-
Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
...
> > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > +enum pin_config_param param, unsigned long data)
...
> > +enum pin_config_p
Linus Walleij wrote at Thursday, October 20, 2011 7:44 AM:
> On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
>
> > We should not require device driver to call these APIs directly. There
> > are so many pinctrl subsystem internal details left to its users.
>
> As explained I already have drive
Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
> On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren wrote:
...
> >> + * @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: the pin will be set to a high
> >> impedance
> >> + * mode, also know as "third-state" (
naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().
Signed-off-by: Stephen Warren
---
Shawn Guo wrote at Sunday, October 23, 2011 2:26 AM:
> On Thu, Oct 20, 2011 at 10:26:43AM -0700, Stephen Warren wrote:
> > Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> > > On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
> > ...
> > &g
Shawn Guo wrote at Sunday, October 23, 2011 2:51 AM:
...
> To me, pin_config() and its parameters should be invisible to client
> drivers. For amba-pl011 example, do you think any of those SoCs will
> need multiple sets of uart pin configurations to switch for different
> working modes? If that's
Linus Walleij wrote at Monday, November 07, 2011 7:15 AM:
> From: Linus Walleij
>
> Machines that have embedded pin controllers need to select them
> explicitly, so why broadcast their config options to menuconfig.
> We provide a helpful submenu for those machines that do select
> it, making it p
Stephen Warren wrote at Friday, October 21, 2011 12:26 PM:
> Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
> completely different manner than they select which function to mux out of
> that pin. In order to support a single "free" pinmux_op, the dri
le to enable debugging for example.
>
> Reported-by: Linus Torvalds
> Signed-off-by: Linus Walleij
Acked-by: Stephen Warren
--
nvpublic
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> * Linus Walleij [22 03:30]:
> > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > wrote:
> > > On 17 November 2011 19:27, Linus Walleij wrote:
> > >>
> > >> Maybe I'm mistaken about the device tree ambitions, but
> > >> I was s
On 11/18/2012 11:41 PM, Viresh Kumar wrote:
> On 19 November 2012 12:05, Rajanikanth HV wrote:
>> On 19 November 2012 12:00, Viresh Kumar wrote:
>>> Firstly you tried square braces [ ], I am not sure if that is allowed.
>>> Can you point me to the specification?
>> http://www.devicetree.org/Devic
property = /bits/ 8 <0x50 0x60 0x70>;
> - u16 array:
> property = /bits/ 16 <0x5000 0x6000 0x7000>;
Reviewed-by: Stephen Warren
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ls only ->related_cpus and not ->cpus, which looks to
> be
> incorrect. Lets fix it.
Joseph Lo reviewed/tested this and it looks fine, so,
Acked-by: Stephen Warren
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On 03/01/2013 02:41 AM, Bill Huang wrote:
> On Thu, 2013-02-28 at 12:49 +0800, Mike Turquette wrote:
>> Dynamic voltage and frequency scaling (dvfs) is a common power saving
>> technique in many of today's modern processors. This patch introduces a
>> common clk rate-change notifier handler which
On 03/12/2013 07:47 PM, Bill Huang wrote:
> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
>> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
>>> Add the below four notifier events so drivers which are interested in
>>> knowing the clock status can act accordingly. T
On 03/12/2013 11:08 PM, Bill Huang wrote:
> On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
>> On 03/12/2013 07:47 PM, Bill Huang wrote:
>>> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
>>>> On Tue, Mar 12, 2013 at 05:37:41AM -0700, B
On 03/12/2013 11:40 PM, Bill Huang wrote:
> On Wed, 2013-03-13 at 13:24 +0800, Stephen Warren wrote:
>> On 03/12/2013 11:08 PM, Bill Huang wrote:
>>> On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
>>>> On 03/12/2013 07:47 PM, Bill Huang wrote:
>>&
On 03/14/2013 03:28 AM, Bill Huang wrote:
> On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
>> On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:
>>
>>> I don't think deferring will work either, considering the usage of DVFS,
>>> device voltage is tightly coupled with frequenc
On 03/14/2013 07:20 PM, Bill Huang wrote:
> On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
>> On 03/14/2013 03:28 AM, Bill Huang wrote:
>>> On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
>>>> On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill H
On 03/15/2013 06:33 AM, Ulf Hansson wrote:
> On 15 March 2013 13:06, Bill Huang wrote:
>> On Fri, 2013-03-15 at 18:08 +0800, Ulf Hansson wrote:
...
>>> Some prerequisites; I think am in favor of using the clk API to
>>> trigger DVFS changes and then I agree on that clk_prepare|unprepare
>>> needs
On 03/15/2013 11:45 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 14, 2013 at 02:31:04AM -0700, Bill Huang wrote:
>> Add the below two notifier events so drivers which are interested in
>> knowing the clock status can act accordingly. This is extremely useful
>> in some of the DVFS (Dynamic Vol
On 03/28/2013 04:01 PM, Mike Turquette wrote:
> Quoting Colin Cross (2013-03-21 17:06:25)
>> On Thu, Mar 21, 2013 at 3:36 PM, Mike Turquette
>> wrote:
>>> To my knowledge, devfreq performs one task: implements an algorithm
>>> (typically one that loops/polls) and applies this heuristic towards a
U-Boot wrapped dtbImage; useful for testing DT with an unmodified U-Boot.
Signed-off-by: Stephen Warren
---
This patch is based on:
git://kernel.ubuntu.com/jk/dt/linux-2.6.git dtbimage
However, I actually developed and tested it only on:
git://git.secretlab.ca/git/linux-2.6 devicetree
existing Harmony version over the copy in board-dt.c
Signed-off-by: Stephen Warren
---
arch/arm/mach-tegra/board-dt.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 899311b..7b9d469 100644
--- a
tegra_common_init was removed by:
0cf6230af909a86f81907455eca2a5c9b8f68fe6
ARM: tegra: Move tegra_common_init to tegra_init_early
Fix the Tegra devicetree support to match.
Signed-off-by: Stephen Warren
---
arch/arm/mach-tegra/board-dt.c |2 --
1 files changed, 0 insertions(+), 2
it's some unrelated issue. I'll try to follow up
and solve that too.
Stephen Warren (3):
ARM: Tegra: dt: Compile fix; tegra_common_init removed
ARM: Tegra: dt: Fix machine desc to match other boards.
ARM: Tegra: Move Harmony .dts file to correct place
arch/arm/boot/dts/tegra-
negatively affected by
this change.
Signed-off-by: Stephen Warren
---
arch/arm/boot/dts/tegra-harmony.dts | 110 +++-
arch/arm/mach-tegra/board-harmony.dts | 113 -
2 files changed, 108 insertions(+), 115 deletions(-)
delete mode 10064
(Do not apply)
This is only necessary at present since the devicetree support relies on
some aspects of some existing hard-coded board file for some parts of
initialization. In the long run, that code can be ported to devicetree
too.
Signed-off-by: Stephen Warren
---
I needed to test devicetree
Tegra's I2C driver has a unique feature built in (although not mainlined
yet); it can multiplex the I2C bus onto different sets of pins using the
Tegra pinmux module, and hence can register more than 1 I2C bus with the
I2C core for each controller. The exact number of busses registers, and
the pinm
Tegra's board files currently contain quite a number of tables, with
board-specific content. For example, (in mainline) arch/arm/mach-tegra/
board-seaboard-pinmux.c contains a table of pinmux settings, a table of
pin drive strengths, and a list of all GPIOs that must be enabled. In
the ChromeOS ker
Grant Likely wrote at Friday, April 29, 2011 5:35 PM:
> On Sat, Apr 23, 2011 at 10:30:03PM -0600, Stephen Warren wrote:
> > The content of the machine descriptions has be re-organized. Without fixing
> > the board-dt.c copy, the system will fail to boot (BUG_ON during timer
>
Stephen Warren wrote at Sent: Friday, April 29, 2011 7:52 PM:
> To: Grant Likely
> Cc: linaro-dev@lists.linaro.org; linux-te...@vger.kernel.org
> Subject: RE: [PATCH 2/3] ARM: Tegra: dt: Fix machine desc to match other
> boards.
>
> Grant Likely wrote at Friday, April 29, 2011 5
Grant Likely wrote at Monday, June 13, 2011 7:32 AM:
> Signed-off-by: Grant Likely
> ---
>
> Hey all,
>
> This is an early draft of the usage model document for the device
> tree, but I wanted to get it out there for feedback, and so that some
> of the Linaro engineers could get started on migra
Linus Walleij wrote at Monday, June 13, 2011 10:58 AM:
> This creates a subsystem for handling of pinmux devices. These are
> devices that enable and disable groups of pins on primarily PGA and
> BGA type of chip packages and common in embedded systems.
I'm a little confused by this version. In pa
Linus Walleij wrote at Tuesday, June 14, 2011 8:26 AM:
> On Tue, Jun 14, 2011 at 1:28 AM, Stephen Warren wrote:
>
> > I'm a little confused by this version.
>
> Sorry, I'll try to clarify.
>
> > In particular:
> >
> > * I don't see some
69 matches
Mail list logo
