Re: [PATCH 00/10] Orion Watchdog fixes

On Tue, Jul 16, 2013 at 11:04:36AM -0300, Ezequiel Garcia wrote: > On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote: > > On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote: > > > On the other side, I'm much interested in knowing if you are OK

Re: [PATCH 00/10] Orion Watchdog fixes

regression? etc." Although I hate the word, I think 'refactoring' is much more appropriate description for this series. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 06/10] watchdog: orion: Update device-tree binding documentation

On Mon, Jul 15, 2013 at 08:32:39PM -0300, Ezequiel Garcia wrote: > Now that the 'reg' property meaning has been changed, > this commit updates the deivce-tree binding documentation. nit. s/deivce/device/ > > Signed-off-by: Ezequiel Garcia > --- > Documentation/devicetree/bindings/watchdog/orio

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Sat, Jul 13, 2013 at 12:56:25PM -0700, Olof Johansson wrote: > On Wed, Jul 10, 2013 at 2:50 PM, Jason Cooper wrote: > > On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote: > >> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper wrote: > >> > On Wed, Ju

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Fri, Jul 12, 2013 at 10:05:45AM -0600, Daniel Drake wrote: > On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper wrote: > > This also means we should do a patch for stable v3.5+ appending the > > "mrvl,..." string to the drivers that had it removed improperly, as >

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

} * I can't find where Arnd's suggestion was, so this hack is completely my own. Keep in mind, the above hack is just a suggestion, it makes my skin crawl just looking at it... I'm open to other ideas. Or, not doing it at all. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote: > On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper wrote: > > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote: > >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper wrote: > >> > Neil, > &g

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Wed, Jul 10, 2013 at 03:50:10PM -0500, Matt Sealey wrote: > On Tue, Jul 9, 2013 at 7:49 AM, Jason Cooper wrote: > > Neil, > > > > I agree with the need to change, however, this has been in the binding > > documentation since v3.5. I wish we had caught this when w

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote: > On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper wrote: > > Neil, > > > > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote: > >> The documented vendor prefix for Marvell is 'marvell&#x

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

Neil, On Wed, Jul 10, 2013 at 12:25:17AM -0700, Neil Zhang wrote: > Jason, > > > -Original Message- > > From: Jason Cooper [mailto:ja...@lakedaemon.net] > > Sent: 2013年7月9日 20:49 > > To: Neil Zhang > > Cc: grant.lik...@linaro.org; haojian.zhu...@gmai

Re: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout

On Tue, Jul 09, 2013 at 12:50:47PM -0600, Bjorn Helgaas wrote: > On Tue, Jul 9, 2013 at 12:20 PM, Jason Cooper wrote: > > Bjorn, > > > > On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote: > >> From: Thomas Petazzoni > >> > >> The ne

Re: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout

est of the series on. Reshuffling the series to alleviate this wouldn't work in this case. :-/ Are you ok with that? (fwiw, the code changes are isolated to pci-mvebu.c) thx, Jason. [1] http://www.spinics.net/lists/arm-kernel/msg257447.html > > diff --git a/Documentation/devicet

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

ible with the old and the new names, and the binding docs updated to reflect the legacy name and the preferred name. thx, Jason. > diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt > b/Documentation/devicetree/bindings/arm/mrvl/intc.txt > index 8b53273..ad27548 100644 >

Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back

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 hopeful

Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back

an idea how to encode MBUS_ID in the PCI-E ranges :( Arnd? Didn't you have some idea? FWIW, I like removing the string tables from the driver, you could keep the fake MBUS-ID and retain that change by adding a marvell,target-id type property to the bridges... Jason ___

Re: [PATCH v5 00/12] MBus DT binding: A new hope

pace not covered by the memory node or any mbus ranges? Is there a situation where that is not sufficient? > For now, this property is intentionally missing, and I expect that > it can be added in the future, together with the full-dynamic MBus > implementation. > > @Arnd, @Jason: Given

Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation

commit will make future improvements on the MBus DT binding easier. > > Signed-off-by: Ezequiel Garcia > --- > Tested on Plathome Openblocks A6 board. > > arch/arm/boot/dts/kirkwood.dtsi | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Applied to mvebu/dt thx,

Re: [PATCH V10 0/4] PCIe support for Samsung Exynos5440 SoC

nusW that you both had patches depending on (now called) mvebu/of_pci. So we got it into arm-soc early so those branches could depend on it. hth, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4 06/12] memory: mvebu-devbus: Remove address decoding window workaround

