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 functions a cape needs.
If you look at the way
On 11/13/2012 8:29 AM, Stephen Warren wrote:
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
On 11/8/2012 3:28 AM, Koen Kooi wrote:
Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende
geschreven:
On 06/11/12 08:40, Tabi Timur-B04825 wrote:
On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
Jane is building custom BeagleBone
On 11/6/2012 12: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 there. Comments and
suggestions greatly appreciated.
Interesting. This just came
On 10/23/2012 4:49 AM, Jon Hunter wrote:
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
Hi,
I much prefer having drivers explicitly manage all their resources,
which would mean that pinctrl calls need to be done on probe() and, if
necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when you
meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
Hi,
I much prefer having drivers explicitly manage all
On 10/23/2012 1:15 PM, Jon Hunter wrote:
Hi Mitch,
On 10/23/2012 11:55 AM, Mitch Bradley wrote:
On 10/23/2012 4:49 AM, Jon Hunter wrote:
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
I strongly suspect (based
On 9/19/2012 7:09 PM, Arnd Bergmann wrote:
On Tuesday 18 September 2012, Mitch Bradley wrote:
There is a delicious irony here with respect to Shark. Shark has real
Open Firmware. It's the platform that I used for the first OFW port to
ARM. We (the Shark design team) had a version of NetBSD
On 9/19/2012 10:24 PM, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
+
On 9/18/2012 4:42 AM, Arnd Bergmann wrote:
On Saturday 15 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to
On 7/14/2012 6:37 AM, David Gibson wrote:
On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote:
I'm not sure this is really a good use of aliases. UARTs use aliases
because it is important that the UART number to tty number is known and
fixed.
This brings up an issue that I've been
On 6/15/2012 1:27 AM, Arnd Bergmann wrote:
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
On 9/5/2011 7:23 AM, Arnd Bergmann wrote:
On Monday 05 September 2011, Cousson, Benoit wrote:
Yeah, I saw that in the cpus node documentation. My point here is that
I do need to represent the MPU subsystem that will contain the cpus. And
thus the Cortex is inside the MPU subsystem.
The
14 matches
Mail list logo
