ux500 DT related fixes and platform enhancements
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
Quoted 8 lines · Lee Jones
Lee Jones (14):
ARM: ux500: Change IRQ from low-to-high edge triggered to high-to-low
ARM: ux500: Include the PRCMU's Secure Registers in DB8500's DT
ARM: ux500: Provide a means to obtain the SMSC9115 clock when DT is enabled
clk: ux500: Ensure the FMSC clock is obtainable
clk: ux500: Provide an alias for the SMSC911x Ethernet chip net/smsc911x: Provide common clock functionality
mmc: mmci: Moveios_handlerfunctionality into the driver
This patch lacks acks from MMC maintainers. Actually, it should just be submitted like any other MMC patches; to Chris Ball and the MMC list.
Quoted 7 lines
ARM: ux500: Set correct MMCI regulator voltages in the ux5x0 Device Tree
ARM: ux500: Specify the ux5x0 MMCI regulator's on/off GPIO as high-enable
ARM: ux500: Specify which IOS regulator to use for MMCI
ARM: ux500: Use the correct name when supplying a GPIO enable pin
ARM: ux500: Setup correct settling time for the MMCI regulator
ARM: ux500: Use the GPIO regulator framework for SDI0's 'en' and 'vsel'
ARM: ux500: Remove traces of theios_handlerfrom platform code
So, the most of these patches really are just ux500 platform patches. Please start queuing these through the ux500 maintainers, i.e. Linus and Srinidhi. We've had cases in the past where you and him step on each others toes (as with the mach/id.h removal), due to lack of coordination. It's definitely easier for everyone if the patches come through (and get acked by) one entity.
The obvious way of doing this is to make sure that Linus (and Srinidhi) are in control of what's going in and when, so they can resolve conflicts and not have them break the whole platform for everybody due to changes they have been unaware of.
-Olof
Quoted 5 lines · Olof Johansson
Quoted 1 line
mmc: mmci: Move
ios_handlerfunctionality into the driverThis patch lacks acks from MMC maintainers. Actually, it should just be submitted like any other MMC patches; to Chris Ball and the MMC list.
Actually this one driver usually goes through Russell's tree. He was OK with Lee pushing it this way, although I don't know if he got a formal ACK?
It doesn't hurt to have Chris' ACK on it too though.
Yours,
Linus Walleij
Chris Ball
Acked-byHi,
Quoted 8 lines · Linus Walleij
Quoted 5 lines · Olof Johansson
Quoted 1 line
mmc: mmci: Move
ios_handlerfunctionality into the driverThis patch lacks acks from MMC maintainers. Actually, it should just be submitted like any other MMC patches; to Chris Ball and the MMC list.
Quoted 5 lines
Actually this one driver usually goes through Russell's tree. He was OK with Lee pushing it this way, although I don't know if he got a formal ACK?
It doesn't hurt to have Chris' ACK on it too though.
Yeah, I've been pointing MMCI patches towards Russell's patch tracker, but taking everything else through mmc-next. Sorry for having a confusing policy. In this case the patch went into Russell's tracker and then came back out again for ordering reasons.
Since Russell's happy with it:
Thanks,
- Chris.
Signature · 2 lines
Chris Ball <[email protected]> <http://printf.net/> One Laptop Per Child
A message that is not in the archive (sent off-list or not yet received): CAF2Aj3gaFtPs7gLd3snzVr1a8Px5A_RN1vz=M+U_LZ3MBpyqqw@mail.gmail.com
Quoted 3 lines · Lee Jones
I can do that. The reason I was submitting myself was due to the massive amount of ux500 DT patches I was pushing. Now that's stopped, I'm happy for Linus to handle it all.
OK so what about I pull this branch into my ux500 git and call it a devicetree branch, and then we can optionally merge a few of those ARM: ux500: * patches that was sent for the regulator stuff on top of that as well?
Yours,
Linus Walleij
Quoted 10 lines · Linus Walleij
Quoted 3 lines · Lee Jones
I can do that. The reason I was submitting myself was due to the massive amount of ux500 DT patches I was pushing. Now that's stopped, I'm happy for Linus to handle it all.
OK so what about I pull this branch into my ux500 git and call it a devicetree branch, and then we can optionally merge a few of those ARM: ux500: * patches that was sent for the regulator stuff on top of that as well?
There are two reasons why I don't like that idea: 1) As Olof pointed out, a lot of these patches aren't actually DT related, and 2) I really want all of the regulator stuff to stay together. Each of the changes in the platform code are directly dependent on the ones happening in the regulator driver, and visa versa. It would be best if they continued to be taken though Marks tree.
Signature · 4 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 7 lines · Lee Jones
Quoted 5 lines · Linus Walleij
OK so what about I pull this branch into my ux500 git and call it a devicetree branch, and then we can optionally merge a few of those ARM: ux500: * patches that was sent for the regulator stuff on top of that as well?
Quoted 6 lines
There are two reasons why I don't like that idea: 1) As Olof pointed out, a lot of these patches aren't actually DT related, and 2) I really want all of the regulator stuff to stay together. Each of the changes in the platform code are directly dependent on the ones happening in the regulator driver, and visa versa. It would be best if they continued to be taken though Marks tree.
I understand this and I'm fully aligned for the non-DT parts.
But I'm worrying about a plethora or merge conflicts under arch/arm/boot/dts/*
I already pulled some of the pinctrl device tree patches over to my Linux-stericsson tree to avoid clashes between ARM SoC and pinctrl.
Rationale: I don't want arch/arm/boot/dts to become the new boardfile-type merge-clash point. That will just invoke the wrath of the Big Penguin.
Yours,
Linus Walleij
Quoted 15 lines · Linus Walleij
Quoted 7 lines · Lee Jones
Quoted 5 lines · Linus Walleij
OK so what about I pull this branch into my ux500 git and call it a devicetree branch, and then we can optionally merge a few of those ARM: ux500: * patches that was sent for the regulator stuff on top of that as well?
Quoted 6 lines
There are two reasons why I don't like that idea: 1) As Olof pointed out, a lot of these patches aren't actually DT related, and 2) I really want all of the regulator stuff to stay together. Each of the changes in the platform code are directly dependent on the ones happening in the regulator driver, and visa versa. It would be best if they continued to be taken though Marks tree.
Quoted 4 lines
I understand this and I'm fully aligned for the non-DT parts.
But I'm worrying about a plethora or merge conflicts under
arch/arm/boot/dts/*
Oh no, do as you please with these.
Quoted 10 lines
I already pulled some of the pinctrl device tree patches over to my Linux-stericsson tree to avoid clashes between ARM SoC and pinctrl.
Rationale: I don't want
arch/arm/boot/dtsto become the new boardfile-type merge-clash point. That will just invoke the wrath of the Big Penguin.Yours,
Linus Walleij
Signature · 4 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog