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
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/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/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/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/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/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 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/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
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
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
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
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
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
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
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
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
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
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
---
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" (
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
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 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-
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
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
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
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
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
> >
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
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
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 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
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 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 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 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 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 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
} 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 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
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 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 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: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
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 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
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 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
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 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[] = {
> > {
> >
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 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
>
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 (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 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
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
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
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 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
>
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
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
(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
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
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-
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
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
69 matches
Mail list logo