2, Greg's tree will be merged by then. At which time, we can decide if it's best to keep the series together or continue to send devbus changes through him. I'm fine either way, and but I have a preference for keeping the series together. thx, Jason. _

Re: [PATCH v4 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

that are guaranteed to be free of > overlaps > +with one another or with the system memory ranges. > + > +Each entry in the property refers to exactly one window. If the operating > system > +choses to use a different set of mbus windows, it must ensure that any > address &g

Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

eed to be free > > of overlaps with one another or with the system memory ranges. > > Each entry in the property refers to exactly one window. If an > > operating system choses to use a different set of mbus windows, > > it mus

Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation

On Wed, Jun 19, 2013 at 03:42:27PM -0300, Ezequiel Garcia wrote: > On Wed, Jun 19, 2013 at 3:36 PM, Jason Cooper wrote: > > On Tue, Jun 18, 2013 at 04:47:57PM -0300, Ezequiel Garcia wrote: > >> On Tue, Jun 18, 2013 at 09:42:48PM +0200, Sebastian Hesselbarth wrote: > >&g

Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation

0 0xf400 0x400 > > > 0xf500 0xf500 0x400>; > > > > Ezequiel, > > > > maybe you should also put a comment at the end of each ranges > > line to name the remap it does? > > > > Also, as already menti

Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

t work if it isn't right so continuing on to try and startup the CPUs is not ideal. panic is probably reasonable? > node = of_find_compatible_node(NULL, NULL, "bootrom"); "marvell,bootrom" ? Jason ___ devicetree-disc

Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

You'll need to define a bootrom binding. There is not a lot of sense in including things in the DT if the kernel can't find them and use them. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes

n the PCI bus. IMHO, a 1:1 mapping between PCI and CPU is strongly preferred. Any other configuration will need some additional techniques to avoid aliasing. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozla

Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

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: > &

Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

we bother to put the BootROM in the > DT window if we're going to check for a fixed address it in any case? Code re-use in the mbus driver? Maybe future SOCs in this family will have programmable SMP startup addresses? Non-SMP systems don't need

Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

correct DTs. > Maybe this is a requirement for this SoC, but not for another... > so, why should the kernel *check* for that? The function was called armada_xp_smp_prepare_cpus - all Armada XP's will work like this.. Jason ___ devicetree

Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

, the only issue with the 32 bit offset is if we need to describe an offset into a target in DT that is larger than 32 bits. The only use of offsets in DT is for internal regs. The need for a > 32 bit offset in DT does not exist with the current architecture. Jason __

Re: [PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes

t; existing PCIe DT binding that has been discussed at length with you? > > I'm pretty sure I explained the idea above 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

Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

thing that could possibly do that is PCI-E, and it is all special anyhow.. The mbus top level ranges remap already supports >4G locations for the windows, even though current hardware cannot do that. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

Where 'S' is the designator for the special items like PCI-E and internal-regs. 0 = normal target ids, 0xF = special ids. The target is only 4 bits, the attr is 8, so a little doc update to clarify this should be enough, no need to change the DTs. Jason __

Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

ampoline in the boot rom and the boot rom *must* be mapped to 0xfff0 ? Verifying the DT is setup this way and aborting if it is not seems like a good idea.. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround

On Tue, Jun 18, 2013 at 02:17:31PM +0200, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Tue, 18 Jun 2013 07:39:20 -0400, Jason Cooper wrote: > > On Tue, Jun 18, 2013 at 08:25:31AM -0300, Ezequiel Garcia wrote: > > > Now that mbus device tree binding has been introd

Re: [PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround

is going through gregkh's tree. Either this patch needs to wait for v3.12, or ask Greg if he can take this one. thx, Jason. > > diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c > index 978e8e3..94c9248 100644 > --- a/drivers/memory/mvebu-devbus.c &

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

igned to their size. eg 1M size window must be aligned to a 1M boundary. First fit only works if you allocate from largest alignment requirement to smallest, otherwise the worst case is something like nearly double the largest alignment wasted in alignment p

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

ate Arnd's earlier comment: The DT representation must handle dynamic allocation, but we can defer implementing the kernel side until there is a need. It isn't clear to me there is a need. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

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 w

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

child > nodes. Arnd already said that mbus isn't "simple-bus" anymore, why > can't it just walk through the nodes and collect required windows? With enough restrictions, I think it is pretty easy to parse marvell,mbus-target, but you can

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

;t have the information or the code to mess with it - so this isn't possible 2) More space for the PCI-E aperture - this is entirely controlled by the kernel, but today we are using the pre-set allocation from the DT, so it doesn't matter how tightly the rest of t

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

ent of that window makes sense to me. (however, this also looks a bit tricky, how do you avoid hitting the PCI-E window reservations, for instance?) Unconditional dynamic assignment is a bit more tricky, for instance the boot rom has to be located at a speci

Re: [PATCH 0/6] Marvell Orion SoC irqchip and clocksource

rivers are queued for next release. > > I can take it through tip if nobody else wants it :) Great! I'll queue up 3-6 for the next merge window. That way we avoid all branch dependencies. :) thx, Jason. ___ devicetree-discuss mailing list devi

Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer

and to John and Thomas. I take the patches for > >> clockevents (and also for clocksource if both are mixed and John did not > >> pick it yet) and Thomas pulls from my tree [1]. > >> > >> If there is no dependency with any other patches of your patchset, which > >

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

oth internal regs and a target id in one binding. Which is why the last DW in the address must be the offset into the target, not something else. > What do you think? IMHO, creating a correct FDT is of primary importance, the maintainability of the text DT is secondary. We can always improve the

Re: [PATCH 12/14] ARM: mvebu: Remove device tree unused properties on A370

homas, applied to mvebu/dt with his Ack. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 01/14] bus: mvebu-mbus: Use pr_fmt

t; drivers/bus/mvebu-mbus.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) As Thomas mentioned, this patch has been applied to mvebu/cleanup with his Ack. thx, Jason. ___ devicetree-discuss mailing list devicetree-discus

