[GIT PULL] ux500 DT related fixes and platform enhancements

[GIT PULL] ux500 DT related fixes and platform enhancements

[Olof Johansson]

Hi,

On Wed, Feb 6, 2013 at 5:59 AM, Lee Jones <lee.jones@linaro.org> wrote:

> 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: Move ios_handler functionality 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.

>       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 the ios_handler from 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

[GIT PULL] ux500 DT related fixes and platform enhancements

[Linus Walleij]

On Wed, Feb 6, 2013 at 6:48 PM, Olof Johansson <olof@lixom.net> wrote:

>>       mmc: mmci: Move ios_handler functionality 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.

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

[GIT PULL] ux500 DT related fixes and platform enhancements

[Chris Ball]

Hi,

On Wed, Feb 06 2013, Linus Walleij wrote:
> On Wed, Feb 6, 2013 at 6:48 PM, Olof Johansson <olof@lixom.net> wrote:
>
>>>       mmc: mmci: Move ios_handler functionality 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.
>
> 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:

Acked-by: Chris Ball <cjb@laptop.org>

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

[GIT PULL] ux500 DT related fixes and platform enhancements

[Linus Walleij]

On Thu, Feb 7, 2013 at 10:24 AM, Lee Jones <lee.jones@linaro.org> wrote:

> 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

[GIT PULL] ux500 DT related fixes and platform enhancements

[Lee Jones]

On Thu, 07 Feb 2013, Linus Walleij wrote:

> On Thu, Feb 7, 2013 at 10:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
> 
> > 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.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[GIT PULL] ux500 DT related fixes and platform enhancements

[Linus Walleij]

On Fri, Feb 8, 2013 at 9:31 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 07 Feb 2013, Linus Walleij wrote:
>>
>> 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.

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

[GIT PULL] ux500 DT related fixes and platform enhancements

[Lee Jones]

On Sun, 10 Feb 2013, Linus Walleij wrote:

> On Fri, Feb 8, 2013 at 9:31 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 07 Feb 2013, Linus Walleij wrote:
> >>
> >> 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.
> 
> 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.

> 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

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog