* [GIT PULL] pxa: patches for next merge window
@ 2010-02-25 2:49 Eric Miao
2010-02-25 20:51 ` Russell King - ARM Linux
0 siblings, 1 reply; 20+ messages in thread
From: Eric Miao @ 2010-02-25 2:49 UTC (permalink / raw)
To: linux-arm-kernel
Russell,
Please help pull from below, thanks.
The following changes since commit 724e6d3fe8003c3f60bf404bf22e4e331327c596:
Linus Torvalds (1):
Linux 2.6.33-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git devel
Daniel Mack (3):
[ARM] pxa/raumfeld: add platform support
[ARM] pxa/raumfeld: add defconfig
[ARM] pxa/raumfeld: set GPIO drive bits for LED pins
Edwin Peer (1):
[ARM] pxa: add support for Embedian MXM-8x10
Eric Miao (22):
[ARM] pxa: use chip->ack() instead of accessing GEDR directly
[ARM] pxa: simplify the LCD pin configuration for pxa25x platforms
[ARM] pxa: simplify the LCD pin configuration for pxa27x platforms
[ARM] pxa: remove the unnecessary restoring of MFP registers
[ARM] pxa: introduce processor specific pxa27x_assert_ac97reset()
[ARM] pxa: add the missing AC97 pin configurations
[ARM] pxa: remove now unnecessary pxa_gpio_mode() calls in ac97
[ARM] pxa/cm-x270: avoid direct access of GPIO/MFP registers
[ARM] pxa/tosa: make use of the matrix keypad driver
[ARM] sa1100: remove unreferenced IRQ definitions
[ARM] locomo: avoid unnecessary cascaded keyboard IRQ
[ARM] locomo: remove unused IRQs and avoid unnecessary cascade
[ARM] locomo: allow cascaded IRQ base to be specified by platforms
[ARM] sa1111: avoid using hardcoded IRQ numbers for PCMCIA driver
[ARM] sa1111: allow cascaded IRQs to be used by platforms
[ARM] pxa: move board board IRQ definitions out of irqs.h
[ARM] pxa: introduce PXA_SSP_LEGACY for legacy SSP API
ASoC: Remove legacy SSP API usage from pxa-ssp.c
[ARM] mmp: rename irq.c to irq-pxa168.c to allow other SoC IRQ chips
MAINTAINERS: add maintainers for Marvell MMP2 (aka ARMADA610) support
[ARM] mmp2: fix incorrect calling of chip->mask_ack() for 2nd
level cascaded IRQs
[ARM] pxa: refactor uncompress.h for non-PXA uarts
Haojian Zhuang (11):
[ARM] mmp: avengers lite (pxa168) board bring up
[ARM] mmp: update pxa168_defconfig and include avengers lite support
[ARM] mmp: add support for Marvell MMP2
[ARM] mmp: add default configuration for MMP2
[ARM] mmp: support jasper development board
[ARM] mmp2: add mask function in irq-mmp2.c
[ARM] mmp2: add mfpr setting
[ARM] mmp2: add gpio initialization
[ARM] mmp2: add missing ICU register definitions
[ARM] mmp2: add support for board IRQs
[ARM] mmp2: add handling on PMIC IRQ
Marc Zyngier (5):
[ARM] pxa/zeus: Allow usage of 8250-compatible UART in uncompress
[ARM] pxa/zeus: Correct the USB host initialisation flags
[ARM] pxa/zeus: Add Eurotech as the manufacturer
[ARM] pxa/zeus: Add support for onboard max6369 watchdog
[ARM] pxa/zeus: Add support for mcp2515 CAN bus
Stefan Schmidt (4):
[ARM] pxa: enable check_scoop_reg() only if CONFIG_PM is set.
[ARM] pxa: define zeus_power_off() only when CONFIG_PM enabled
[ARM] pxa/imote2: Add defconfig for the imote2 platform.
[ARM] pxa/imote2: Remove redundant pin entry for nCS.
MAINTAINERS | 7 +
arch/arm/Kconfig | 4 +-
arch/arm/common/locomo.c | 362 +----
arch/arm/common/sa1111.c | 112 ++-
arch/arm/common/scoop.c | 2 +-
arch/arm/configs/imote2_defconfig | 2077 ++++++++++++++++++++++++++
arch/arm/configs/mmp2_defconfig | 1194 +++++++++++++++
arch/arm/configs/pxa168_defconfig | 229 ++-
arch/arm/configs/raumfeld_defconfig | 1898 +++++++++++++++++++++++
arch/arm/include/asm/hardware/it8152.h | 12 +
arch/arm/include/asm/hardware/locomo.h | 4 +
arch/arm/include/asm/hardware/sa1111.h | 4 +
arch/arm/mach-mmp/Kconfig | 35 +-
arch/arm/mach-mmp/Makefile | 10 +-
arch/arm/mach-mmp/avengers_lite.c | 51 +
arch/arm/mach-mmp/common.h | 4 +
arch/arm/mach-mmp/flint.c | 123 ++
arch/arm/mach-mmp/include/mach/cputype.h | 9 +
arch/arm/mach-mmp/include/mach/devices.h | 12 +
arch/arm/mach-mmp/include/mach/entry-macro.S | 7 +-
arch/arm/mach-mmp/include/mach/irqs.h | 115 ++-
arch/arm/mach-mmp/include/mach/mfp-mmp2.h | 240 +++
arch/arm/mach-mmp/include/mach/mfp-pxa168.h | 4 +-
arch/arm/mach-mmp/include/mach/mmp2.h | 60 +
arch/arm/mach-mmp/include/mach/regs-apbc.h | 41 +
arch/arm/mach-mmp/include/mach/regs-icu.h | 42 +-
arch/arm/mach-mmp/include/mach/uncompress.h | 13 +-
arch/arm/mach-mmp/irq-mmp2.c | 154 ++
arch/arm/mach-mmp/{irq.c => irq-pxa168.c} | 0
arch/arm/mach-mmp/jasper.c | 80 +
arch/arm/mach-mmp/mmp2.c | 123 ++
arch/arm/mach-mmp/time.c | 26 +-
arch/arm/mach-pxa/Kconfig | 35 +
arch/arm/mach-pxa/Makefile | 5 +
arch/arm/mach-pxa/balloon3.c | 33 +-
arch/arm/mach-pxa/capc7117.c | 158 ++
arch/arm/mach-pxa/cm-x255.c | 21 +-
arch/arm/mach-pxa/cm-x270.c | 83 +-
arch/arm/mach-pxa/cm-x2xx-pci.c | 2 +-
arch/arm/mach-pxa/e740.c | 6 +
arch/arm/mach-pxa/e750.c | 6 +
arch/arm/mach-pxa/e800.c | 9 +
arch/arm/mach-pxa/em-x270.c | 21 +-
arch/arm/mach-pxa/icontrol.c | 202 +++
arch/arm/mach-pxa/idp.c | 20 +-
arch/arm/mach-pxa/imote2.c | 3 +-
arch/arm/mach-pxa/include/mach/balloon3.h | 10 +
arch/arm/mach-pxa/include/mach/irqs.h | 153 +--
arch/arm/mach-pxa/include/mach/lpd270.h | 4 +
arch/arm/mach-pxa/include/mach/lubbock.h | 11 +
arch/arm/mach-pxa/include/mach/mainstone.h | 17 +
arch/arm/mach-pxa/include/mach/mfp-pxa25x.h | 32 +
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h | 27 +
arch/arm/mach-pxa/include/mach/mxm8x10.h | 21 +
arch/arm/mach-pxa/include/mach/pcm027.h | 7 +
arch/arm/mach-pxa/include/mach/ssp.h | 2 +
arch/arm/mach-pxa/include/mach/uncompress.h | 41 +-
arch/arm/mach-pxa/include/mach/zeus.h | 3 +-
arch/arm/mach-pxa/lpd270.c | 6 +-
arch/arm/mach-pxa/lubbock.c | 35 +-
arch/arm/mach-pxa/magician.c | 21 +-
arch/arm/mach-pxa/mainstone.c | 27 +-
arch/arm/mach-pxa/mioa701.c | 24 +-
arch/arm/mach-pxa/mxm8x10.c | 474 ++++++
arch/arm/mach-pxa/palmld.c | 21 +-
arch/arm/mach-pxa/palmt5.c | 21 +-
arch/arm/mach-pxa/palmtc.c | 21 +-
arch/arm/mach-pxa/palmte2.c | 21 +-
arch/arm/mach-pxa/palmtreo.c | 20 +-
arch/arm/mach-pxa/palmtx.c | 21 +-
arch/arm/mach-pxa/palmz72.c | 22 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 9 +-
arch/arm/mach-pxa/poodle.c | 28 +-
arch/arm/mach-pxa/pxa27x.c | 19 +
arch/arm/mach-pxa/raumfeld.c | 1108 ++++++++++++++
arch/arm/mach-pxa/spitz.c | 20 +-
arch/arm/mach-pxa/ssp.c | 5 +
arch/arm/mach-pxa/tosa.c | 117 ++-
arch/arm/mach-pxa/trizeps4.c | 27 +-
arch/arm/mach-pxa/viper.c | 8 +-
arch/arm/mach-pxa/zeus.c | 91 +-
arch/arm/mach-sa1100/badge4.c | 5 +
arch/arm/mach-sa1100/collie.c | 4 +
arch/arm/mach-sa1100/include/mach/collie.h | 7 -
arch/arm/mach-sa1100/include/mach/irqs.h | 91 +--
arch/arm/mach-sa1100/jornada720.c | 5 +
arch/arm/mach-sa1100/neponset.c | 5 +
drivers/input/keyboard/locomokbd.c | 32 +-
drivers/pcmcia/sa1111_generic.c | 25 +-
drivers/usb/gadget/pxa25x_udc.c | 4 +
sound/arm/pxa2xx-ac97-lib.c | 68 +-
sound/soc/pxa/pxa-ssp.c | 90 +-
92 files changed, 9256 insertions(+), 1232 deletions(-)
create mode 100644 arch/arm/configs/imote2_defconfig
create mode 100644 arch/arm/configs/mmp2_defconfig
create mode 100644 arch/arm/configs/raumfeld_defconfig
create mode 100644 arch/arm/mach-mmp/avengers_lite.c
create mode 100644 arch/arm/mach-mmp/flint.c
create mode 100644 arch/arm/mach-mmp/include/mach/mfp-mmp2.h
create mode 100644 arch/arm/mach-mmp/include/mach/mmp2.h
create mode 100644 arch/arm/mach-mmp/irq-mmp2.c
rename arch/arm/mach-mmp/{irq.c => irq-pxa168.c} (100%)
create mode 100644 arch/arm/mach-mmp/jasper.c
create mode 100644 arch/arm/mach-mmp/mmp2.c
create mode 100644 arch/arm/mach-pxa/capc7117.c
create mode 100644 arch/arm/mach-pxa/icontrol.c
create mode 100644 arch/arm/mach-pxa/include/mach/mxm8x10.h
create mode 100644 arch/arm/mach-pxa/mxm8x10.c
create mode 100644 arch/arm/mach-pxa/raumfeld.c
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-25 2:49 [GIT PULL] pxa: patches for next merge window Eric Miao
@ 2010-02-25 20:51 ` Russell King - ARM Linux
2010-02-25 21:29 ` Russell King - ARM Linux
0 siblings, 1 reply; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-02-25 20:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2010 at 10:49:03AM +0800, Eric Miao wrote:
> Russell,
>
> Please help pull from below, thanks.
>
> The following changes since commit 724e6d3fe8003c3f60bf404bf22e4e331327c596:
> Linus Torvalds (1):
> Linux 2.6.33-rc8
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git devel
Err, you've rebased your tree since I last pulled it, and this now results
in the following, and a load of duplicated commits between the two trees.
This is not nice, please don't rebase stuff which I've already pulled.
I'm going to think about what to do about this; I can't trivially drop
your previous work from my tree.
diff --cc arch/arm/mach-pxa/raumfeld.c
index 06717d7,3184bdc..0000000
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@@ -231,6 -231,10 +231,13 @@@ static mfp_cfg_t raumfeld_connector_pin
GPIO26_SSP2_FRM,
GPIO27_SSP2_TXD,
GPIO29_SSP2_EXTCLK,
++<<<<<<< HEAD:arch/arm/mach-pxa/raumfeld.c
++=======
+
+ /* LEDs */
+ GPIO35_GPIO | MFP_LPM_PULL_LOW,
+ GPIO36_GPIO | MFP_LPM_DRIVE_HIGH,
++>>>>>>> aa4efff73f7ccf59efbc1fc98c31b43b70dc3731:arch/arm/mach-pxa/raumfeld.c
};
static mfp_cfg_t raumfeld_speaker_pin_config[] __initdata = {
@@@ -277,6 -281,10 +284,13 @@@
GPIO87_SSP1_TXD,
GPIO88_SSP1_RXD,
GPIO90_SSP1_SYSCLK,
++<<<<<<< HEAD:arch/arm/mach-pxa/raumfeld.c
++=======
+
+ /* LEDs */
+ GPIO35_GPIO | MFP_LPM_PULL_LOW,
+ GPIO36_GPIO | MFP_LPM_DRIVE_HIGH,
++>>>>>>> aa4efff73f7ccf59efbc1fc98c31b43b70dc3731:arch/arm/mach-pxa/raumfeld.c
};
/*
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-25 20:51 ` Russell King - ARM Linux
@ 2010-02-25 21:29 ` Russell King - ARM Linux
2010-02-26 2:50 ` Eric Miao
2010-02-26 9:05 ` Eric Miao
0 siblings, 2 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-02-25 21:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 25, 2010 at 08:51:13PM +0000, Russell King - ARM Linux wrote:
> Err, you've rebased your tree since I last pulled it, and this now results
> in the following, and a load of duplicated commits between the two trees.
>
> This is not nice, please don't rebase stuff which I've already pulled.
>
> I'm going to think about what to do about this; I can't trivially drop
> your previous work from my tree.
What happened to this commit?
[ARM] pxa/ttc_dkb: remove duplicate macro definition
which follows:
[ARM] pxa/raumfeld: add defconfig
[ARM] pxa/raumfeld: add platform support
in your previous pull request? I can find these two in your latest with
different commit IDs, but not the pxa/ttc_dkb patch.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-25 21:29 ` Russell King - ARM Linux
@ 2010-02-26 2:50 ` Eric Miao
2010-02-26 9:05 ` Eric Miao
1 sibling, 0 replies; 20+ messages in thread
From: Eric Miao @ 2010-02-26 2:50 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 26, 2010 at 5:29 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 25, 2010 at 08:51:13PM +0000, Russell King - ARM Linux wrote:
>> Err, you've rebased your tree since I last pulled it, and this now results
>> in the following, and a load of duplicated commits between the two trees.
>>
>> This is not nice, please don't rebase stuff which I've already pulled.
>>
>> I'm going to think about what to do about this; I can't trivially drop
>> your previous work from my tree.
>
> What happened to this commit?
>
> [ARM] pxa/ttc_dkb: remove duplicate macro definition
>
> which follows:
>
> [ARM] pxa/raumfeld: add defconfig
> [ARM] pxa/raumfeld: add platform support
>
> in your previous pull request? ?I can find these two in your latest with
> different commit IDs, but not the pxa/ttc_dkb patch.
>
Ouch, I'll get this sorted out and send the pull request again. Sorry it
took you time to find the mess out ;-)
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-25 21:29 ` Russell King - ARM Linux
2010-02-26 2:50 ` Eric Miao
@ 2010-02-26 9:05 ` Eric Miao
2010-02-28 16:14 ` Russell King - ARM Linux
1 sibling, 1 reply; 20+ messages in thread
From: Eric Miao @ 2010-02-26 9:05 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 26, 2010 at 5:29 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 25, 2010 at 08:51:13PM +0000, Russell King - ARM Linux wrote:
>> Err, you've rebased your tree since I last pulled it, and this now results
>> in the following, and a load of duplicated commits between the two trees.
>>
>> This is not nice, please don't rebase stuff which I've already pulled.
>>
>> I'm going to think about what to do about this; I can't trivially drop
>> your previous work from my tree.
>
> What happened to this commit?
>
> [ARM] pxa/ttc_dkb: remove duplicate macro definition
>
Hi Russell,
This one actually has been merged into 'fix' and been there in -rc8
already. Now we have to live with this duplicate commit, it's my fault.
> which follows:
>
> [ARM] pxa/raumfeld: add defconfig
> [ARM] pxa/raumfeld: add platform support
>
> in your previous pull request? ?I can find these two in your latest with
> different commit IDs, but not the pxa/ttc_dkb patch.
>
I've sorted this out by merging your devel branch back, and rebased
the remaining patches on top of it. Please try re-pull. A rough test
here at my side shows a clean merge so far.
Thanks
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-26 9:05 ` Eric Miao
@ 2010-02-28 16:14 ` Russell King - ARM Linux
2010-03-01 0:42 ` Nicolas Pitre
2010-03-01 9:39 ` Uwe Kleine-König
0 siblings, 2 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-02-28 16:14 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 26, 2010 at 05:05:01PM +0800, Eric Miao wrote:
> Hi Russell,
>
> This one actually has been merged into 'fix' and been there in -rc8
> already. Now we have to live with this duplicate commit, it's my fault.
>
> > which follows:
> >
> > [ARM] pxa/raumfeld: add defconfig
> > [ARM] pxa/raumfeld: add platform support
> >
> > in your previous pull request? ?I can find these two in your latest with
> > different commit IDs, but not the pxa/ttc_dkb patch.
> >
>
> I've sorted this out by merging your devel branch back, and rebased
> the remaining patches on top of it. Please try re-pull. A rough test
> here at my side shows a clean merge so far.
That isn't a fix - merging my devel branch just causes more problems
because it regularly gets rebuilt.
The 'devel' branch contains individual patches, and is regularly re-
generated from individual sub-branches.
The 'devel-stable' branch (internal) contains work pulled from other
people, and the 'stable' bit means that I once pulled, I don't wind
the tree back at any point. This gets merged into 'devel' as the last
merge.
Your original set of commits were merged into 'devel-stable' and has
had other trees merged on top of those.
You've destroyed your original commits, so this calls into question my
entire 'devel-stable' branch.
I've still not decided what to do about this. I'll ask Linus to merge
most of the 'devel' stuff without 'devel-stable' merged into mainline
to move stuff forward - this means _no_ _one's_ git work will be merged
through my tree, at least initially.
However, I'm putting 'devel-stable' on hold; I'll let the other ARM git
maintainers discuss this and work out what they're going to do about
this mess. One solution is to destroy the 'devel-stable' branch in
its entirety, and get everyone to resend all their pull requests.
That's *not* nice.
I also won't be pulling any more git trees until this issue is resolved -
it would be stupid to pull more git trees on top of 'devel-stable' at
this point.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-28 16:14 ` Russell King - ARM Linux
@ 2010-03-01 0:42 ` Nicolas Pitre
2010-03-01 13:23 ` Eric Miao
2010-03-01 9:39 ` Uwe Kleine-König
1 sibling, 1 reply; 20+ messages in thread
From: Nicolas Pitre @ 2010-03-01 0:42 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, 28 Feb 2010, Russell King - ARM Linux wrote:
> You've destroyed your original commits, so this calls into question my
> entire 'devel-stable' branch.
>
> I've still not decided what to do about this. I'll ask Linus to merge
> most of the 'devel' stuff without 'devel-stable' merged into mainline
> to move stuff forward - this means _no_ _one's_ git work will be merged
> through my tree, at least initially.
>
> However, I'm putting 'devel-stable' on hold; I'll let the other ARM git
> maintainers discuss this and work out what they're going to do about
> this mess. One solution is to destroy the 'devel-stable' branch in
> its entirety, and get everyone to resend all their pull requests.
> That's *not* nice.
What about simply ignoring Eric's latest pull request and have your
'devel-stable' be merged by Linus as is? Surely the earlier branch you
merged from Eric wasn't that bad anyway, and Eric can certainly provide
new commits on top later on to fix possible issues with that in order to
bring his stuff to the same state as what he just asked you to pull.
Nicolas
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-02-28 16:14 ` Russell King - ARM Linux
2010-03-01 0:42 ` Nicolas Pitre
@ 2010-03-01 9:39 ` Uwe Kleine-König
2010-03-01 9:48 ` Russell King - ARM Linux
1 sibling, 1 reply; 20+ messages in thread
From: Uwe Kleine-König @ 2010-03-01 9:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello Russell,
> > This one actually has been merged into 'fix' and been there in -rc8
> > already. Now we have to live with this duplicate commit, it's my fault.
> >
> > > which follows:
> > >
> > > [ARM] pxa/raumfeld: add defconfig
> > > [ARM] pxa/raumfeld: add platform support
> > >
> > > in your previous pull request? ?I can find these two in your latest with
> > > different commit IDs, but not the pxa/ttc_dkb patch.
> > >
> >
> > I've sorted this out by merging your devel branch back, and rebased
> > the remaining patches on top of it. Please try re-pull. A rough test
> > here at my side shows a clean merge so far.
>
> That isn't a fix - merging my devel branch just causes more problems
> because it regularly gets rebuilt.
>
> The 'devel' branch contains individual patches, and is regularly re-
> generated from individual sub-branches.
>
> The 'devel-stable' branch (internal) contains work pulled from other
> people, and the 'stable' bit means that I once pulled, I don't wind
> the tree back at any point. This gets merged into 'devel' as the last
> merge.
>
> Your original set of commits were merged into 'devel-stable' and has
> had other trees merged on top of those.
>
> You've destroyed your original commits, so this calls into question my
> entire 'devel-stable' branch.
>
> I've still not decided what to do about this. I'll ask Linus to merge
> most of the 'devel' stuff without 'devel-stable' merged into mainline
> to move stuff forward - this means _no_ _one's_ git work will be merged
> through my tree, at least initially.
>
> However, I'm putting 'devel-stable' on hold; I'll let the other ARM git
> maintainers discuss this and work out what they're going to do about
> this mess. One solution is to destroy the 'devel-stable' branch in
> its entirety, and get everyone to resend all their pull requests.
> That's *not* nice.
>
> I also won't be pulling any more git trees until this issue is resolved -
> it would be stupid to pull more git trees on top of 'devel-stable' at
> this point.
In my eyes there are three different possibilities for the future:
a) every tree requested for pulling has to keep constant.
b) rmk treats the submaintainer trees as his topic branches that are
regularly merged into devel.
c) Linus pulls directly from submaintainers.
I think c) isn't nice (and AFAIK Linus would request a)).
I'd prefer a). And if a submaintainer "doesn't behave" next time either
both trees are pulled making the arm tree as ugly as are the others
sometimes or the second pull request is declined if Russell notes it
early enough (maybe supported by some script work).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 9:39 ` Uwe Kleine-König
@ 2010-03-01 9:48 ` Russell King - ARM Linux
2010-03-01 10:11 ` Paul Mundt
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-03-01 9:48 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 01, 2010 at 10:39:27AM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
(in reply to Eric)
> > The 'devel' branch contains individual patches, and is regularly re-
> > generated from individual sub-branches.
> >
> > The 'devel-stable' branch (internal) contains work pulled from other
> > people, and the 'stable' bit means that I once pulled, I don't wind
> > the tree back at any point. This gets merged into 'devel' as the last
> > merge.
> >
> > Your original set of commits were merged into 'devel-stable' and has
> > had other trees merged on top of those.
> >
> > You've destroyed your original commits, so this calls into question my
> > entire 'devel-stable' branch.
> >
> > I've still not decided what to do about this. I'll ask Linus to merge
> > most of the 'devel' stuff without 'devel-stable' merged into mainline
> > to move stuff forward - this means _no_ _one's_ git work will be merged
> > through my tree, at least initially.
> >
> > However, I'm putting 'devel-stable' on hold; I'll let the other ARM git
> > maintainers discuss this and work out what they're going to do about
> > this mess. One solution is to destroy the 'devel-stable' branch in
> > its entirety, and get everyone to resend all their pull requests.
> > That's *not* nice.
> >
> > I also won't be pulling any more git trees until this issue is resolved -
> > it would be stupid to pull more git trees on top of 'devel-stable' at
> > this point.
>
> In my eyes there are three different possibilities for the future:
>
> a) every tree requested for pulling has to keep constant.
> b) rmk treats the submaintainer trees as his topic branches that are
> regularly merged into devel.
> c) Linus pulls directly from submaintainers.
>
> I think c) isn't nice (and AFAIK Linus would request a)).
>
> I'd prefer a). And if a submaintainer "doesn't behave" next time either
> both trees are pulled making the arm tree as ugly as are the others
> sometimes or the second pull request is declined if Russell notes it
> early enough (maybe supported by some script work).
I've added Linus to this, so he's aware of what's going on, since if
I do merge Eric's latest tree, Linus will see duplicate commits from
me and I don't wish to have one of Linus' responses to that. ;)
The general rule is that once you've asked someone to pull your tree,
that's it, the commits are cast in stone. It doesn't matter who you
ask to pull your tree.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 9:48 ` Russell King - ARM Linux
@ 2010-03-01 10:11 ` Paul Mundt
2010-03-01 10:27 ` Uwe Kleine-König
2010-03-01 10:12 ` Uwe Kleine-König
2010-03-01 16:40 ` Linus Torvalds
2 siblings, 1 reply; 20+ messages in thread
From: Paul Mundt @ 2010-03-01 10:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 01, 2010 at 09:48:21AM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 01, 2010 at 10:39:27AM +0100, Uwe Kleine-K?nig wrote:
> > In my eyes there are three different possibilities for the future:
> >
> > a) every tree requested for pulling has to keep constant.
> > b) rmk treats the submaintainer trees as his topic branches that are
> > regularly merged into devel.
> > c) Linus pulls directly from submaintainers.
> >
> > I think c) isn't nice (and AFAIK Linus would request a)).
> >
> > I'd prefer a). And if a submaintainer "doesn't behave" next time either
> > both trees are pulled making the arm tree as ugly as are the others
> > sometimes or the second pull request is declined if Russell notes it
> > early enough (maybe supported by some script work).
>
> I've added Linus to this, so he's aware of what's going on, since if
> I do merge Eric's latest tree, Linus will see duplicate commits from
> me and I don't wish to have one of Linus' responses to that. ;)
>
> The general rule is that once you've asked someone to pull your tree,
> that's it, the commits are cast in stone. It doesn't matter who you
> ask to pull your tree.
Out of the non-PXA merge requests, the only conflicts seem to be on
Kconfig/Makefile bits as usual, being fairly insular beyond that. While
these are fairly easy to sort out, it's a bit impolite to jump to c) as
long as other changes in the same area are already present in the ARM
tree. I intentionally did not send my pull request to Linus initially
because I didn't want to create extra work for others merging out of
order and triggering conflicts on the same files. (Although in -next at
the moment I believe it's only 3 trees that are in conflict with regards
to arch/arm/{Kconfig,Makefile}).
c) works so long as there is no overlap between trees and people
generally behave responsibly. Some of the ARM trees already do this
today, where areas of overlap are handled through the ARM tree while
isolated changes are often just pulled directly. As long as people can
determine when to use which strategy then this model works fairly well.
Some merge conflicts will occur regardless, though.
Having said that, many of the ARM architecture git trees are pulled in to
-next directly with merge resolution handled there, some of which will be
merged in to the main ARM tree and others which will not. Anything
showing up in -next should have already been reviewed and aimed at
heading in to Linus's tree directly, so having an extra layer where
everything has to be integrated before being sent out just seems like
extra work. Someone is going to have to do the merge resolution
regardless, the issue is just trying to make sure that the more serious
ones are resolved in the ARM tree.
One way around this would be to have people pull before doing a merge
request, but that also means that you're then sending out a merge request
for something that hasn't seen the testing that the original one did, and
may suddenly have bugs introduced by upstream changes. This isn't an
ideal solution either.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 9:48 ` Russell King - ARM Linux
2010-03-01 10:11 ` Paul Mundt
@ 2010-03-01 10:12 ` Uwe Kleine-König
2010-03-01 16:40 ` Linus Torvalds
2 siblings, 0 replies; 20+ messages in thread
From: Uwe Kleine-König @ 2010-03-01 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
> > I'd prefer a). And if a submaintainer "doesn't behave" next time either
> > both trees are pulled making the arm tree as ugly as are the others
> > sometimes or the second pull request is declined if Russell notes it
> > early enough (maybe supported by some script work).
~/gsrc/linux-2.6$ git rev-parse linus/master
30ff056c42c665b9ea535d8515890857ae382540
~/gsrc/linux-2.6$ git rev-list v2.6.31..linus/master | while read rev; do git show $rev | git patch-id; done | sort > dup
~/gsrc/linux-2.6$ uniq -w 40 -d dup | wc -l
126
(Assuming that did what I intended (and different patches don't share
patch ids) this means there are 126 patches between v2.6.31 and today
that exist twice (or more) in Linus' tree.)
I havn't checked any of them but seeing this I don't consider Eric's two
duplicated commits to be that important.
Still it would be nice to pay attention not to introduce them in the
future of course.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 10:11 ` Paul Mundt
@ 2010-03-01 10:27 ` Uwe Kleine-König
2010-03-02 0:33 ` Stephen Rothwell
0 siblings, 1 reply; 20+ messages in thread
From: Uwe Kleine-König @ 2010-03-01 10:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
> Out of the non-PXA merge requests, the only conflicts seem to be on
> Kconfig/Makefile bits as usual, being fairly insular beyond that. While
> these are fairly easy to sort out,
Only a nice hint to whoever will merge the different arm trees in the
end: Note that next is (or recently was) broken, because git merged two
arm trees successfully (i.e. didn't result in a conflict) according to
Stephen and broke arch/arm/Kconfig with it. See
http://thread.gmane.org/gmane.linux.ports.arm.kernel/75250
for the exact details.
(I don't know if Stephen reports these issues to Linus anyhow, so this
mail might have been sent for nothing.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 0:42 ` Nicolas Pitre
@ 2010-03-01 13:23 ` Eric Miao
2010-03-01 15:16 ` Russell King - ARM Linux
0 siblings, 1 reply; 20+ messages in thread
From: Eric Miao @ 2010-03-01 13:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 1, 2010 at 8:42 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 28 Feb 2010, Russell King - ARM Linux wrote:
>
>> You've destroyed your original commits, so this calls into question my
>> entire 'devel-stable' branch.
>>
>> I've still not decided what to do about this. ?I'll ask Linus to merge
>> most of the 'devel' stuff without 'devel-stable' merged into mainline
>> to move stuff forward - this means _no_ _one's_ git work will be merged
>> through my tree, at least initially.
>>
>> However, I'm putting 'devel-stable' on hold; I'll let the other ARM git
>> maintainers discuss this and work out what they're going to do about
>> this mess. ?One solution is to destroy the 'devel-stable' branch in
>> its entirety, and get everyone to resend all their pull requests.
>> That's *not* nice.
>
> What about simply ignoring Eric's latest pull request and have your
> 'devel-stable' be merged by Linus as is? ?Surely the earlier branch you
> merged from Eric wasn't that bad anyway, and Eric can certainly provide
> new commits on top later on to fix possible issues with that in order to
> bring his stuff to the same state as what he just asked you to pull.
>
Russell,
Regarding the problem of my rebased three commits that were already
merged into your tree, I'm seeing three ways out:
1. merge back your devel branch (tried and as you suggested is not a
very clean way)
2. merge linus v2.6.33-rc? and get the other commits rebased
3. rebase all the other commits against your devel branch or (devel-stable)
Just lemme know which is the best approach.
BTW, it would be very helpful to us if we are able to understand the
difference and how you maintain 'devel' and 'devel-stable' branch?
- eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 13:23 ` Eric Miao
@ 2010-03-01 15:16 ` Russell King - ARM Linux
2010-03-02 4:48 ` Eric Miao
0 siblings, 1 reply; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-03-01 15:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 01, 2010 at 09:23:37PM +0800, Eric Miao wrote:
> Russell,
>
> Regarding the problem of my rebased three commits that were already
> merged into your tree, I'm seeing three ways out:
>
> 1. merge back your devel branch (tried and as you suggested is not a
> very clean way)
>
> 2. merge linus v2.6.33-rc? and get the other commits rebased
>
> 3. rebase all the other commits against your devel branch or (devel-stable)
>
> Just lemme know which is the best approach.
>
> BTW, it would be very helpful to us if we are able to understand the
> difference and how you maintain 'devel' and 'devel-stable' branch?
The devel branch is unstable - it's a combination of topic branches,
and these topic branches are regularly re-merged to produce a single
head for Stephen Rothwell to pull into -next. The other reason for
publishing it is to give Nicolas (and others) something to look at so
they know what's going on in my tree.
It also occasionally receives truely unstable patches for testing
purposes, which very well could be dropped - eg, if they cause build
errors. (Remember - I have no practical way to test patches which
affect many ARM platforms, except by getting linux-next to pick them
up.)
What this means is that the commit IDs of the merges and occasionally
patches will change, and as such, basing anything on top of it is a
recipe for disaster.
In theory, the devel-stable branch receives merges of external trees,
occasionally receives local merges from stable topic branches, but is
never rebased and no commits are ever undone on it.
So, basing patches on top of devel-stable should be safe.
If you can arrange for your tree to be rebased upon devel-stable, that
should solve the problem, and avoid any need to mess around with what's
already committed there.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 9:48 ` Russell King - ARM Linux
2010-03-01 10:11 ` Paul Mundt
2010-03-01 10:12 ` Uwe Kleine-König
@ 2010-03-01 16:40 ` Linus Torvalds
2010-03-01 16:58 ` Linus Torvalds
2 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2010-03-01 16:40 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 1 Mar 2010, Russell King - ARM Linux wrote:
> On Mon, Mar 01, 2010 at 10:39:27AM +0100, Uwe Kleine-K?nig wrote:
> >
> > In my eyes there are three different possibilities for the future:
> >
> > a) every tree requested for pulling has to keep constant.
> > b) rmk treats the submaintainer trees as his topic branches that are
> > regularly merged into devel.
> > c) Linus pulls directly from submaintainers.
> >
> > I think c) isn't nice (and AFAIK Linus would request a)).
> >
> > I'd prefer a). And if a submaintainer "doesn't behave" next time either
> > both trees are pulled making the arm tree as ugly as are the others
> > sometimes or the second pull request is declined if Russell notes it
> > early enough (maybe supported by some script work).
>
> I've added Linus to this, so he's aware of what's going on, since if
> I do merge Eric's latest tree, Linus will see duplicate commits from
> me and I don't wish to have one of Linus' responses to that. ;)
>
> The general rule is that once you've asked someone to pull your tree,
> that's it, the commits are cast in stone. It doesn't matter who you
> ask to pull your tree.
Yes. I think (a) is the right thing to do, ie if rmk is pulling from
others, then those others must always follow the same rules that _I_
require people I pull from to follow.
Quite frankly, (b) is going to be a total mess. It's been done. The
resulting 'devel' branch will end up looking like 'next', and while
there's no question that 'next' isn't very useful, it's also almost
totally impossible to look through the history of it when things go wrong
(git has 'rerere' to remember previous merge resolutions so that they
don't have to be re-done over and over again, but that's about the only
kind of "history of history" that git helps with).
And while (c) is something I do, it's something I want to do
_occasionally_ rather than all the time. IOW, I'll happily take direct
pulls from submaintainers, but I'd rather have a good reason for it (ie
maintainer is temporarily busy with something else, or it's an urgent fix
late in the -rc series that somebody just wants to happen asap etc).
So I'd much prefer (a). And that does mean that submaintainers have to be
more on-the-ball.
IOW, if a submaintainer ask somebody else to pull from them, that tree is
now public, and cannot then be rebased or do other history-destroying
things.
This obviously does require that submaintainers be more careful, but
that's a _good_ thing. They need to think twice before asking their
higher-up maintainer to pull their stuff, because once it's pulled, it's
set in stone.
rmk: I think it's ok if you end up having to rebase something this time in
order to fix up a mistake that has already happened - no rule should be
_so_ set in stone that it can't be violated when bad things happen.
But you could be hard-nosed and push the pain downward (that's what I tend
to try to do), ie do something like force your submaintainers to go back
to the old state that you already pulled from, and then rebase their
subsequent changes on top of that.
The reason _I_ tend to push the pain back down is (a) I'm lazy, and I damn
well like it that way and (b) I also happen to think that it's
fundamentally much better to "spread out" the pain as widely as possible
than have it concentrate at some maintainer level.
So not only for me personally, but in general, I think it's better if we
strive to push the burden of maintenance as far out as possible. That way
the development model scales, rather than become too tied up with
particular maintainers having to be really really on top of everything.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 16:40 ` Linus Torvalds
@ 2010-03-01 16:58 ` Linus Torvalds
2010-03-01 17:07 ` Russell King - ARM Linux
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2010-03-01 16:58 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 1 Mar 2010, Linus Torvalds wrote:
>
> rmk: I think it's ok if you end up having to rebase something this time in
> order to fix up a mistake that has already happened - no rule should be
> _so_ set in stone that it can't be violated when bad things happen.
Btw, since I have a pending pull from you already, let me know if I should
pull it or not. I was just about to pull it, and then I started wondering
whether the pax patches are involved, so I kept off.
But if you're just going to ask the pxa people to fix things up (which is
my preference), just send me an email saying "go ahead and pull". I'm
checking, just in case.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 16:58 ` Linus Torvalds
@ 2010-03-01 17:07 ` Russell King - ARM Linux
0 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2010-03-01 17:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 01, 2010 at 08:58:12AM -0800, Linus Torvalds wrote:
> On Mon, 1 Mar 2010, Linus Torvalds wrote:
> >
> > rmk: I think it's ok if you end up having to rebase something this time in
> > order to fix up a mistake that has already happened - no rule should be
> > _so_ set in stone that it can't be violated when bad things happen.
>
> Btw, since I have a pending pull from you already, let me know if I should
> pull it or not. I was just about to pull it, and then I started wondering
> whether the pax patches are involved, so I kept off.
That pull request contains just local commits, so it's safe to be pulled
in respect of this issue. The only concern raised on it is from Geert
Uytterhoeven over a bit of missing documentation - basically:
5) void update_mmu_cache(struct vm_area_struct *vma,
- unsigned long address, pte_t pte)
+ unsigned long address, pte_t *ptep)
At the end of every page fault, this routine is invoked to
tell the architecture specific code that a translation
- described by "pte" now exists at virtual address "address"
- for address space "vma->vm_mm", in the software page tables.
+ now exists at virtual address "address" for address space
+ "vma->vm_mm", in the software page tables.
the complaint is that 'ptep' is not documented. "ptep is a pointer to
the pte" wouldn't (at least to me) provide any additional information
to the reader.
> But if you're just going to ask the pxa people to fix things up (which is
> my preference), just send me an email saying "go ahead and pull". I'm
> checking, just in case.
I hope that the PXA situation does get straightened out soon, at which
point this will be part of a pull request next week.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 10:27 ` Uwe Kleine-König
@ 2010-03-02 0:33 ` Stephen Rothwell
0 siblings, 0 replies; 20+ messages in thread
From: Stephen Rothwell @ 2010-03-02 0:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi Uwe,
On Mon, 1 Mar 2010 11:27:27 +0100 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
>
> > Out of the non-PXA merge requests, the only conflicts seem to be on
> > Kconfig/Makefile bits as usual, being fairly insular beyond that. While
> > these are fairly easy to sort out,
> Only a nice hint to whoever will merge the different arm trees in the
> end: Note that next is (or recently was) broken, because git merged two
> arm trees successfully (i.e. didn't result in a conflict) according to
> Stephen and broke arch/arm/Kconfig with it. See
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/75250
>
> for the exact details.
>
> (I don't know if Stephen reports these issues to Linus anyhow, so this
> mail might have been sent for nothing.)
Thanks for that, I had not pointed that one out to Linus, yet.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100302/82ccbada/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
2010-03-01 15:16 ` Russell King - ARM Linux
@ 2010-03-02 4:48 ` Eric Miao
0 siblings, 0 replies; 20+ messages in thread
From: Eric Miao @ 2010-03-02 4:48 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 1, 2010 at 11:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Mar 01, 2010 at 09:23:37PM +0800, Eric Miao wrote:
>> Russell,
>>
>> Regarding the problem of my rebased three commits that were already
>> merged into your tree, I'm seeing three ways out:
>>
>> 1. merge back your devel branch (tried and as you suggested is not a
>> very clean way)
>>
>> 2. merge linus v2.6.33-rc? and get the other commits rebased
>>
>> 3. rebase all the other commits against your devel branch or (devel-stable)
>>
>> Just lemme know which is the best approach.
>>
>> BTW, it would be very helpful to us if we are able to understand the
>> difference and how you maintain 'devel' and 'devel-stable' branch?
>
> The devel branch is unstable - it's a combination of topic branches,
> and these topic branches are regularly re-merged to produce a single
> head for Stephen Rothwell to pull into -next. ?The other reason for
> publishing it is to give Nicolas (and others) something to look at so
> they know what's going on in my tree.
>
> It also occasionally receives truely unstable patches for testing
> purposes, which very well could be dropped - eg, if they cause build
> errors. ?(Remember - I have no practical way to test patches which
> affect many ARM platforms, except by getting linux-next to pick them
> up.)
>
> What this means is that the commit IDs of the merges and occasionally
> patches will change, and as such, basing anything on top of it is a
> recipe for disaster.
>
> In theory, the devel-stable branch receives merges of external trees,
> occasionally receives local merges from stable topic branches, but is
> never rebased and no commits are ever undone on it.
>
> So, basing patches on top of devel-stable should be safe.
>
> If you can arrange for your tree to be rebased upon devel-stable, that
> should solve the problem, and avoid any need to mess around with what's
> already committed there.
>
OK, rebased and pushed. Let me know if there are any remaining issues
during re-pull as I don't want block others from being pulled, feeling
guilty... ;-P
- eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] pxa: patches for next merge window
@ 2010-12-22 9:09 Eric Miao
0 siblings, 0 replies; 20+ messages in thread
From: Eric Miao @ 2010-12-22 9:09 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit b0c3844d8af6b9f3f18f31e1b0502fbefa2166be:
Linux 2.6.37-rc6 (2010-12-15 17:24:48 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git devel
Bjorn Forsman (1):
ARM: pxa/colibri: setup pins for USB host port 3
Daniel Mack (2):
video: add driver for PXA3xx 2D graphics accelerator
ARM: pxa/raumfeld: enable PXA3XX_GCU driver
Eric Miao (9):
ARM: pxa: remove un-used mapping of camera registers
ARM: pxa: introduce addr-map.h for large bus addresses and ranges
ARM: pxa: replace duplicated macro DEFINE_PXA3_CK() with DEFINE_CK()
ARM: pxa: separate the clock support into clock-{pxa2xx,pxa3xx}.c
ARM: pxa: remove get_memclk_frequency_10khz()
ARM: pxa: introduce pxa2xx_clock_sysclass for clock suspend/resume
ARM: pxa: introduce pxa3xx_clock_sysclass for clock suspend/resume
ARM: pxa: add clock for static memory controller
ARM: mmp: correct the naming of GPIOxx_GPIO definitions
Haojian Zhuang (9):
ARM: mmp: append brownstone support
ARM: mmp: fix the typo - MMP2 is compatible with ARMv7
ARM: pxa: redefine the cpu_is_pxa3xx
ARM: pxa: redefine irqs.h
ARM: pxa: support pxa95x
ARM: pxa: support saarb platform
ARM: mmp: select CPU_PJ4
ARM: pxa: sanitize IRQ registers access based on offset
ARM: pxa: add iwmmx support for PJ4
Marek Vasut (13):
ARM: pxa: Introduce pxa{25x,27x,3xx}_map_io()
ARM: pxa: Access SMEMC via virtual addresses
ARM: pxa: Add pxa320 PCMCIA check
ARM: pxa: Toradex Colibri PXA270 CF support
ARM: pxa: Push Colibri evalboard MFP into module files
ARM: pxa: Add M41T00 RTC support into Colibri evalboard
ARM: pxa: Rename Colibri evalboard
ARM: pxa: Colibri PXA320 PCMCIA driver
ARM: pxa: Modularize Palm Tungsten|C
ARM: pxa: Add gpio-leds and vibrator support to PalmTC
ARM: pxa: Fix number of IRQs on Balloon3
ARM: pxa: Update Balloon3 for new FPGA firmware
ARM: pxa: Add Balloon3 NAND ready check
Mark F. Brown (1):
ARM: mmp: refactored 5V regulator support using fixed-regulator
Zhangfei Gao (2):
ARM: mmp: add mmc resource
ARM: mmp: add sd card to jasper
cxie4 (1):
ARM: mmp: add usb clock for pxa168/pxa910
arch/arm/Kconfig | 4 +-
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/iwmmxt.S | 55 ++-
arch/arm/kernel/pj4-cp0.c | 94 +++
arch/arm/mach-mmp/Kconfig | 22 +-
arch/arm/mach-mmp/Makefile | 1 +
arch/arm/mach-mmp/brownstone.c | 204 ++++++
arch/arm/mach-mmp/flint.c | 2 +-
arch/arm/mach-mmp/include/mach/mfp-mmp2.h | 338 +++++-----
arch/arm/mach-mmp/include/mach/mmp2.h | 22 +
arch/arm/mach-mmp/include/mach/regs-apmu.h | 2 +
arch/arm/mach-mmp/jasper.c | 35 +
arch/arm/mach-mmp/mmp2.c | 35 +
arch/arm/mach-mmp/pxa910.c | 2 +
arch/arm/mach-pxa/Kconfig | 24 +-
arch/arm/mach-pxa/Makefile | 10 +-
arch/arm/mach-pxa/balloon3.c | 59 +-
arch/arm/mach-pxa/capc7117.c | 2 +-
arch/arm/mach-pxa/clock-pxa2xx.c | 64 ++
arch/arm/mach-pxa/clock-pxa3xx.c | 218 ++++++
arch/arm/mach-pxa/clock.c | 26 +-
arch/arm/mach-pxa/clock.h | 47 +-
arch/arm/mach-pxa/cm-x2xx.c | 26 +-
arch/arm/mach-pxa/cm-x300.c | 2 +-
...ibri-pxa270-evalboard.c => colibri-evalboard.c} | 96 ++--
arch/arm/mach-pxa/colibri-pxa270-income.c | 47 --
arch/arm/mach-pxa/colibri-pxa270.c | 108 +++-
arch/arm/mach-pxa/colibri-pxa300.c | 73 +-
arch/arm/mach-pxa/colibri-pxa320.c | 139 ++--
arch/arm/mach-pxa/colibri-pxa3xx.c | 49 --
arch/arm/mach-pxa/corgi.c | 6 +-
arch/arm/mach-pxa/cpufreq-pxa2xx.c | 10 +-
arch/arm/mach-pxa/csb726.c | 9 +-
arch/arm/mach-pxa/devices.c | 247 ++++----
arch/arm/mach-pxa/em-x270.c | 4 +-
arch/arm/mach-pxa/eseries.c | 12 +-
arch/arm/mach-pxa/ezx.c | 12 +-
arch/arm/mach-pxa/generic.c | 48 +-
arch/arm/mach-pxa/generic.h | 11 +-
arch/arm/mach-pxa/gumstix.c | 2 +-
arch/arm/mach-pxa/h5000.c | 11 +-
arch/arm/mach-pxa/himalaya.c | 2 +-
arch/arm/mach-pxa/hx4700.c | 2 +-
arch/arm/mach-pxa/icontrol.c | 2 +-
arch/arm/mach-pxa/idp.c | 2 +-
arch/arm/mach-pxa/include/mach/addr-map.h | 48 ++
arch/arm/mach-pxa/include/mach/balloon3.h | 6 +-
arch/arm/mach-pxa/include/mach/colibri.h | 14 +-
arch/arm/mach-pxa/include/mach/hardware.h | 47 +-
arch/arm/mach-pxa/include/mach/irqs.h | 48 +-
arch/arm/mach-pxa/include/mach/pxa2xx-regs.h | 66 --
arch/arm/mach-pxa/include/mach/pxa3xx-regs.h | 9 -
arch/arm/mach-pxa/include/mach/regs-intc.h | 4 -
arch/arm/mach-pxa/include/mach/smemc.h | 74 ++
arch/arm/mach-pxa/irq.c | 129 +++--
arch/arm/mach-pxa/littleton.c | 2 +-
arch/arm/mach-pxa/lpd270.c | 5 +-
arch/arm/mach-pxa/lubbock.c | 5 +-
arch/arm/mach-pxa/magician.c | 2 +-
arch/arm/mach-pxa/mainstone.c | 5 +-
arch/arm/mach-pxa/mioa701.c | 2 +-
arch/arm/mach-pxa/mp900.c | 2 +-
arch/arm/mach-pxa/palmld.c | 2 +-
arch/arm/mach-pxa/palmt5.c | 2 +-
arch/arm/mach-pxa/palmtc.c | 190 ++++-
arch/arm/mach-pxa/palmte2.c | 2 +-
arch/arm/mach-pxa/palmtreo.c | 4 +-
arch/arm/mach-pxa/palmtx.c | 2 +-
arch/arm/mach-pxa/palmz72.c | 2 +-
arch/arm/mach-pxa/pcm027.c | 2 +-
arch/arm/mach-pxa/poodle.c | 2 +-
arch/arm/mach-pxa/pxa25x.c | 86 ++-
arch/arm/mach-pxa/pxa27x.c | 102 ++-
arch/arm/mach-pxa/pxa3xx.c | 234 +------
arch/arm/mach-pxa/pxa930.c | 2 +-
arch/arm/mach-pxa/pxa95x.c | 308 ++++++++
arch/arm/mach-pxa/raumfeld.c | 11 +-
arch/arm/mach-pxa/saar.c | 2 +-
arch/arm/mach-pxa/saarb.c | 114 +++
arch/arm/mach-pxa/sleep.S | 2 +-
arch/arm/mach-pxa/smemc.c | 51 +-
arch/arm/mach-pxa/spitz.c | 13 +-
arch/arm/mach-pxa/stargate2.c | 7 +-
arch/arm/mach-pxa/tavorevb.c | 2 +-
arch/arm/mach-pxa/tavorevb3.c | 2 +-
arch/arm/mach-pxa/tosa.c | 9 +-
arch/arm/mach-pxa/trizeps4.c | 5 +-
arch/arm/mach-pxa/viper.c | 2 +-
arch/arm/mach-pxa/vpac270.c | 2 +-
arch/arm/mach-pxa/xcep.c | 7 +-
arch/arm/mach-pxa/z2.c | 2 +-
arch/arm/mach-pxa/zeus.c | 10 +-
arch/arm/mach-pxa/zylonite.c | 2 +-
arch/arm/mm/Kconfig | 8 +-
arch/arm/plat-pxa/Makefile | 1 +
arch/arm/plat-pxa/include/plat/mfp.h | 4 +-
drivers/pcmcia/Kconfig | 3 +-
drivers/pcmcia/Makefile | 2 +
drivers/pcmcia/pxa2xx_balloon3.c | 11 +-
drivers/pcmcia/pxa2xx_base.c | 64 ++-
drivers/pcmcia/pxa2xx_colibri.c | 229 ++++++
drivers/pcmcia/soc_common.h | 3 +
drivers/video/Kconfig | 10 +
drivers/video/Makefile | 1 +
drivers/video/pxa3xx-gcu.c | 772 ++++++++++++++++++++
drivers/video/pxa3xx-gcu.h | 38 +
106 files changed, 3671 insertions(+), 1313 deletions(-)
create mode 100644 arch/arm/kernel/pj4-cp0.c
create mode 100644 arch/arm/mach-mmp/brownstone.c
create mode 100644 arch/arm/mach-pxa/clock-pxa2xx.c
create mode 100644 arch/arm/mach-pxa/clock-pxa3xx.c
rename arch/arm/mach-pxa/{colibri-pxa270-evalboard.c =>
colibri-evalboard.c} (51%)
create mode 100644 arch/arm/mach-pxa/include/mach/addr-map.h
create mode 100644 arch/arm/mach-pxa/include/mach/smemc.h
create mode 100644 arch/arm/mach-pxa/pxa95x.c
create mode 100644 arch/arm/mach-pxa/saarb.c
create mode 100644 drivers/pcmcia/pxa2xx_colibri.c
create mode 100644 drivers/video/pxa3xx-gcu.c
create mode 100644 drivers/video/pxa3xx-gcu.h
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-12-22 9:09 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-25 2:49 [GIT PULL] pxa: patches for next merge window Eric Miao
2010-02-25 20:51 ` Russell King - ARM Linux
2010-02-25 21:29 ` Russell King - ARM Linux
2010-02-26 2:50 ` Eric Miao
2010-02-26 9:05 ` Eric Miao
2010-02-28 16:14 ` Russell King - ARM Linux
2010-03-01 0:42 ` Nicolas Pitre
2010-03-01 13:23 ` Eric Miao
2010-03-01 15:16 ` Russell King - ARM Linux
2010-03-02 4:48 ` Eric Miao
2010-03-01 9:39 ` Uwe Kleine-König
2010-03-01 9:48 ` Russell King - ARM Linux
2010-03-01 10:11 ` Paul Mundt
2010-03-01 10:27 ` Uwe Kleine-König
2010-03-02 0:33 ` Stephen Rothwell
2010-03-01 10:12 ` Uwe Kleine-König
2010-03-01 16:40 ` Linus Torvalds
2010-03-01 16:58 ` Linus Torvalds
2010-03-01 17:07 ` Russell King - ARM Linux
2010-12-22 9:09 Eric Miao
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.