Re: [PATCH 03/14] bus: mvebu-mbus: Introduce device tree binding

fully described in the binding document (Ezequiel, feel free to crib my text), and the 'special' IDs don't overlap with potentially valid target ids (ie don't use 0 == internal regs). Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 03/14] bus: mvebu-mbus: Introduce device tree binding

block -- o = offset within the target Which is pretty tidy.. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

t; > + }; > Again, I don't understand this part. For the purpose of specification, I > would not make a special case here. It is not a hardware property that makes > these special but the way we use it from Linux. Consequently I would suggest > we skip the PCI ranges in the initial boot time setup by identifying the > pcie-controller node by its "compatible" property. This is tricky :| The PCIE controller needs both target IDs and the aperture range to allocate them in. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 03/14] bus: mvebu-mbus: Introduce device tree binding

NTERNAL_REGS_MAP_ID is an invalid target ID value, defined to mean the internal registers target. 0x is a better choice for this than 0, because 0x is never going to be a valid target id, it is too large. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 6/6] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC

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 t

Re: [PATCH 0/6] Marvell Orion SoC irqchip and clocksource

te ridiculuous dependency havoc > of mv643xx_eth DT support (current net-next) that will add to both irqchip > and clocksource branches respectively. Therefore, I suggest that irq > and clocksource maintainers take in the mere drivers (Patches 1+2) and > Jason Cooper handles the re

Re: [PATCH 0/6] Marvell Orion SoC irqchip and clocksource

s broadly good to me, based on a quick read through all the patches. Regards, Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: DT version of kirkwood_ge0x_init()

pointer > >would be more than appreciated. > > Hmm, sometimes I am also lost especially about when branches will be > merged. Jason can tell you for sure. Basically, patches go into some > maintainer's or submaintainer's branch first. In the simple case, we look at the dif

Re: DT version of kirkwood_ge0x_init()

