On Sat, Jul 06, 2013 at 01:38:35AM +0200, Arnd Bergmann wrote:
On Saturday 06 July 2013, Thomas Petazzoni wrote:
Arnd, Jason, if you could confirm that you both agree with this DT
binding soon, Ezequiel and I would quickly adapt the code accordingly,
and hopefully converge towards a final
On Fri, Jul 05, 2013 at 06:39:11PM -0300, Ezequiel Garcia wrote:
ranges =
0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
0x4 0 0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 MBUS_ID(0xf0, 0x01)
On Sat, Jun 29, 2013 at 04:04:03PM -0300, Ezequiel Garcia wrote:
In the current proposal we have now required a 'controller' property
to specify the MBus controller MMIO registers. To us this looks more
appropriate, since the MBus registers are effectively located within
the internal register
On Wed, Jun 19, 2013 at 02:11:58PM +0200, Arnd Bergmann wrote:
Mmm.. and why is this option acceptable?
As I explained on IRC, there is no requirement to pick a specific bus
aperture. The only two sensible choices are to make the bus address
the same as the CPU address, or to make the bus
On Wed, Jun 19, 2013 at 07:02:00AM -0300, Ezequiel Garcia wrote:
Verifying the DT is setup this way and aborting if it is not seems
like a good idea..
I agree it's a nice idea, but I'm not too sure how to accomplish this
in a simple and generic way. There's nothing in the DT that allows
On Wed, Jun 19, 2013 at 02:58:24PM -0300, Ezequiel Garcia wrote:
I wasn't sure you wanted to panic(), to clip on available CPUs,
or to just do a pr_warn / WARN(), so here's a piece of code:
(disclaimer: non-tested, non-compiled, etc.)
Up to you, but you know it won't work if it isn't right so
On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
I thought we agreed to something like:
SIAA
Where 'S' is the
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
Also allows you to have up to 40b offset, which might be important
with LPAE enabled.
Not with the current generation I
originally and was ignored.
Jason Gunthorpe might remember better, but I think he liked it when I
originally proposed doing it this way.
I remember it took a bit to understand your proposal, but I thought it
could work, but I admit I forget all the little details now :(
Ah, if I can just rephrase
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
S = 0 means 4 bit I, 8 bit A
S = F means special
S = 1 could mean 16 bit I, etc , etc
S 0x8 == 0x0 means 7b target
S 0x8 == 0x8 means 7b special ?
No need, special == mbus driver defined. There is no target ID.
The
On Tue, Jun 18, 2013 at 04:43:31PM -0300, Ezequiel Garcia wrote:
I think some kind of test is needed here. As I understand it the SMP
startup uses a trampoline in the boot rom and the boot rom *must* be
mapped to 0xfff0 ?
Yes, that's my understanding as well, but I will do some
On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
Having the kernel enforce that the DT node is present and at the right
location, I think, is helpful for the bootloader folks to ensure they
write correct DTs.
Granted. But then I wonder... why do we bother to put the BootROM
On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
The forms could
On Wed, Jun 12, 2013 at 05:02:50PM -0300, Ezequiel Garcia wrote:
I'm probably missing something, but... are you sure that's supposed to work?
Hum.
Looking through the yacc for dtc, it looks like all exprs must be enclosed
in (), so no it shouldn't work, sadly.
Jason
On Wed, Jun 12, 2013 at 06:12:22PM -0300, Ezequiel Garcia wrote:
Actually, the best thing about this solution is that we don't even
have to bother setting up the mappings when loading the mbus driver:
We don't need any ranges (other than internal-regs) in DT, and we
don't need complex
On Wed, Jun 12, 2013 at 11:52:32PM +0200, Arnd Bergmann wrote:
Whether that results in an optimum mapping or not depends on the actual
sizes for the child nodes. Since everything is a power-of-two size,
a first-fit algorithm actually isn't bad at all.
The windows must be aligned to their size.
On Tue, Jun 11, 2013 at 05:26:47PM +0200, Arnd Bergmann wrote:
That looks ok to me, yes. If you have just one device under some of the nodes
however, I think it's easier use an empty ranges property and do
devbus-bootcs {
ranges;
nor {
On Wed, Jun 12, 2013 at 12:34:14AM +0200, Arnd Bergmann wrote:
a significant waste of physical address space, because the (per-soc)
ranges property has to be set up for the largest possible external
device connected to the bus, but the mbus window only needs to cover the
device that is
On Wed, Jun 12, 2013 at 12:22:29AM +0200, Sebastian Hesselbarth wrote:
sorry to kick into this thread that late but Ezequiel made me think of
address windows when asking on IRC. From what I can see from your and
Arnd's proposal the only real difference is that having it Arnd's way
allows you
On Sat, Jun 08, 2013 at 03:38:52PM -0300, Ezequiel Garcia wrote:
mbus {
ranges = 0x012f 0 0xe800 0x800
devbus-bootcs {
ranges = 0 0x012f 0 0x800
}
}
We shouldn't mangle the DT format just to make it convenient for
humans to write - if
On Fri, Jun 07, 2013 at 01:59:43PM +0200, Arnd Bergmann wrote:
On Friday 07 June 2013 18:19:40 Jingoo Han wrote:
Hi Jason Gunthorpe,
I implemented 'Single domain' with Exynos PCIe for last two months;
however, it cannot work properly due to the hardware restriction.
Each MEM region
On Fri, Jun 07, 2013 at 09:01:44PM +0200, Arnd Bergmann wrote:
+- compatible: Should be set to one of the following:
+ marvell,armada370-mbus
+ marvell,armadaxp-mbus
I thought they are compatible with all older ones at the register level,
as long as we describe
On Fri, Jun 07, 2013 at 09:53:03PM +0200, Arnd Bergmann wrote:
Can you explain to me why it is an invalid target ID value? Is it
treated very differently by the mbus register setup than all the
others? I guess we can define it as something else to make a valid
target ID, by using one or more
On Fri, Jun 07, 2013 at 11:15:50PM +0200, Arnd Bergmann wrote:
The mbus driver should never read or write this register.
That is not a hard requirement, right? I guess based on the
recent discussion about the 0xd0 or 0xf1 window, there may
actually be good reasons to reassign it, although
On Thu, Jun 06, 2013 at 06:27:08PM +0200, Sebastian Hesselbarth wrote:
This patch set introduces DT-aware irqchip and clocksource drivers for
Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
patches for Dove and Kirkwood to enable them for DT-boards.
Looks broadly good
On Thu, May 02, 2013 at 09:05:38PM +0200, Sebastian Hesselbarth wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string? Looks to me
like either
On Thu, May 02, 2013 at 09:34:30PM +0200, Sebastian Hesselbarth wrote:
The compatible string should change if the binding changes in an
incomptible way, and we should try not to change it unless it's
fundamentally flawed.
Well, there is no _fundamental_ change in the binding syntax as it
On Mon, Apr 08, 2013 at 06:08:53PM +0900, Jingoo Han wrote:
I have a question. Now, I am reviewing the Tegra PCIe, Marvell PCIe
patchset. However, in the case of Exynos PCIe, 'downstream I/O' and
'non-prefetchable memory' are different between PCIe0 and PCIe1.
These regions are not shared.
On Fri, Apr 05, 2013 at 03:58:03PM +0200, Sebastian Hesselbarth wrote:
I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT
On Wed, Mar 27, 2013 at 05:35:48PM +0900, Jingoo Han wrote:
Here is the lspci -vv output.
I tested Exynos PCIe with e1000e lan card.
00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01) (prog-if
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV-
On Wed, Mar 27, 2013 at 07:05:02PM +0100, Thomas Petazzoni wrote:
This all looks really great to me, I hope to try it as well when I get
time. But just one small suggestion:
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index ea49476..1b4675f 100644
+++
On Tue, Mar 26, 2013 at 05:18:32PM +0100, Thomas Petazzoni wrote:
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+
On Tue, Mar 26, 2013 at 05:52:22PM +0100, Thomas Petazzoni wrote:
This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an IRQ domain
associated with the 'msi' node in the Device Tree, which the PCI
controller will refer to in
On Tue, Mar 26, 2013 at 09:46:13PM +0100, Thomas Petazzoni wrote:
To me, the topology of the hardware is really that a single device
provides two features: the main interrupt controller and the MSI
interrupt controller. But I will adapt to whatever DT binding you
propose.
No.. the HW is a
On Tue, Mar 26, 2013 at 10:16:54PM +0100, Thomas Petazzoni wrote:
FWIW, MSI-X is not restricted to 16 bits, so if you can detect from
the PCI layer if it is setting up MSI or MSI-X you could allocate low
bits first to MSI-X and high bits first to MSI, increasing the number
of available
On Tue, Mar 26, 2013 at 11:06:56PM +0100, Thomas Petazzoni wrote:
The PCIe host driver just seems to get in the way, it has no knowledge
it is adding to the process.
irqchip knows:
- what the physical address of the doorbell is
- how to construct an address that is per-cpu or
On Tue, Mar 26, 2013 at 10:27:44PM +0100, Thomas Petazzoni wrote:
Is this correct? Thierry, Jason, if you could confirm my understanding,
that would be great. I could then rework and resend the patch set.
It looked to me the same as what Thierry was doing, and Thierry's
looked like it included
On Sat, Mar 23, 2013 at 01:09:18PM +0900, Jingoo Han wrote:
+ pcie0@4000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+
On Fri, Mar 22, 2013 at 07:28:54AM +0100, Andrew Lunn wrote:
IO space needs to stay where it is, somewhere in the top 1GB, because
it is limited to the 32bit address space.
Yes
We must have some SDRAM in the bottom of the 40bit address range in
order that DMA works. Bounce buffers are used
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:
Dear Jason Gunthorpe,
On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:
Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 - 8GB
I see two potential issues
On Thu, Mar 21, 2013 at 11:35:21PM +0200, Lior Amsalem wrote:
*) It would require Linux to change the internal registers address
(for now the kernel relies on the bootloader). The problem is that
we can't do it early enough to preserve the earlyprintk
functionality. Maybe you
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
It turns out that this works with the Tegra driver because it uses the
new of_pci_process_ranges() function and simply overwrites earlier
matches by subsequent ones.
ranges = 0x8200 0 0
On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1
registers */
0x8100 0 0 0x8200 0 0x0001
On Wed, Mar 13, 2013 at 09:18:15AM +0100, Thierry Reding wrote:
Mitch already answered this. The specification is now almost 15 years
old and it couldn't possibly have foreseen all of the future use-cases.
If the specification is too restrictive and Mitch gives his blessing to
remove some of
On Wed, Mar 13, 2013 at 08:26:28PM +0100, Thierry Reding wrote:
As Mitch already said there's very little chance that the specification
update will be ratified through IEEE, so I think that we might just as
well put a corresponding text somewhere below Documentation/devicetree.
Sure, I'm fine
On Wed, Mar 13, 2013 at 11:02:35PM +0100, Thierry Reding wrote:
Does that look about correct?
By my reading of the spec the entries in ranges should not
have the b,d,f bits set..
Although it is not a big stretch to include them..
Now the code will actually match the first entry and assume
On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
port hardware used the common programming model, with real config
headers and stuff, 3/2 would be good because you could use existing
drivers. But since you need a special root-port driver anyway, why go
to the trouble of
On Tue, Mar 12, 2013 at 08:08:52AM +0100, Thierry Reding wrote:
So to recapitulate, we agree that configuration space can be translated
through the ranges property. That means the only missing link is a new
function to translate not only assigned-addresses but also the reg
property for PCI
On Tue, Mar 12, 2013 at 09:38:19PM +0100, Thierry Reding wrote:
I've also verified that things actually do work with the binding that I
proposed for Tegra, even if I add device_type = pci to the root port
nodes. The reason is that the OF core looks up the type of the *parent*
node to find a
On Tue, Mar 12, 2013 at 10:30:06PM +0100, Thierry Reding wrote:
Not going down the of_pci_* code paths for address translation at the
root port bridge nodes is certainly not right.
I'm not so sure. Why should the pcie-controller be a PCI device?
The spec is clear on that point as well:
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 functions so common PCI enumeration code will
(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 {
if (to_devfn(ranges_entry.child) ==
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 to run in bridge mode. So
Marvell really
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 nutshell (since some of the context isn't quoted anymore) the
problem that we're trying to solve is that
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 in the address space defined by its parent -
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 in that posting looks messed up to me.
1
On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
- dev-err_interrupt = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ if (pdev-dev.of_node) {
+ dev-regs = of_iomap(pdev-dev.of_node, 0);
+ if (!dev-regs) {
+
On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion
On Fri, Jan 25, 2013 at 11:34:55AM +0100, Guennadi Liakhovetski wrote:
Is there no need to reset the phy at runtime ?
No idea, I'm not developing the driver, I'm just porting one specific
feature from one API to another with no functional changes (apart from
postponing setting the GPIO).
On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
In either of those cases, does it make sense to use the MSI support
outside the scope of the PCI infrastructure? That is, would devices
other than PCI devices be able to generate an MSI?
I've come around to your way of
On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote:
On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote:
On Thursday 10 January 2013, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote:
On Wed, Jan 09, 2013 at 04:12:31PM -0700
On Thu, Jan 10, 2013 at 08:03:27PM +0100, Thierry Reding wrote:
You'd piece a mapping together, each bus requires 16 64k mappings, a
simple 2d array of busnr*16 of pointers would do the trick. A more
clever solution would be to allocate contiguous virtual memory and
split that up..
On Thu, Jan 10, 2013 at 09:20:07PM +0100, Thierry Reding wrote:
Arnd's version is good too, but you would be restricted to aligned
powers of two for the bus number range in the DT, which is probably
not that big a deal either?
Stephen suggested on IRC that we could try to keep a bit of
On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote:
On 01/09/2013 03:10 PM, Arnd Bergmann wrote:
On Wednesday 09 January 2013, Thierry Reding wrote:
What happens on Tegra is that we need to map 256 MiB of physical memory
to access all the PCIe extended configuration space.
On Wed, Dec 19, 2012 at 12:54:51PM +, Grant Likely wrote:
Then it sounds like you really don't want PCI addressing in the
children. It sounds like the children addresses need to be in the form
[bar#] [offset-from-base-of-bar]. In that case, you need the
appropriate
They should be
On Fri, Dec 14, 2012 at 08:26:29PM +, Grant Likely wrote:
If the soc_devices are getting triggered on that and they shouldn't be,
then we need a mechanism in the soc_bridge node to kick out of that
behavoir for its children.
Is this what you were thinking?
Not really. I see
cases where the PCI device may be a complex
SOC with no PCI based partitioning of sub-functionality.
Tested on an ARM kirkwood system
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/of/address.c | 29 +
1 files changed, 29 insertions(+), 0
On Fri, Nov 30, 2012 at 09:48:05AM +, Grant Likely wrote:
If you attempt to stick a 'reg' in a block nested below a
'device_type=pci' the kernel throws lots of error messsages and
generates bad address mappings.
Have you added the appropriate #address-cells and #size-cells to the pci
On Thu, Nov 29, 2012 at 04:26:48PM +, Grant Likely wrote:
Hmmm. okay that makes sense, but something still isn't quite right. So
of_translate_address should take care of drilling down through the bus
layers, and when it gets to the PCI node it /should/ use
of_bus_pci_translate to handle
On Mon, Nov 26, 2012 at 02:03:16PM +, Grant Likely wrote:
On Wed, 21 Nov 2012 14:02:40 -0700, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
'assigned-addresses' is used for certain PCI device type nodes in
lieu of 'reg', since this is enforced by of/address.c, have
This allows platform_device_add a chance to call insert_resource
on all of the resources from OF. At a minimum this fills in proc/iomem
and presumably makes resource tracking and conflict detection work
better.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers
On Wed, Nov 21, 2012 at 03:51:04PM +, Grant Likely wrote:
On Wed, 21 Nov 2012 00:24:48 -0700, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
This allows platform_device_add a chance to call insert_resource
on all of the resources from OF. At a minimum this fills in proc/iomem
On Wed, Nov 21, 2012 at 06:07:46PM +, Grant Likely wrote:
Which is nesting the generic gpio driver under a larger region..
Try two sibling nodes with overlapping addresses. There are powerpc
device trees doing that even though it isn't legal by the ofw and
epapr specs.
Both my
'assigned-addresses' is used for certain PCI device type nodes in
lieu of 'reg', since this is enforced by of/address.c, have
of_device_make_bus_id look there as well.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/of/platform.c |2 ++
1 files changed, 2
On Thu, Nov 22, 2012 at 03:36:21PM +, Grant Likely wrote:
Hmm... I've not tried it with assigned-address. I tried with two sibling
platform devices using just the 'reg' property. That the kernel will
complain about. For powerpc-only, the patch I posted allows the device
to get registered
76 matches
Mail list logo
