Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
Maybe I'm
On 07/17/2012 01:24 PM, Arnd Bergmann wrote:
...
I think we're basically on the same page. Let's see if I have covered
all the cases we discussed so far. I've tried to update the binding that
Jon sent out initially with everything we've discussed, so please review
this to see if I understood
On 07/24/2012 01:19 AM, Arnd Bergmann wrote:
On Monday 23 July 2012, Stephen Warren wrote:
3. A device with three channels, one of which has two alternatives:
s/three/four/ s/one of which/both of which/
This binding doc seems reasonable to me.
I asked a linguist about it who said
On 08/21/2012 05:17 AM, AnilKumar Ch wrote:
Add device tree data for tps65910 regulator by adding all tps65910
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65910 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree
On 08/21/2012 10:38 AM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 09:48:21AM -0600, Stephen Warren wrote:
This .dtsi file adds a node for every single regulator within
the TPS65910, which in turn means that of_regulator_match() will
find a node for every regulator, and in turn every
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
...
Maybe the lack of audio support in drm is because the audio users should
not talk to drm directly but to a lower level component (omapdrm,
On 09/01/2012 12:05 AM, AnilKumar, Chimata wrote:
On Fri, Aug 31, 2012 at 14:59:21, AnilKumar, Chimata wrote:
Modify c_can binding documentation according to recent review comments
on device tree data addition patches.
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
On 09/02/2012 10:54 PM, AnilKumar Ch wrote:
Modify c_can binding documentation according to recent review comments
on device tree data addition patches.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Reviewed-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send
On 09/10/2012 09:23 AM, Linus Walleij wrote:
On Sun, Sep 9, 2012 at 1:44 AM, Domenico Andreoli cav...@gmail.com wrote:
On Fri, Sep 07, 2012 at 11:57:59PM +0200, Linus Walleij wrote:
If all you need to to is to multiplex the pins into GPIO mode,
then the gpio_get() call on this driver *can*
On 09/10/2012 01:34 PM, Linus Walleij wrote:
On Mon, Sep 10, 2012 at 7:41 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 09/10/2012 09:23 AM, Linus Walleij wrote:
That seems like exactly what we were trying to avoid when we added the
possibility for GPIO to call into pinctrl
Grant Likely wrote at Wednesday, July 06, 2011 12:56 PM:
On Thu, Jun 30, 2011 at 03:07:23PM +0500, G, Manjunath Kondaiah wrote:
Add I2C and it's child device nodes for beagle board.
The I2C1 controller child devices are not populated and it
should be handled along with OMAP clock changes.
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM:
I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test on.
Here are the results I found:
Harmony:
Tegra USB3 - SMSC9514 hub: NOT affected
(Unplugging LAN cable, or disabling SMSC9514 LAN driver doesn't change
Marc Zyngier wrote at Friday, September 02, 2011 3:51 AM:
On 01/09/11 20:08, Stephen Warren wrote:
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM:
I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test
on.
Here are the results I found:
Harmony
On 09/13/2012 04:00 PM, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
On 09/14/2012 04:41 PM, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
The binding looks good to me now, so,
Reviewed-by: Stephen Warren swar
On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote:
Actually moving it from plat-omap, as this framework/driver code is
supposed to be under drivers/ folder. The framework should work with
the current supported OMAP processors (OMAP1+) that have mailbox and
can be used as a method of
On 04/30/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I'll reply to the binding
On 05/03/2012 09:27 AM, Tony Lindgren wrote:
Hi,
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 00:16]:
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Hmm I'm not sure
On 05/04/2012 09:06 AM, Jon Hunter wrote:
Hi Stephen,
On 05/03/2012 05:26 PM, Stephen Warren wrote:
On 04/30/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve
On 05/04/2012 09:56 AM, Arnd Bergmann wrote:
On Monday 30 April 2012, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no
On 05/02/2012 11:24 AM, Tony Lindgren wrote:
Add simple pinctrl driver using device tree data.
Currently this driver only works on omap2+ series of
processors, where there is either an 8 or 16-bit padconf
register for each pin. Support for other similar pinmux
controllers could be added.
On 05/05/2012 11:10 AM, Jassi Brar wrote:
On 5 May 2012 00:53, Arnd Bergmann a...@arndb.de wrote:
On Friday 04 May 2012, Jassi Brar wrote:
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
I think such
On 05/07/2012 11:19 AM, Jassi Brar wrote:
On 7 May 2012 21:23, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/05/2012 11:10 AM, Jassi Brar wrote:
Hmm... there ought to be a way by which a client is handed a random 'token'
via its dt node and similarly the dmac informed which channel
On 05/08/2012 01:09 PM, Jassi Brar wrote:
On 8 May 2012 22:05, Stephen Warren swar...@wwwdotorg.org wrote:
The data doesn't need to be part of the DMA controller node in order for
the DMA controller driver to be the entity interpreting it.
I rather say, if the dma controller driver
On 05/04/2012 03:57 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 12:27]:
On 05/02/2012 11:24 AM, Tony Lindgren wrote:
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 11:59]:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do
On 05/04/2012 08:04 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:55 Fri 04 May , Stephen Warren wrote:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I
On 05/09/2012 03:38 PM, Jassi Brar wrote:
On 10 May 2012 00:40, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/08/2012 01:09 PM, Jassi Brar wrote:
There is important difference between providing data via clients
during runtime vs providing info about every client to the dmac driver
at one
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 11:59]:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn
On 05/10/2012 11:27 AM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120510 10:09]:
On 05/09/2012 02:49 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504
On 05/10/2012 01:59 PM, Jassi Brar wrote:
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/09/2012 03:38 PM, Jassi Brar wrote:
One point is about 'qos' here something like bandwidth allocation.
If the dmac driver knew up-front the max possible clients that could
On 05/11/2012 01:51 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120511 12:21]:
The mapping of GPIO to pinctrl pins would presumably be driven solely by
the HW design of the pin controller and GPIO, and not by the mux
selection in the pin controller (otherwise, I'd argue
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we
On 05/12/2012 05:49 PM, Linus Walleij wrote:
On Thu, May 10, 2012 at 7:05 PM, Stephen Warren swar...@wwwdotorg.org wrote:
Also, were you intending pinctrl-simple to actually be the GPIO
controller itself? That'd be another case that one might consider fairly
simple, but then extends to being
On 05/16/2012 07:15 AM, Jon Hunter wrote:
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
On 05/16/2012 01:14 AM, Linus Walleij wrote:
On Mon, May 14, 2012 at 8:38 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/12/2012 05:49 PM, Linus Walleij wrote:
...
Maybe -simple isn't such a good name for this thing. Noone thinks
any kind of pin control is simple in any sense
On 05/16/2012 10:01 AM, Jon Hunter wrote:
...
By the way, I do see your point. You wish to describe the all the
mappings available to all dma controllers and then set a mapping in the
device tree. Where as I am simply setting a mapping and do not list all
other possibilities (assuming that
On 05/16/2012 11:37 AM, Jon Hunter wrote:
On 05/16/2012 12:24 PM, Jassi Brar wrote:
On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com wrote:
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one
On 05/16/2012 01:42 PM, Arnd Bergmann wrote:
On Wednesday 16 May 2012, Jassi Brar wrote:
On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote:
Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver
DMA
On 05/16/2012 03:16 PM, Jassi Brar wrote:
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de wrote:
...
More importantly, you make it very hard to add devices in a board file
to a dma controller that already has descriptions for some channels,
because you cannot easily extend the chan-map
On 05/18/2012 02:49 PM, Arnd Bergmann wrote:
On Wednesday 16 May 2012, Stephen Warren wrote:
Simple case:
/* e.g. FIFO TX DMA req - 2 DMACs possible */
dma-req-0 = dmac1 DMAC1_DMA_REQ_6;
/* e.g. FIFO RX DMA req 1 DMAC possible */
dma-req-1 = dmac1 DMAC1_DMA_REQ_8;
Multiple DMAC case
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
On Friday 18 May 2012, Stephen Warren wrote:
The driver can still request the dma line by name tx and the subsystem
would pick one out of those with the same name.
For the majority of cases, we would only need a single dma request line
Hmm. Many
On 05/19/2012 02:44 AM, Arnd Bergmann wrote:
On Friday 18 May 2012, Stephen Warren wrote:
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
So if we do that, we might want to make the dma-names property mandatory
for every device, and document what the names are.
We could do that, but one more
On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
On Monday 21 May 2012, Stephen Warren wrote:
The point with the direction was that it covers most cases and makes
them rather simple, while for the rare case where you need more than
two channels, you just use the otherwise optional named interface
On 06/11/2012 07:58 AM, Tony Lindgren wrote:
Add one-register-per-pin type device tree based pinctrl driver.
Currently this driver only works on omap2+ series of processors,
where there is either an 8 or 16-bit padconf register for each pin.
Support for other similar pinmux controllers can
On 06/15/2012 03:49 AM, Tony Lindgren wrote:
(Arnd, Grant, Rob, CC'ing you mainly re: the very last set of comments
in this email; can you take a look at Tony's patch and comment on the
binding)
* Stephen Warren swar...@wwwdotorg.org [120614 16:16]:
On 06/11/2012 07:58 AM, Tony Lindgren wrote
On 06/19/2012 07:56 AM, Tony Lindgren wrote:
Hi,
Below is the pinctrl-single patch updated with hopefully all the Stephen's
comments addressed. The binding still needs to be looked at, see relevant
parts of the discussion below.
...
From: Tony Lindgren t...@atomide.com
Date: Wed, 6 Jun
On 06/22/2012 02:39 AM, Tony Lindgren wrote:
Hi,
* Stephen Warren swar...@wwwdotorg.org [120621 15:17]:
On 06/19/2012 07:56 AM, Tony Lindgren wrote:
+
+- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
+ pinmux register; this gets combined with pinconf mask
On 06/26/2012 07:43 AM, Tony Lindgren wrote:
...
Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based
pinctrl driver
Add one-register-per-pin type device tree based pinctrl driver.
This driver has been tested on omap2+ series of processors,
where there is either an 8
Nicolas Ferre wrote at Wednesday, February 29, 2012 7:54 AM:
By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can
Cousson, Benoit wrote at Monday, March 05, 2012 6:14 AM:
On 2/29/2012 9:54 PM, Stephen Warren wrote:
Nicolas Ferre wrote at Wednesday, February 29, 2012 7:54 AM:
By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
On 03/14/2012 11:47 AM, Nicolas Ferre wrote:
...
I do have the will to avoid the treats of memory corruption in case of
malformed DT data, as Stephen was saying. But, on the other hand I do
not know really if this can happen: if the .xlate() function which is
provided by the DMA controller is
On 03/19/2012 09:01 AM, Arnd Bergmann wrote:
On Monday 19 March 2012, Mark Brown wrote:
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
After implementing both schemes (ie. interrupts+interrupt-names
[*-]gpios)
I definitely prefer the fixed property name plus a separate names
On 03/19/2012 09:45 AM, Arnd Bergmann wrote:
On Monday 19 March 2012, Stephen Warren wrote:
Maybe one can use named properties in a new device node in that case,
like this:
bus {
dma: dma-controller {
#dma-cells = 1
On 03/20/2012 04:13 AM, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void *
Rob Herring wrote at Wednesday, February 22, 2012 10:23 AM:
On 02/22/2012 08:31 AM, Cousson, Benoit wrote:
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base
On 11/06/2012 12:41 PM, Pantelis Antoniou wrote:
Hi Russ,
On Nov 6, 2012, at 8:29 PM, Russ Dill wrote:
On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [121106 03:16]:
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Interesting. This just came up internally at NVIDIA within the last
couple
On 11/07/2012 01:47 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started
On 11/08/2012 07:26 PM, David Gibson wrote:
...
I also think graft will handle most of your use cases, although as I
said I don't fully understand the implications of some of them, so I
could be wrong. So, the actual insertion of the subtree is pretty
trivial to implement. phandles are the
On 11/08/2012 10:32 PM, Joel A Fernandes wrote:
...
Alternatively to hashing, reading David Gibson's paper I followed,
phandle is supposed to 'uniquely' identity node. I wonder why the node
name itself is not sufficient to uniquely identify. The code that does
the tree walking can then just
On 11/05/2012 01:40 PM, Grant Likely wrote:
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Here's one other requirement I'd like that I don't think I saw
explicitly mentioned in
On 11/08/2012 07:26 PM, David Gibson wrote:
...
So, let me take a stab at this from a more bottom-up approach, and see
if we meet in the middle somewhere. As I discussed in the other
thread with Daniel Mack, I can see two different operationso on the
fdt that might be useful in this context.
On 11/09/2012 09:28 AM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote:
...
I do rather suspect this use-case is quite common. NVIDIA certainly has
a bunch of development boards with pluggable
PMIC/audio/WiFi/display/..., and I believe there's
On 11/09/2012 09:28 AM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get
On 11/12/2012 04:23 AM, Pantelis Antoniou wrote:
Hi Grant,
Sorry for the late comments, travelling...
On Nov 9, 2012, at 6:28 PM, Grant Likely wrote:
...
*with the caveat that not all types of changes are a good idea and we
may disallow. For example, is changing properties in existing
On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote:
On 11/09/2012 09:28 AM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
...
I do rather suspect this use-case is quite common
On 11/12/2012 05:50 AM, Pantelis Antoniou wrote:
Hi Rob.
On Nov 11, 2012, at 10:47 PM, Rob Landley wrote:
On 11/09/2012 10:28:59 AM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote
On 11/12/2012 10:00 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote:
On 11/12/2012 04:23 AM, Pantelis Antoniou wrote:
Hi Grant,
Sorry for the late comments, travelling...
On Nov 9, 2012, at 6:28 PM, Grant Likely wrote:
...
*with the caveat
On 11/12/2012 10:19 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote:
On 11/12/2012 10:00 AM, Pantelis Antoniou wrote:
Hi Stephen,
On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote:
On 11/12/2012 04:23 AM, Pantelis Antoniou wrote:
Hi Grant
On 11/12/2012 06:05 PM, David Gibson wrote:
On Fri, Nov 09, 2012 at 09:42:37PM +, Grant Likely wrote:
...
2) graft bundle
The base tree has something like this:
...
i2c@XXX {
...
cape-socket {
compatible =
On 11/13/2012 12:25 AM, David Gibson wrote:
On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
[snip]
Oh yes. In fact if one was to use a single kernel image for beagleboard
and beaglebone, for the cape to work for both
On 11/13/2012 01:09 AM, Pantelis Antoniou wrote:
On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
...
1) We annotate the base tree with some extra label information for
nodes which overlays are likely to want to reference by phandle. e.g.
beaglebone_pic: interrupt-controller@X {
On 11/13/2012 11:10 AM, Mitch Bradley wrote:
It seems to me that this capebus discussion is missing an important
point. The name capebus suggests that it is a bus, so there should be a
parent node to represent that bus. It should have a driver whose API
implements all of the system-interface
tens of subarch lists though,
and the OMAP maintainer and LAKML were CC'd.
On 11/19/12 20:31, Stephen Warren wrote:
Now that the only field in struct sys_timer is .init, delete the struct,
and replace the machine descriptor .timer field with the initialization
function itself.
This will enable
On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers
On 01/31/2013 10:51 AM, Arnd Bergmann wrote:
This is what I think it would look like to do a default platform
with an empty machine descriptor on ARM. It makes the few required
entries in the descriptor optional by using the new irqchip_init()
and clocksource_of_init() functions as defaults,
On 02/07/2013 01:53 PM, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
Now that we have OF based init with CLKSRC_OF, convert smp_twd init
function to use it and covert all callers of
twd_local_timer_of_register.
Reviewed-by: Stephen Warren swar...@nvidia.com
Thanks
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time to add FIT support, also looking at the proliferating number of
dtbs, as it
On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move
On 02/21/2013 06:29 AM, Tom Rini wrote:
On 02/20/2013 11:26 PM, Stephen Warren wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello, I've been spinning some work-in-progress patches for
FIT build support in the kernel. With the move to
multiplatform support on OMAP, I feel
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is
On 02/21/2013 12:57 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz,
On 02/21/2013 03:05 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
...
Distros already ship huge kernels with modules for every hardware out
there. Shipping all the DTs as well doesn't seem like a problem.
But it is! Even shipping multiple kernels _is_ a problem for
On 02/21/2013 04:11 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
...
The DT is meant to describe hardware. As far as I know, the hardware I
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't
On 02/21/2013 05:39 PM, Russell King - ARM Linux wrote:
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote:
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
...
Someone will want to use a previously unsupported feature of some HW and
then write the DT bindings for that feature
On 02/26/2013 03:01 AM, Javier Martinez Canillas wrote:
...
I was wondering if the level/edge settings for gpios is working on OMAP.
...
Reading the gpio-omap.txt documentation it says that #interrupt-cells
should be 2 and that a value of 8 is active low level-sensitive.
So I tried this:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board.
In
On 02/26/2013 04:01 PM, Jon Hunter wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT
On 02/26/2013 04:45 PM, Jon Hunter wrote:
On 02/26/2013 05:06 PM, Stephen Warren wrote:
On 02/26/2013 04:01 PM, Jon Hunter wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I
On 02/26/2013 08:33 PM, Javier Martinez Canillas wrote:
...
Yes, I realized that requesting the gpio was necessary so what I did
is to use the regulator-fixed optional property gpio and define
the GPIO used as an IRQ in a regulator used by the SMSC chip. So, I
have this on my board DT:
On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote:
On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 06:13 PM, Stephen Warren wrote:
On 02/26/2013 04:45 PM, Jon Hunter wrote:
...
One issue I see is that by not calling gpio_request, then potentially
you
On 03/05/2013 07:21 AM, Kishon Vijay Abraham I wrote:
From: Graeme Gregory g...@slimlogic.co.uk
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
diff --git
On 03/07/2013 02:36 AM, Felipe Balbi wrote:
CONFIG_USB_OTG_UTILS will be removed very
soon, so we should check CONFIG_USB_PHY
instead.
The Tegra EHCI driver isn't very useful without the Tegra PHY driver.
Perhaps its Kconfig should simply select USB_PHY, and the ifdefs be
removed rather than
On 03/07/2013 02:35 AM, Felipe Balbi wrote:
Hi folks,
inspired by Paul's DWC2 patchset which added usb_otg_state_string()
(a copy of otg_state_string()) I have now renamed otg_state_string()
to usb_otg_state_string(), moved it to usb-common, then moved all
phy drivers to drivers/usb/phy/
On 03/08/2013 12:14 AM, Felipe Balbi wrote:
Hi,
On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren wrote:
On 03/07/2013 02:35 AM, Felipe Balbi wrote:
Hi folks,
inspired by Paul's DWC2 patchset which added
usb_otg_state_string() (a copy of otg_state_string()) I have
now renamed
On 03/08/2013 11:26 AM, Felipe Balbi wrote:
On Fri, Mar 08, 2013 at 10:14:11AM -0700, Stephen Warren wrote:
On 03/08/2013 12:14 AM, Felipe Balbi wrote:
Hi,
On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren
wrote:
On 03/07/2013 02:35 AM, Felipe Balbi wrote:
Hi folks,
inspired
1 - 100 of 236 matches
Mail list logo