On Tue, Jun 04, 2013 at 08:05:00AM -0400, Jason Cooper wrote: > On Tue, Jun 04, 2013 at 01:59:27PM +0200, Simon Guinot wrote: > > On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote: > > > On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote: > &g

Re: DT version of kirkwood_ge0x_init()

On Tue, Jun 04, 2013 at 01:59:27PM +0200, Simon Guinot wrote: > On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote: > > On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote: > > > On 06/04/13 12:18, Gerlando Falauto wrote: > > > >I noticed

Re: DT version of kirkwood_ge0x_init()

ian's hard work, we'll finally be able to remove them and kirkwood will be completely DT. We're very excited about this. :) Next, we'll move the Marvell DT boards over to mach-mvebu/ and only legacy boards in -kirkwood/, -orion5x/, -dove/, and

Re: [PATCHv3 0/3] Add G762/G763 PWM fan controller

anch/repository. If there are hwmon fixes in it, > they should be submitted to the lm-sensors mailing list. Yes, please, unless you *need* a patch to build/boot that isn't in mainline yet, always base off of one of Linus' tags, eg v3.10-rc4. Then

Re: [PATCH -next] pci: mvebu: fix return value check in mvebu_pcie_probe()

d-off-by: Wei Yongjun > --- > drivers/pci/host/pci-mvebu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to mvebu/pcie. FYI: mvebu/pcie_bridge, and mvebu/pcie_kirkwood have been rebased on top of this change. thx, Jason. ___ d

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote: > On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth > wrote: > > On 05/23/2013 08:40 PM, Jason Cooper wrote: > > >> I think marvell,psc1_reset =<>; gives us the most flexibility in > >

Re: [PATCH V3 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs

On Wed, May 22, 2013 at 09:25:02PM +0200, Simon Baatz wrote: > Hi Jason, > > On Tue, May 21, 2013 at 09:14:55AM -0400, Jason Cooper wrote: > > On Tue, May 21, 2013 at 01:01:41AM +0200, Simon Baatz wrote: > > > Hi, > > > > > > V3 changes: > &g

Re: [PATCH V3 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs

it is currently my primary email server, dhcp, dns, file server, and a few other irreplaceable things. :( I *really* need to upgrade/reconfigure ... thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv10 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

On Sun, May 19, 2013 at 04:47:03PM -0400, Jason Cooper wrote: > On Thu, May 16, 2013 at 05:55:20PM +0200, Thomas Petazzoni wrote: > > The Armada 370 has two gatable clocks for each PCIe interface, and we > > want both of them to be enabled. We therefore make one of the two > &

Re: [PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property

On Mon, May 20, 2013 at 09:03:00AM +0200, Linus Walleij wrote: > On Sun, May 19, 2013 at 10:31 PM, Jason Cooper wrote: > > > patches 2, 3, and 4 applied to mvebu/of_pci to facilitate others > > (LinusW) basing their work off of it. > > Thanks, is this going to be pull

Re: [PATCHv10 9/9] arm: mvebu: update defconfig with PCI and USB support

XHCI controller > connected on the PCIe bus, enable the corresponding options as well. > > Signed-off-by: Thomas Petazzoni > --- > arch/arm/configs/mvebu_defconfig |3 +++ > 1 file changed, 3 insertions(+) Applied to mvebu/defconfig thx, Jason. _

Re: [PATCHv10 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

Thanks for the head's up on the clk conflict. My resolution should match yours. Please let me know if it doesn't. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property

67 > > include/linux/of_address.h | 48 +++ > 2 files changed, 115 insertions(+) patches 2, 3, and 4 applied to mvebu/of_pci to facilitate others (LinusW) basing their work off of it. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv10 1/9] arm: mvebu: fix the 'ranges' property to handle PCIe

gt; arch/arm/boot/dts/armada-370.dtsi|3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) Applied to mvebu/fixes thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

On Fri, May 17, 2013 at 12:08:26AM -0700, Mike Turquette wrote: > Quoting Jason Cooper (2013-05-16 08:06:16) > > Mike, Sebastian, > > > > On Thu, May 16, 2013 at 10:26:24AM +0200, Sebastian Hesselbarth wrote: > > > On 05/16/2013 09:44 AM, Thomas Petazzoni wro

Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems

On Thu, May 16, 2013 at 12:12:02PM -0400, Jason Cooper wrote: > On Thu, May 16, 2013 at 06:08:50PM +0200, Thomas Petazzoni wrote: > > Dear Jason Cooper, > > > > On Thu, 16 May 2013 11:56:17 -0400, Jason Cooper wrote: > > > > > > > > Building th

Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems

On Thu, May 16, 2013 at 06:08:50PM +0200, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Thu, 16 May 2013 11:56:17 -0400, Jason Cooper wrote: > > > > > > Building this showed a warning here. It seems you forgot > > > > > to mark this one as __init.

Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems

On Thu, May 16, 2013 at 05:49:03PM +0200, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Thu, 16 May 2013 11:40:31 -0400, Jason Cooper wrote: > > > > > +static int mvebu_pcie_init(void) > > > > > > Building this showed a warning here. It seems y

Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems

"PCIe%d.%d: cannot get clock\n", > > + port->port, port->lane); > > + iounmap(port->base); > > + port->haslink = 0; > > + continue; > > + } > > + > &

Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

o take these through arm-soc. Any merge conflicts should be minimal. And at any rate, resolving the conflicts are *much* easier to handle than having arm-soc depend on an outside tree (then Linus has to take care in the order he merges them, no rebasing for clk tree, dogs and cats living together, etc ;-) ) thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2 10/10] ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA

