On 3/10/2013 9:46 PM, Thierry Reding wrote:
On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
Okay, I think I finally get it. The Marvell root port bridge setup
registers
On 3/11/2013 8:23 AM, Jason Gunthorpe wrote:
(b) The discovery/enumeration code needs to access config space via
pci_ops. The root complex driver implements pci_ops based on a trivial
parsing of ranges (omitting irrelevant details):
pci_op_read(devfn, pos) {
loop_over_ranges_entries {
On 3/11/2013 8:15 AM, Jason Gunthorpe wrote:
On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
So it seems that we are faced with two requirements that are somewhat at
odds with one another.
1) Some of the root port bridge registers have to be accessed via config
space access
On 3/11/2013 1:25 PM, Jason Gunthorpe wrote:
On Mon, Mar 11, 2013 at 11:50:19AM -1000, Mitch Bradley wrote:
However - the driver runs the core in a 'root port bridge mode' where
the config header register block you are looking at is inhibited. The
Marvell IP block requires software support
On 3/10/2013 5:06 AM, Thomas Petazzoni wrote:
Dear Mitch Bradley,
On Sat, 09 Mar 2013 19:04:51 -1000, Mitch Bradley wrote:
As stated in my recent reply to Jason, I thing the correct property is
ranges. Ranges translates mappable child address space addresses
into parent addresses
On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
Okay, I think I finally get it. The Marvell root port bridge setup
registers look like standard config headers, even though they aren't
really in config space (because you need
On 3/8/2013 3:31 PM, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 01:46:13PM -1000, Mitch Bradley wrote:
On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
http://www.spinics.net/lists/arm-kernel/msg228749.html
The example
On 3/8/2013 1:12 PM, Rob Herring wrote:
On 03/08/2013 01:14 AM, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a nutshell (since some of the context isn't quoted anymore) the
problem that we're trying
On 3/8/2013 9:12 AM, Thierry Reding wrote:
On Fri, Mar 08, 2013 at 09:52:28AM -0700, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a
On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
http://www.spinics.net/lists/arm-kernel/msg228749.html
The example in that posting looks messed up to me.
1) It has reg = 0x0800 0 0 0 0, but 0x0800 0 0 is not a valid
address
On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
Hi,
On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
gerlando.fala...@keymile.com wrote:
Hi everyone,
I have a similar question.
I'd like to name i2c devices so that a userspace application can somehow
identify those devices with the
On 3/1/2013 1:17 PM, Stephen Warren wrote:
On 03/01/2013 02:47 PM, Mitch Bradley wrote:
On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
Hi,
On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
gerlando.fala...@keymile.com wrote:
Hi everyone,
I have a similar question.
I'd like to name
On 1/7/2013 10:43 AM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/exynos/hdmi.txt
On 12/17/2012 6:50 PM, Stephen Boyd wrote:
Hi,
I'd like to propose a binding for gate clocks so that we can discuss how
descriptive devicetree clock bindings should be.
Binding for simple gate clocks.
This binding uses the common clock binding[1].
[1]
On 12/17/2012 11:36 AM, Stephen Warren wrote:
On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
Nvidia's Tegra has multiple uart controller which supports:
- APB dma based controller fifo read/write.
- End Of Data interrupt in incoming data to know whether end
of frame achieve or not.
- Hw
On 12/17/2012 12:04 PM, Stephen Warren wrote:
On 12/17/2012 02:58 PM, Mitch Bradley wrote:
On 12/17/2012 11:36 AM, Stephen Warren wrote:
On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
Nvidia's Tegra has multiple uart controller which supports:
- APB dma based controller fifo read/write
On 12/10/2012 12:38 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote:
Sorry for my pci ignorance (have never got hw for mb/zynq)
I just want to get better overview how we should we our drivers to
be compatible.
Does it mean that pci is supposed be
On 11/29/2012 1:46 AM, Grant Likely wrote:
On Thu, Nov 29, 2012 at 6:39 AM, Jon Masters jonat...@jonmasters.org wrote:
Hey guys,
I apologize if I should have RTFM. If a platform provides a device tree
at boot time, and the kernel also has a tree appended, what behavior is
supposed to happen?
On 11/26/2012 12:37 PM, Rob Herring wrote:
On 11/26/2012 02:19 PM, Guenter Roeck wrote:
On Mon, Nov 26, 2012 at 10:43:38AM -0600, Rob Herring wrote:
On 11/25/2012 10:53 PM, Guenter Roeck wrote:
Some I2C devices are not or not correctly initialized by the firmware.
Configuration would be
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 7:51 AM, Thierry Reding wrote:
On Tue, Nov 13, 2012 at 10:46:53AM -0700, Stephen Warren wrote:
On 11/13/2012 04:08 AM, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
This adds support for reading display timings from DT or/and
convert one
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/31/2012 1:00 PM, Daniel Mack wrote:
cc devicetree-discuss. Here's a reference to the full thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
On 26.10.2012 20:39, Stephen Warren wrote:
On 10/24/2012 03:47 AM, Daniel Mack wrote:
Hi,
a project I'm involved in
On 10/31/2012 6:36 PM, Stephen Warren wrote:
On 10/31/2012 05:56 PM, Mitch Bradley wrote:
On 10/31/2012 1:00 PM, Daniel Mack wrote:
cc devicetree-discuss. Here's a reference to the full thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
On 26.10.2012 20:39, Stephen
On 10/24/2012 8:09 AM, Stephen Warren wrote:
On 10/24/2012 11:46 AM, Alan Stern wrote:
On Wed, 24 Oct 2012, Stephen Warren wrote:
How do we determine which existing drivers claim to support usb-ehci?
A quick search under arch/ and drivers/ turns up nothing but
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 10/10/2012 8:40 AM, Stephen Warren wrote:
On 10/10/2012 11:09 AM, Rob Herring wrote:
On 10/09/2012 04:16 PM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
On 10/10/2012 1:16 PM, David Gibson wrote:
On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
On 10/10/2012 10:16 AM, Stephen Warren wrote:
On 10/10/2012 01:24 AM, David Gibson wrote:
On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
On Oct 9, 2012, at 6:04 PM, Scott Wood
On 10/9/2012 11:16 AM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
Perhaps we can just handle this through the regular patch review
process; I think it may be
On 10/7/2012 11:01 PM, Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller
On 10/1/2012 6:53 AM, Stephen Warren wrote:
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
Parse a display-node with timings and hardware-specs from devictree.
diff --git a/Documentation/devicetree/bindings/video/display
b/Documentation/devicetree/bindings/video/display
new file mode
On 10/1/2012 10:25 AM, Stephen Warren wrote:
On 10/01/2012 01:16 PM, Mitch Bradley wrote:
On 10/1/2012 6:53 AM, Stephen Warren wrote:
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
Parse a display-node with timings and hardware-specs from devictree.
diff --git a/Documentation/devicetree
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
Hi Thomas,
On 8/22/2012 2:04 AM, Thomas Abraham wrote:
On 22 August 2012 16:38, Chris Ball c...@laptop.org wrote:
Hi Thomas,
On Wed, Aug 22 2012, Thomas Abraham wrote:
This matches Mitch's last suggestion exactly -- I think we're all agreed
on these properties now. The only remaining
On 8/21/2012 7:33 AM, Thomas Abraham wrote:
On 21 August 2012 21:31, Rob Herring robherri...@gmail.com wrote:
On 08/21/2012 10:18 AM, Chris Ball wrote:
Hi,
On Tue, Aug 21 2012, Rob Herring wrote:
cd-gpios and cd-external can be present on the same node. if broken-cd
is present, it must be
On 8/20/2012 2:37 AM, Tabi Timur-B04825 wrote:
Srinivas KANDAGATLA wrote:
But assuming that this really is the best approach, then it would make
sense for --strip-disabled to leave this node in the dtb, because
otherwise there would be no way to re-enable it.
--strip-disabled should still get
On 8/17/2012 1:36 AM, Mark Brown wrote:
On Thu, Aug 16, 2012 at 11:36:31AM -1000, Mitch Bradley wrote:
The main rule for node names is that a user browsing the device tree
can easily determine what something is. Thus ethernet instead of
DEC,21140.
Does this actually buy us much
On 8/16/2012 8:38 AM, Stephen Warren wrote:
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between
On 8/16/2012 9:34 AM, Stephen Warren wrote:
As I understand it, there is a rule when writing device tree files (and
bindings) that nodes should be named after the type of object they
represent, and not the particular instance of the object. Related, node
names should not be interpreted as
Here is the situation: We (OLPC) have an audio codec that is strongly
associated with an audio controller, but it also has some registers that
you get at with I2C.
In some sense, the codec has two parents, the audio controller
(connected via I2S) and the I2C controller.
Is there an established
On 8/15/2012 1:29 AM, David Gibson wrote:
On Wed, Aug 15, 2012 at 10:49:44AM +0100, Srinivas KANDAGATLA wrote:
On 15/08/12 03:12, Tabi Timur-B04825 wrote:
On Tue, Aug 14, 2012 at 8:11 PM, David Gibson d...@au1.ibm.com wrote:
On Mon, Aug 13, 2012 at 09:01:53AM +0100, Srinivas KANDAGATLA wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the platform data would fill in the fields mentioned
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same
On 8/1/2012 9:47 AM, Alex Courbot wrote:
On 07/31/2012 09:55 PM, Mitch Bradley wrote:
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot
On 7/25/2012 11:48 AM, David Gibson wrote:
On Tue, Jul 24, 2012 at 11:34:50AM +0200, Attila Kinali wrote:
Hi,
I have here an embedded system where i use a serial port as SD Card
interface as well as SPI interface. I select what i want to use
by setting a GPIO pin high or low.
Currently i'm
On 7/24/2012 7:35 AM, Wolfgang Denk wrote:
Dear Arnd,
In message 201207241319.45101.a...@arndb.de you wrote:
I'm trying to implement a driver that can do both DMA and PIO, and it would
be
nice if the user was able to select the mode (on a per-bus basis) using the
DT.
The PIO mode can
I want to apologize to everybody for my hard-to-read
text that is improperly word-wrapped. I keep trying
to find Thunderbird settings that will Do The Right Thing,
but so far have been stymied.
___
devicetree-discuss mailing list
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
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 meaning to comment on.
The use of phandle-valued properties in the aliases node causes real OFW
On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
On Fri, 6 Jul 2012, Mitch Bradley wrote:
On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
The kernel *must* go where it is linked, but the FDT contains only relative
references and is thus free to go anywhere. The same is true of ramdisks,
which
I'm passing a flatted device tree from OLPC's bootloader (which
is a full Open Firmware implementation) to the kernel. If I
put the FDT at the traditional address 0x100, bad things
happen when the DT is larger than 16K. The FDT extends past
the 0x4000 boundary and gets overwritten by the early
or not
I'm just getting lucky.
Thanks,
Mitch
How about doing the same with your FDT?
-Original Message-
From: devicetree-discuss [mailto:devicetree-discuss-
bounces+dvomlehn=cisco@lists.ozlabs.org] On Behalf Of Mitch Bradley
Sent: Friday, July 06, 2012 5:25 PM
To: linux-arm-ker
On 7/5/2012 4:54 AM, Arnd Bergmann wrote:
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = marvell, orion-gpio;
...
On 7/3/2012 5:45 AM, Stephen Warren wrote:
On 07/03/2012 09:43 AM, Segher Boessenkool wrote:
There is still no reason for the fake bus node to have a compatible
property though. What could it possibly mean? This bus does not
exist at all but you access it in bla bla bla way? That just
On 7/2/2012 7:43 AM, Stephen Warren wrote:
On 07/02/2012 11:23 AM, Mitch Bradley wrote:
On 7/2/2012 5:59 AM, Stephen Warren wrote:
On 07/01/2012 01:36 PM, Rob Herring wrote:
On 06/28/2012 06:05 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
An enumerated bus is one
On 6/28/2012 7:50 AM, Stephen Warren wrote:
On 06/27/2012 06:57 PM, Mitch Bradley wrote:
On 6/27/2012 11:26 AM, Stephen Warren wrote:
I believe I've seen the following construct bandied about as the correct
way of representing a bunch of nodes that have the same name (since they
represent
On 6/28/2012 8:21 AM, Mitch Bradley wrote:
On 6/28/2012 7:50 AM, Stephen Warren wrote:
On 06/27/2012 06:57 PM, Mitch Bradley wrote:
On 6/27/2012 11:26 AM, Stephen Warren wrote:
I believe I've seen the following construct bandied about as the
correct
way of representing a bunch of nodes
On 6/28/2012 8:49 AM, Mitch Bradley wrote:
On 6/28/2012 8:21 AM, Mitch Bradley wrote:
On 6/28/2012 7:50 AM, Stephen Warren wrote:
On 06/27/2012 06:57 PM, Mitch Bradley wrote:
On 6/27/2012 11:26 AM, Stephen Warren wrote:
I believe I've seen the following construct bandied about as the
correct
On 6/28/2012 10:51 AM, Stephen Warren wrote:
On 06/28/2012 02:28 PM, Mitch Bradley wrote:
On 6/28/2012 8:49 AM, Mitch Bradley wrote:
On 6/28/2012 8:21 AM, Mitch Bradley wrote:
On 6/28/2012 7:50 AM, Stephen Warren wrote:
On 06/27/2012 06:57 PM, Mitch Bradley wrote:
On 6/27/2012 11:26 AM
On 6/28/2012 12:02 PM, Stephen Warren wrote:
On 06/28/2012 02:58 PM, Mitch Bradley wrote:
On 6/28/2012 10:51 AM, Stephen Warren wrote:
On 06/28/2012 02:28 PM, Mitch Bradley wrote:
...
Hmmm
Ah yes.
I'd somewhat prefer to avoid calling of_translate_address() when we
know it's going
On 6/27/2012 2:43 AM, Sascha Hauer wrote:
Hi All,
I'd like to have a possibility to describe fixed display modes in the
devicetree. This topic has been discussed before here:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html
The result at that time was that EDID data
On 6/27/2012 11:26 AM, Stephen Warren wrote:
I believe I've seen the following construct bandied about as the correct
way of representing a bunch of nodes that have the same name (since they
represent the same type of object) within device-tree.
regulators {
compatible =
On 6/25/2012 1:49 PM, Rob Herring wrote:
On 06/25/2012 03:23 PM, Alexandre Pereira da Silva wrote:
Grab the devicetree node properties to override VendorId, ProductId,
bcdDevice, Manucacturer, Product and SerialNumber
Signed-off-by: Alexandre Pereira da Silva aletes@gmail.com
---
On 6/20/2012 8:47 PM, Thierry Reding wrote:
On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
On 6/19/2012 3:30 AM, Thierry Reding wrote:
On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
On 06/14/2012
On 6/21/2012 9:45 AM, Mark Brown wrote:
On Thu, Jun 21, 2012 at 05:17:45PM +, Arnd Bergmann wrote:
On Thursday 21 June 2012, Mark Brown wrote:
I'm not that big a fan of moving all the data into device tree as it
means that you need even more parsing code and you need to update the
device
On 6/20/2012 6:32 AM, Stephen Warren wrote:
On 06/19/2012 03:31 PM, Mitch Bradley wrote:
...
The third cell offset is necessary so that the size field has a number
space that can include it.
Can you expand on that sentence a bit more; I don't quite understand
that aspect. Thanks
On 6/20/2012 9:57 AM, Arnd Bergmann wrote:
On Tuesday 19 June 2012, Mitch Bradley wrote:
Version A - 3 address cells: In this version, the intermediate address
space has 3 cells: port#, address type, offset. Address type is
0 : root port
1 : config space
2 : extended config
On 6/19/2012 3:30 AM, Thierry Reding wrote:
On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
On 06/14/2012 01:29 PM, Thierry Reding wrote:
On Thu, Jun 14, 2012 at 12:30:50PM -0600, Stephen Warren wrote:
On
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 6/12/2012 8:45 PM, Thierry Reding wrote:
* Mitch Bradley wrote:
On 6/12/2012 10:15 AM, Stephen Warren wrote:
On 06/12/2012 11:20 AM, Thierry Reding wrote:
...
I came up with the following alternative:
pci {
compatible = nvidia,tegra20-pcie;
reg
On 6/12/2012 9:52 PM, Thierry Reding wrote:
On Tue, Jun 12, 2012 at 09:28:51PM -1000, Mitch Bradley wrote:
On 6/12/2012 8:45 PM, Thierry Reding wrote:
* Mitch Bradley wrote:
On 6/12/2012 10:15 AM, Stephen Warren wrote:
On 06/12/2012 11:20 AM, Thierry Reding wrote:
...
I came up
On 6/12/2012 10:19 PM, Thierry Reding wrote:
On Tue, Jun 12, 2012 at 10:05:35PM -1000, Mitch Bradley wrote:
On 6/12/2012 9:52 PM, Thierry Reding wrote:
I think the configuration spaces and downstream I/O ranges need to be in the
pcie-controller's reg property because they are remapped and used
On 6/12/2012 7:20 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 06/12/2012 12:21 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 06/11/2012 09:05 AM, Thierry Reding wrote:
This commit adds support for instantiating the Tegra PCIe
controller from a device tree.
+++
On 6/12/2012 9:46 AM, Stephen Warren wrote:
On 06/12/2012 01:10 PM, Mitch Bradley wrote:
On 6/12/2012 7:20 AM, Thierry Reding wrote:
...
I came up with the following alternative:
pci {
compatible = nvidia,tegra20-pcie;
reg =0x80003000 0x0800
On 6/12/2012 10:15 AM, Stephen Warren wrote:
On 06/12/2012 11:20 AM, Thierry Reding wrote:
...
I came up with the following alternative:
pci {
compatible = nvidia,tegra20-pcie;
reg =0x80003000 0x0800 /* PADS registers */
On 6/5/2012 7:25 PM, Haojian Zhuang wrote:
...
mmp2-brownstone.dts is too complex since both apbaxi are imported.
Could we only use flat structure in mmp2-brownstone.dts?
See http://dev.laptop.org/~wmb/mmp2-devicetree/mmp2-brownstone-flat.dts
/Brownstone
in 3.5-rc1. We're looking at adopting the MMP2 device tree for the OLPC
XO-1.75 board, and Mitch Bradley has some corrections to the device tree
format that we'd like to make, appended below.
You can see all of the files Mitch mentions at:
http://dev.laptop.org/~wmb/mmp2-devicetree
. Update PXA168 dts files for irq,
timer, gpio components.
The patch I'm replying to introduced a device tree for MMP2/Brownstone
in 3.5-rc1. We're looking at adopting the MMP2 device tree for the OLPC
XO-1.75 board, and Mitch Bradley has some corrections to the device tree
format that we'd like
On 6/3/2012 2:05 AM, Mark Brown wrote:
On Sat, Jun 02, 2012 at 09:45:10PM -0500, Rob Herring wrote:
I tend to agree with Steven's and Olof's comments in this thread. As the
node names generally don't have much meaning, I don't think we should
start now. We've already got multiple styles of
There are some inconsistencies in this patch as indicated in-line below:
On 3/5/2012 2:21 AM, Haojian Zhuang wrote:
Add OF support in Document/devicetree directory.
Signed-off-by: Haojian Zhuanghaojian.zhu...@marvell.com
---
Documentation/devicetree/bindings/arm/mrvl.txt |6 +++
I like the general approach of simplifying the pinctrl thing, as the
previous approach did not appear to be converging.
One possible name would be gpconfig - for general purpose configuration.
The register access model in the strawman proposal is probably too
simple. 32-bit memory mapped
On 2/6/2012 9:26 AM, Linus Walleij wrote:
On Mon, Feb 6, 2012 at 8:05 PM, Mitch Bradleyw...@firmworks.com wrote:
I like the general approach of simplifying the pinctrl thing, as the
previous approach did not appear to be converging.
pinctrl as such is upstream, widely ACKed and quite
On 2/6/2012 7:33 PM, Stephen Warren wrote:
On 02/06/2012 11:05 AM, Mitch Bradley wrote:
I like the general approach of simplifying the pinctrl thing, as the
previous approach did not appear to be converging.
One possible name would be gpconfig - for general purpose configuration.
Sounds
On 1/23/2012 6:18 AM, Stephen Warren wrote:
Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warrenswar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen
On 1/20/2012 9:32 PM, Olof Johansson wrote:
Hi,
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warrenswar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git
On 1/13/2012 8:52 AM, Kumar Gala wrote:
We have some scenarios in which we might have 2 different drivers (one in kernel or one
user space as an example) and wanted to see how we'd convey in the device tree which
driver should claim the specific device instance.
From glancing at the OF specs
Sorry for the delay in responding; I just received the message today...
On 12/9/2011 2:25 PM, Michael Bohan wrote:
Hi,
I am designing a bus driver for the System Power Management Interface,
which is also known as SPMI. Information about the bus can be found
through this website:
On 1/11/2012 10:29 AM, Stephen Warren wrote:
Mitch Bradley wrote at Tuesday, January 10, 2012 11:43 PM:
On 1/10/2012 2:28 PM, Timur Tabi wrote:
Mitch Bradley wrote:
...
That GPIO pin thing is annoying, but not sufficiently complex or common
that it warrants having a separate EDID driver
On 1/11/2012 10:17 AM, Timur Tabi wrote:
Mitch Bradley wrote:
I think that would not be a good design. Presence and location of EDID
data is not something that a generic I2C driver should know. It's the
video controller that knows that EDID exists, where it is located
(device ID 0x50
I find it ironic that the very first device tree implementation, dating
back to 1989, was built around a Turing complete language.
On 1/11/2012 11:36 AM, Stephen Warren wrote:
Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM:
On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren
On 1/11/2012 2:15 PM, Stephen Warren wrote:
Mitch Bradley wrote at Wednesday, January 11, 2012 4:16 PM:
On 1/11/2012 10:29 AM, Stephen Warren wrote:
Mitch Bradley wrote at Tuesday, January 10, 2012 11:43 PM:
On 1/10/2012 2:28 PM, Timur Tabi wrote:
Mitch Bradley wrote:
...
That GPIO pin
More nits picked below ...
i2c1: i2c@7000c000 {
#address-cells =1;
#size-cells =0;
compatible = nvidia,tegra20-i2c;
reg =0x7000C000 0x100;
interrupts =0 38 0x04;
};
mux@0 {
The name i2cmux might be more evocative.
#address-cells =1;
#size-cells
On 1/10/2012 11:58 AM, Timur Tabi wrote:
Jamie Lokier wrote:
It still needs to know *which* I2C bus master is connected to the
display. Some graphics hardware has multiple, e.g. one to talk with
the DVI/HDMI transmitter, another connected by cable to the display.
Yes, this is my problem. I
1 - 100 of 162 matches
Mail list logo
