* [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-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 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-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 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 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 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 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-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 threadend 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.