rch/arm/mach-kirkwood/board-sheevaplug.c | 27 +++ > arch/arm/mach-kirkwood/common.h |5 + > 5 files changed, 44 insertions(+) > create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c Applie

Re: [PATCH V2 09/10] ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug

ts > create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts Applied to mvebu/dt thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2 07/10] ARM: mvebu: Use standard MMC binding for all users of mvsdio

boot/dts/kirkwood.dtsi|4 > 10 files changed, 17 insertions(+), 1 deletion(-) Applied to mvebu/dt thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2 07/10] ARM: mvebu: Use standard MMC binding for all users of mvsdio

pinctrl-0 = <&pmx_sdio &pmx_sdio_cd>; > pinctrl-names = "default"; > status = "okay"; > - cd-gpios = <&gpio1 15 0>; > + cd-gpios = <&gpio1 15 1>; Is this a bugfix th

Re: [PATCH] pinctrl: dove: add PMU functions to pinctrl

On Mon, May 13, 2013 at 10:03:57PM +0200, Sebastian Hesselbarth wrote: > On 05/13/2013 10:00 PM, Jason Cooper wrote: > >On Tue, May 07, 2013 at 01:36:08AM +0200, Sebastian Hesselbarth wrote: > >>Dove power management unit can mux some special functions to mpp0-15. > >>

Re: [PATCH] pinctrl: dove: add PMU functions to pinctrl

> updated accordingly. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Linus Walleij > Cc: Jason Cooper > Cc: Stephen Warren > Cc: Thomas Petazzoni > Cc: Greg Kroah-Hartman > Cc:

Re: [PATCH 1/3] clk: mvebu: add gate ctrl for Prestera kirkwood variants

+-> kirkwood-prestera.dtsi +-> kirkwood-6282.dtsi or, kirkwood.dtsi prestera.dtsi -pinctrl- kirkwood-98dx4122.dtsi (should rename to prestera-, but seems churn-ish) kirkwood-6281.dtsi kirkwood-6282.dtsi -dts- kirkwood-km_kirkwood.dts (rename/churn prestera-?) |-prester

Re: [PATCH 3/3] ARM: kirkwood: remove clock gating disabling for km_kirkwood

#clock-cells = <1>; > + }; > }; > }; --->8 Please split this into two patches, one for the dtsi, and one for code removal. It'll prevent merge conflicts and branch dependencies for us. thx, Jason. > diff --git a/arch/arm/ma

Re: [PATCH 0/7] mv643xx_eth: device tree bindings

n figure this out, I'd like to do the same for the kirkwood-pcie series. thoughts? thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/3] ARM: dove: add DT parsing for legacy timer

an stay, the init code will vanish as soon as there is true > device tree support for orion timer. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Thomas Gleixner > Cc: Russell King > Cc: Arnd Bergm

Re: [PATCH 1/3] ARM: dove: add DT parsing for legacy mv643xx_eth

an stay, the init code will vanish as soon as there is true > device tree support for mv643xx_eth. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Thomas Gleixner > Cc: Russell King > Cc: Arnd Bergm

Re: [PATCH v2 2/5] ARM: dove: add DT parsing for legacy mv643xx_eth

On Fri, May 03, 2013 at 07:06:32AM +0200, Andrew Lunn wrote: > Jason: what is the status of the ethernet driver conversion to DT? > Will it get merged this week, or is it material for the next merge > window? You'd have to ask Florian/David Miller. I'm not sure wether David wa

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

On Fri, May 03, 2013 at 12:37:20AM +0200, Sebastian Hesselbarth wrote: > (@Jason C: Are you sure that I should merge dove and orion > irqchip patches? I doubt that anything touching generic irq > will not go through irq tree.) Putting them in the same patch series does not imply they h

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote: > On 05/02/2013 09:35 PM, Jason Gunthorpe wrote: > >I have kirkwood HW but I haven't had time to make newer kernels run on > >it, otherwise I'd test it too :( > > I also have kirkwood HW but t

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

oint - the original binding was flawed in that regard :| Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

ned, I would keep the old name then.. The bridge controller can be called marvell,orion-intc-bridge, and if Dove needs a pmu controller, marvell,dove-intc-pmu ? > >.. which lets this go away, use the generic irqchip_init instead of > >orion_init_irq. > > Same as above. I have kir

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

; Signed-off-by: Sebastian Hesselbarth > --- > Note: This patch triggers a checkpatch warning for > WARNING: Avoid CamelCase: > > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Thomas Gleixner > Cc: Russell King > Cc: Arnd Bergmann > Cc: Jason C

Re: [PATCH 0/3] ARM: dove: prepare and move to orion irqchip driver

keep that patch with this series and prevent a cross-tree dependency. thx, Jason. > arch/arm/mach-dove/Kconfig|1 + > arch/arm/mach-dove/Makefile |4 +- > arch/arm/mach-dove/board-dt.c | 77 > - > 4 files changed, 87 inserti

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

+} Shouldn't this use the new IRQCHIP_DECLARE mechanism? > diff --git a/include/linux/irqchip/orion.h b/include/linux/irqchip/orion.h > +extern void orion_init_irq(void); .. which lets this go away, use the generic irqchip_init instead of orion_init_irq. Regards, Jason _

Re: [PATCHv1 3/3] hwmon: Add DT documentation for g762 driver

;1>; /* closed-loop control */ > + pwm_enable = <2>;/* PWM mode */ > + pwm_freq = <8192>; /* PWM reference clock freq */ > + fan_pulses = <2>;/* 2 pulses per rev */ > + fan_div =

Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing

On Mon, Apr 22, 2013 at 12:53:43PM -0400, Jason Cooper wrote: > On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote: > > This patchset factors out duplicated code associated with parsing PCI > > DT "ranges" properties across the architectures and introduces a

Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing

v3.9 once it drops. Several dependencies will be removed (since they will have been merged into v3.9). Once the rebase is done, I'll send a pull request to Arnd and Olof so we can get as many cycles on -next as possible. thx, Jason. > > Compared to the v7 sent by Andre

Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser

On Fri, Apr 19, 2013 at 09:19:50AM +0200, Gabor Juhos wrote: > 2013.04.18. 15:09 keltezéssel, Jason Cooper írta: > > On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote: > >> On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote: > >>> On Tue, Ap

Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser

function to use the new common > > > of_pci_range_parser. > > > > > > Signed-off-by: Andrew Murray > > > Signed-off-by: Liviu Dudau > > > Reviewed-by: Rob Herring > > > > Tested-by: Linus Walleij > > Jason - you may not have seen this, but here (Linus

Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

On Thu, Apr 18, 2013 at 01:48:32PM +0100, Grant Likely wrote: > On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper wrote: > > On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: > > > On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper > > > wrote: > > >

  1   2   3   4   5   >