What's inside the pxa tree for this merge window

What's inside the pxa tree for this merge window

[Eric Miao]

Here's the preview of request-pull result, please let me know if there
is anything missed, thanks.

URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git

Alex Roman (1):
      [ARM] pxa/colibri: add UART MFP configuration for the PXA320 module

Aric D. Blumer (1):
      USB: ohci-pxa27x: Reconfigure power settings on resume

Daniel Mack (6):
      [ARM] pxa: add MFP_PULL_FLOAT
      [ARM] pxa: add clock definition for graphics controller
      [ARM] pxa: add device definition for graphics controller
      [ARM] pxa: rename GCU IRQ for consistency
      [ARM] pxafb: use resource_size() function
      [ARM] pxa/colibri: add NAND config for Colibri PXA3xx boards

Daniel Ribeiro (1):
      [ARM] pxa/ezx: set IRQ_BOARD_END for EZX

Eric Miao (3):
      [ARM] pxa/littleton: update littleton to use the new
gpio_card_detect for mmc
      [ARM] pxa/corgi: make use of GPIO based matrix keypad driver
      [ARM] pxa/spitz: make use of GPIO based matrix keypad driver

Guennadi Liakhovetski (3):
      [ARM] pxa/pcm990: convert pcm990 to soc-camera as platform-device
      [ARM] pxa/mioa701: convert mioa701 to the new platform-device
soc-camera interface
      [ARM] pxa/em-x270: convert em-x270 to soc-camera as platform-device

Haojian Zhuang (10):
      [ARM] pxa: remove duplicate mfp definition in mach
      [ARM] pxa: support mfp of pxa935
      [ARM] pxa: expand irq support for PXA93x and PXA950
      [ARM] pxa: update cpu_is_xsc3() to include Marvell CPUID
      [ARM] pxa: add cpu_is_pxa950() and Kconfig options
      [ARM] pxa: add more registers in interrupt controller
      [ARM] pxa: initialize default interrupt priority and use ICHP
for IRQ handling
      [ARM] pxa: update dependancy of pxa i2c module
      [ARM] pxa: merge {zylonite,littleton}_defconfig into pxa3xx_defconfig
      [ARM] pxa: update rtc-sa1100.c to use 'struct dev_pm_ops'

Jonathan McDowell (1):
      [ARM] pxa: balloon3 (http://balloonboard.org/) base machine support

Marek Vasut (9):
      [ARM] pxa/palm: add detect_delay to mmc for PalmTX,T5,LD
      [ARM] pxa/palm: Add NOR flash support for PalmLD
      [ARM] pxa/palm: add NAND Flash support for PalmTX
      [ARM] pxa/palm: Add NOR Flash support for PalmTX
      [ARM] pxa: Palm Tungsten|C initial support
      [ARM] pxa: Palm Tungsten|C PCMCIA support
      [ARM] pxa/palm: fix possibly uninitialized variable in PalmTC-pcmcia
      [ARM] pxa: add gpio_pwdown(_inverted) into pxaficp_ir.c
      MAINTAINERS: fix mailing list entries for ARM/Palm devices

Matej Kenda (2):
      [ARM] pxa: add support for the IskraTel XCEP board
      [ARM] pxa: add defconfig for IskraTel XCEP board

Mike Rapoport (11):
      [ARM] pxa/em-x270: remove debug leftovers
      [ARM] pxa/em-x270: add vcc_core regulator
      [ARM] pxa/cm-x270: add libertas device registration
      [ARM] pxa: update da903x_bl.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pxa serial driver to use 'struct dev_pm_ops'
      [ARM] pxa: update ohci-pxa27x.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pxa2xx-spi.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pxafb.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pxa2xx-ac97.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pxamci.c to use 'struct dev_pm_ops'
      [ARM] pxa: update pcmcia/pxa2xx_base.c to use 'struct dev_pm_ops'

Philipp Zabel (2):
      [ARM] pxa: remove left-over struct clk *other field from struct clk
      [ARM] pxa/hx4700: use platform_lcd driver

Robert Jarzmik (6):
      [ARM] pxa/dma: cosmetic move of EXPORT_SYMBOL under their functions
      [ARM] pxa/dma: optimize irq handler loop
      [ARM] pxa/dma: add debugfs entries
      [ARM] pxamci: add simple gpio controls
      [ARM] pxa: factor pxamci gpio handling
      [ARM] pxa: update rtc-pxa.c to use 'struct dev_pm_ops'

Tom?? ?ech (1):
      [ARM] pxa/treo680: move LCD power GPIO to proper place

walker at suse.cz (1):
      [ARM] pxa/treo680: pxamci simplify to use GPIO

What's inside the pxa tree for this merge window

[Daniel Mack]

On Thu, Sep 10, 2009 at 07:46:26PM +0800, Eric Miao wrote:
> Daniel Mack (6):
>       [ARM] pxa: add MFP_PULL_FLOAT
>       [ARM] pxa: add clock definition for graphics controller
>       [ARM] pxa: add device definition for graphics controller
>       [ARM] pxa: rename GCU IRQ for consistency

Regarding the PXA3xx GCU driver:

I really wonder what's wrong with the fbdev people to ignore my very
simple patch for pxa3xx gcu enabling (not the gcu driver itself but just
the acceleration ID registration), even after the fifth (or so)
repost.

We've been using this driver for quite some time now. There's a small
bug hiding somewhere which we are currently trying to sort out, but
that's most probably not in the kernel driver but in the DirectFB part.
It would, however, be much easier for people to help testing if the
driver was upstream.

Is there any way to push things a little? Except for that one bug, the
driver is a huge benefit for any PXA3xx application with graphical user
interface, so I'd really like to see it mainline. The sooner the better.

Thanks,
Daniel

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

On Thu, 10 Sep 2009, Daniel Mack wrote:

> On Thu, Sep 10, 2009 at 07:46:26PM +0800, Eric Miao wrote:
> > Daniel Mack (6):
> >       [ARM] pxa: add MFP_PULL_FLOAT
> >       [ARM] pxa: add clock definition for graphics controller
> >       [ARM] pxa: add device definition for graphics controller
> >       [ARM] pxa: rename GCU IRQ for consistency
> 
> Regarding the PXA3xx GCU driver:
> 
> I really wonder what's wrong with the fbdev people to ignore my very
> simple patch for pxa3xx gcu enabling (not the gcu driver itself but just
> the acceleration ID registration), even after the fifth (or so)
> repost.

I think, Andrew Morton is taking care of fbdev patches currently, try to 
ping him.

> We've been using this driver for quite some time now. There's a small
> bug hiding somewhere which we are currently trying to sort out, but
> that's most probably not in the kernel driver but in the DirectFB part.
> It would, however, be much easier for people to help testing if the
> driver was upstream.
> 
> Is there any way to push things a little? Except for that one bug, the
> driver is a huge benefit for any PXA3xx application with graphical user
> interface, so I'd really like to see it mainline. The sooner the better.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

What's inside the pxa tree for this merge window

[Eric Miao]

On Thu, Sep 10, 2009 at 7:54 PM, Daniel Mack <daniel@caiaq.de> wrote:
> On Thu, Sep 10, 2009 at 07:46:26PM +0800, Eric Miao wrote:
>> Daniel Mack (6):
>> ? ? ? [ARM] pxa: add MFP_PULL_FLOAT
>> ? ? ? [ARM] pxa: add clock definition for graphics controller
>> ? ? ? [ARM] pxa: add device definition for graphics controller
>> ? ? ? [ARM] pxa: rename GCU IRQ for consistency
>
> Regarding the PXA3xx GCU driver:
>
> I really wonder what's wrong with the fbdev people to ignore my very
> simple patch for pxa3xx gcu enabling (not the gcu driver itself but just
> the acceleration ID registration), even after the fifth (or so)
> repost.
>

Mmm... I don't actually see there is any problem with that patch. I can
take it if you are OK.

BTW: do you think CONFIG_PXA3xx_GCU is necessary around the
FB_ACCEL_PXA3xx assignment?

What's inside the pxa tree for this merge window

[Daniel Mack]

On Thu, Sep 10, 2009 at 08:23:00PM +0800, Eric Miao wrote:
> On Thu, Sep 10, 2009 at 7:54 PM, Daniel Mack <daniel@caiaq.de> wrote:
> > Regarding the PXA3xx GCU driver:
> >
> > I really wonder what's wrong with the fbdev people to ignore my very
> > simple patch for pxa3xx gcu enabling (not the gcu driver itself but just
> > the acceleration ID registration), even after the fifth (or so)
> > repost.
> >
> 
> Mmm... I don't actually see there is any problem with that patch. I can
> take it if you are OK.

Yes, please :) I thought you were mentioning you'd be needing an ACK
from the fbdev people.

> BTW: do you think CONFIG_PXA3xx_GCU is necessary around the
> FB_ACCEL_PXA3xx assignment?

Hmm, I'd say you don't want fb.fix.accel set unless the driver is
enabled, right?

Thanks,
Daniel

What's inside the pxa tree for this merge window

[Eric Miao]

On Thu, Sep 10, 2009 at 8:32 PM, Daniel Mack <daniel@caiaq.de> wrote:
> On Thu, Sep 10, 2009 at 08:23:00PM +0800, Eric Miao wrote:
>> On Thu, Sep 10, 2009 at 7:54 PM, Daniel Mack <daniel@caiaq.de> wrote:
>> > Regarding the PXA3xx GCU driver:
>> >
>> > I really wonder what's wrong with the fbdev people to ignore my very
>> > simple patch for pxa3xx gcu enabling (not the gcu driver itself but just
>> > the acceleration ID registration), even after the fifth (or so)
>> > repost.
>> >
>>
>> Mmm... I don't actually see there is any problem with that patch. I can
>> take it if you are OK.
>
> Yes, please :) I thought you were mentioning you'd be needing an ACK
> from the fbdev people.
>

Yeah, but in case of no one Ack...

>> BTW: do you think CONFIG_PXA3xx_GCU is necessary around the
>> FB_ACCEL_PXA3xx assignment?
>
> Hmm, I'd say you don't want fb.fix.accel set unless the driver is
> enabled, right?
>

I'm not sure if it can be set anyway without the driver being
built. I mean - I don't want Kconfig option to cross modules.

What's inside the pxa tree for this merge window

[Daniel Mack]

On Thu, Sep 10, 2009 at 08:35:51PM +0800, Eric Miao wrote:
> On Thu, Sep 10, 2009 at 8:32 PM, Daniel Mack <daniel@caiaq.de> wrote:
> > Hmm, I'd say you don't want fb.fix.accel set unless the driver is
> > enabled, right?
> >
> 
> I'm not sure if it can be set anyway without the driver being
> built.

DirectFB userspace applications take that value to decide whether to
enable the acceleration driver or go for software fallbacks. If that
field is set, the kernel is expected to come along with the driver
interface.

Hence, it should really only be set if the driver is enabled, otherwise
the userspace logic breaks.

> I mean - I don't want Kconfig option to cross modules.

I agree, and it would be even better to only set that field in case the
driver has actually been probed (and not just enabled in the kernel
config). But I see no clean way to do that - the gcu driver has no
access to the framebuffer driver and its data structs either.

Daniel

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

On Thu, 10 Sep 2009, Daniel Mack wrote:

> On Thu, Sep 10, 2009 at 08:35:51PM +0800, Eric Miao wrote:
> > On Thu, Sep 10, 2009 at 8:32 PM, Daniel Mack <daniel@caiaq.de> wrote:
> > > Hmm, I'd say you don't want fb.fix.accel set unless the driver is
> > > enabled, right?
> > >
> > 
> > I'm not sure if it can be set anyway without the driver being
> > built.
> 
> DirectFB userspace applications take that value to decide whether to
> enable the acceleration driver or go for software fallbacks. If that
> field is set, the kernel is expected to come along with the driver
> interface.
> 
> Hence, it should really only be set if the driver is enabled, otherwise
> the userspace logic breaks.
> 
> > I mean - I don't want Kconfig option to cross modules.
> 
> I agree, and it would be even better to only set that field in case the
> driver has actually been probed (and not just enabled in the kernel
> config). But I see no clean way to do that - the gcu driver has no
> access to the framebuffer driver and its data structs either.

Yeah, that doesn't look pretty. Maybe add a field to struct 
pxafb_mach_info? You can put its assignment in respective platform data 
instances under an #ifdef - that's more acceptable, IMHO. Of course, it is 
still worse than beeing able to switch this at run-time. But you could 
trick by setting that field at run-time if acceleration is available, 
provided you have that info before pxafb initialises. Also consider, there 
might be more PXA SoCs in the future using pxafb and providing hardware 
acceleration.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

What's inside the pxa tree for this merge window

[Daniel Mack]

On Thu, Sep 10, 2009 at 03:05:51PM +0200, Guennadi Liakhovetski wrote:
> On Thu, 10 Sep 2009, Daniel Mack wrote:
> 
> > I agree, and it would be even better to only set that field in case the
> > driver has actually been probed (and not just enabled in the kernel
> > config). But I see no clean way to do that - the gcu driver has no
> > access to the framebuffer driver and its data structs either.
> 
> Yeah, that doesn't look pretty. Maybe add a field to struct 
> pxafb_mach_info? You can put its assignment in respective platform data 
> instances under an #ifdef - that's more acceptable, IMHO. Of course, it is 
> still worse than beeing able to switch this at run-time. But you could 
> trick by setting that field at run-time if acceleration is available, 
> provided you have that info before pxafb initialises. Also consider, there 
> might be more PXA SoCs in the future using pxafb and providing hardware 
> acceleration.

Jep, that's a good idea. Will send a new patch for that later.

Thanks,
Daniel

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

Hi Eric,

On Thu, 10 Sep 2009, Eric Miao wrote:

> Here's the preview of request-pull result, please let me know if there
> is anything missed, thanks.
> 
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git

[snip]

> Guennadi Liakhovetski (3):
>       [ARM] pxa/pcm990: convert pcm990 to soc-camera as platform-device
>       [ARM] pxa/mioa701: convert mioa701 to the new platform-device soc-camera interface
>       [ARM] pxa/em-x270: convert em-x270 to soc-camera as platform-device

Could you please try to push your tree to Linus as early in the merge 
cycle as possible? The v4l tree depends on the above patches, and sh 
depends on v4l. Is your tree going to Linus via Russell or directly?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

What's inside the pxa tree for this merge window

[Russell King - ARM Linux]

On Mon, Sep 14, 2009 at 01:03:33PM +0200, Guennadi Liakhovetski wrote:
> Hi Eric,
> 
> On Thu, 10 Sep 2009, Eric Miao wrote:
> 
> > Here's the preview of request-pull result, please let me know if there
> > is anything missed, thanks.
> > 
> > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> 
> [snip]
> 
> > Guennadi Liakhovetski (3):
> >       [ARM] pxa/pcm990: convert pcm990 to soc-camera as platform-device
> >       [ARM] pxa/mioa701: convert mioa701 to the new platform-device soc-camera interface
> >       [ARM] pxa/em-x270: convert em-x270 to soc-camera as platform-device
> 
> Could you please try to push your tree to Linus as early in the merge 
> cycle as possible? The v4l tree depends on the above patches, and sh 
> depends on v4l. Is your tree going to Linus via Russell or directly?

The request was for me to merge it into my tree.  However, last Saturday
I asked Linus to pull my tree... still waiting, so I'm not going to merge
anything further until that's reached some resolution.

It's a very bad idea to change trees after a pull request has been sent.

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

On Mon, 14 Sep 2009, Russell King - ARM Linux wrote:

> On Mon, Sep 14, 2009 at 01:03:33PM +0200, Guennadi Liakhovetski wrote:
> > Hi Eric,
> > 
> > On Thu, 10 Sep 2009, Eric Miao wrote:
> > 
> > > Here's the preview of request-pull result, please let me know if there
> > > is anything missed, thanks.
> > > 
> > > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> > 
> > [snip]
> > 
> > > Guennadi Liakhovetski (3):
> > >       [ARM] pxa/pcm990: convert pcm990 to soc-camera as platform-device
> > >       [ARM] pxa/mioa701: convert mioa701 to the new platform-device soc-camera interface
> > >       [ARM] pxa/em-x270: convert em-x270 to soc-camera as platform-device
> > 
> > Could you please try to push your tree to Linus as early in the merge 
> > cycle as possible? The v4l tree depends on the above patches, and sh 
> > depends on v4l. Is your tree going to Linus via Russell or directly?
> 
> The request was for me to merge it into my tree.  However, last Saturday
> I asked Linus to pull my tree... still waiting, so I'm not going to merge
> anything further until that's reached some resolution.
> 
> It's a very bad idea to change trees after a pull request has been sent.

Ic, Eric, when would you be pushing your tree then?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

What's inside the pxa tree for this merge window

[Eric Miao]

On Tue, Sep 15, 2009 at 2:30 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Mon, 14 Sep 2009, Russell King - ARM Linux wrote:
>
>> On Mon, Sep 14, 2009 at 01:03:33PM +0200, Guennadi Liakhovetski wrote:
>> > Hi Eric,
>> >
>> > On Thu, 10 Sep 2009, Eric Miao wrote:
>> >
>> > > Here's the preview of request-pull result, please let me know if there
>> > > is anything missed, thanks.
>> > >
>> > > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
>> >
>> > [snip]
>> >
>> > > Guennadi Liakhovetski (3):
>> > > ? ? ? [ARM] pxa/pcm990: convert pcm990 to soc-camera as platform-device
>> > > ? ? ? [ARM] pxa/mioa701: convert mioa701 to the new platform-device soc-camera interface
>> > > ? ? ? [ARM] pxa/em-x270: convert em-x270 to soc-camera as platform-device
>> >
>> > Could you please try to push your tree to Linus as early in the merge
>> > cycle as possible? The v4l tree depends on the above patches, and sh
>> > depends on v4l. Is your tree going to Linus via Russell or directly?
>>
>> The request was for me to merge it into my tree. ?However, last Saturday
>> I asked Linus to pull my tree... still waiting, so I'm not going to merge
>> anything further until that's reached some resolution.
>>
>> It's a very bad idea to change trees after a pull request has been sent.
>
> Ic, Eric, when would you be pushing your tree then?
>

Request has already been sent.

What's inside the pxa tree for this merge window

[Russell King - ARM Linux]

On Tue, Sep 15, 2009 at 02:50:36PM +0800, Eric Miao wrote:
> On Tue, Sep 15, 2009 at 2:30 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
> > On Mon, 14 Sep 2009, Russell King - ARM Linux wrote:
> >
> >> The request was for me to merge it into my tree. ?However, last Saturday
> >> I asked Linus to pull my tree... still waiting, so I'm not going to merge
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> anything further until that's reached some resolution.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> It's a very bad idea to change trees after a pull request has been sent.
> >
> > Ic, Eric, when would you be pushing your tree then?
> >
> 
> Request has already been sent.

It seems from your following email (to the pull request) that neither of
you actually read what I said.  The relevent bit is underlined with ^'s.

It has now been merged, so I can now start merging stuff into my tree
again.

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

On Tue, 15 Sep 2009, Russell King - ARM Linux wrote:

> On Tue, Sep 15, 2009 at 02:50:36PM +0800, Eric Miao wrote:
> > On Tue, Sep 15, 2009 at 2:30 PM, Guennadi Liakhovetski
> > <g.liakhovetski@gmx.de> wrote:
> > > On Mon, 14 Sep 2009, Russell King - ARM Linux wrote:
> > >
> > >> The request was for me to merge it into my tree. ?However, last Saturday
> > >> I asked Linus to pull my tree... still waiting, so I'm not going to merge
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >> anything further until that's reached some resolution.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>
> > >> It's a very bad idea to change trees after a pull request has been sent.
> > >
> > > Ic, Eric, when would you be pushing your tree then?
> > >
> > 
> > Request has already been sent.
> 
> It seems from your following email (to the pull request) that neither of
> you actually read what I said.  The relevent bit is underlined with ^'s.
> 
> It has now been merged, so I can now start merging stuff into my tree
> again.

I did read it, what I wasn't sure about is after

Eric has sent a pull request to you
you have sent a pull request to Linus
Linus has merged your tree
you can (and will) now pull further trees

whether you will be sending another pull request to Linus in this merge 
window and if so - approximately when. Or whether because Eric's request 
has missed your first pull request it now has to be pulled directly by 
Linus to make it in this window. After this your reply it seems to be the 
former, so, I'm hoping you'll be sending a next pull request to Linus with 
PXA patches in your tree some time soon in this merge window.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

What's inside the pxa tree for this merge window

[Matej Kenda]

On Thu, 2009-09-10 at 19:46 +0800, Eric Miao wrote:
> Here's the preview of request-pull result, please let me know if there
> is anything missed, thanks.
> 
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> 
> 
> Matej Kenda (2):
>       [ARM] pxa: add support for the IskraTel XCEP board
>       [ARM] pxa: add defconfig for IskraTel XCEP board

Eric, what is the current status of this request? Do I need to repost
the patches to included into 2.6.32?

Russell discarded them from his patch system, because they are on your
list.

Thanks,

Matej

What's inside the pxa tree for this merge window

[Eric Miao]

On Fri, Sep 18, 2009 at 2:43 PM, Matej Kenda <matejken@gmail.com> wrote:
> On Thu, 2009-09-10 at 19:46 +0800, Eric Miao wrote:
>> Here's the preview of request-pull result, please let me know if there
>> is anything missed, thanks.
>>
>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
>>
>>
>> Matej Kenda (2):
>> ? ? ? [ARM] pxa: add support for the IskraTel XCEP board
>> ? ? ? [ARM] pxa: add defconfig for IskraTel XCEP board
>
> Eric, what is the current status of this request? Do I need to repost
> the patches to included into 2.6.32?
>
> Russell discarded them from his patch system, because they are on your
> list.
>

Then those will be merged by Russell and finally propagates into Linus' tree,
so don't worry about that.

What's inside the pxa tree for this merge window

[Russell King - ARM Linux]

On Fri, Sep 18, 2009 at 08:43:47AM +0200, Matej Kenda wrote:
> On Thu, 2009-09-10 at 19:46 +0800, Eric Miao wrote:
> > Here's the preview of request-pull result, please let me know if there
> > is anything missed, thanks.
> > 
> > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> > 
> > 
> > Matej Kenda (2):
> >       [ARM] pxa: add support for the IskraTel XCEP board
> >       [ARM] pxa: add defconfig for IskraTel XCEP board
> 
> Eric, what is the current status of this request? Do I need to repost
> the patches to included into 2.6.32?
> 
> Russell discarded them from his patch system, because they are on your
> list.

I discarded them _because_ Eric handled them, which is what I said in the
comments when I discarded them.

What's inside the pxa tree for this merge window

[Guennadi Liakhovetski]

On Fri, 18 Sep 2009, Russell King - ARM Linux wrote:

> On Fri, Sep 18, 2009 at 08:43:47AM +0200, Matej Kenda wrote:
> > On Thu, 2009-09-10 at 19:46 +0800, Eric Miao wrote:
> > > Here's the preview of request-pull result, please let me know if there
> > > is anything missed, thanks.
> > > 
> > > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> > > 
> > > 
> > > Matej Kenda (2):
> > >       [ARM] pxa: add support for the IskraTel XCEP board
> > >       [ARM] pxa: add defconfig for IskraTel XCEP board
> > 
> > Eric, what is the current status of this request? Do I need to repost
> > the patches to included into 2.6.32?
> > 
> > Russell discarded them from his patch system, because they are on your
> > list.
> 
> I discarded them _because_ Eric handled them, which is what I said in the
> comments when I discarded them.

Ok, I did do my best to get patches in the right order in the mainline, 
but it all failed. AFAICS, v4l and sh are already in the mainline with a 
_wrongly_ resolved mefge conflict, which, most likely, breaks the 
sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for 
which should have been applied before both those trees and still haven't 
been applied are broken until the patches do get in and the later those 
patches get applied the longer the interval with the broken for them 
bisection is going to be.

Thanks
Guennadi
---
Guennadi Liakhovetski

What's inside the pxa tree for this merge window

[Russell King - ARM Linux]

On Mon, Sep 21, 2009 at 09:19:46PM +0200, Guennadi Liakhovetski wrote:
> On Fri, 18 Sep 2009, Russell King - ARM Linux wrote:
> 
> > On Fri, Sep 18, 2009 at 08:43:47AM +0200, Matej Kenda wrote:
> > > On Thu, 2009-09-10 at 19:46 +0800, Eric Miao wrote:
> > > > Here's the preview of request-pull result, please let me know if there
> > > > is anything missed, thanks.
> > > > 
> > > > URL: git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> > > > 
> > > > 
> > > > Matej Kenda (2):
> > > >       [ARM] pxa: add support for the IskraTel XCEP board
> > > >       [ARM] pxa: add defconfig for IskraTel XCEP board
> > > 
> > > Eric, what is the current status of this request? Do I need to repost
> > > the patches to included into 2.6.32?
> > > 
> > > Russell discarded them from his patch system, because they are on your
> > > list.
> > 
> > I discarded them _because_ Eric handled them, which is what I said in the
> > comments when I discarded them.
> 
> Ok, I did do my best to get patches in the right order in the mainline, 
> but it all failed. AFAICS, v4l and sh are already in the mainline with a 
> _wrongly_ resolved mefge conflict, which, most likely, breaks the 
> sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for 
> which should have been applied before both those trees and still haven't 
> been applied are broken until the patches do get in and the later those 
> patches get applied the longer the interval with the broken for them 
> bisection is going to be.

Meanwhile I have to consider that we have several bug fixes outstanding,
and since I can't send Linus a pull request every day (max once a week)
I have to be very careful about when I send stuff.

So I only get _two_ opportunities during a merge window to send a pull
request.

I'm going to wait until tomorrow before sending my final pull for this
window, which is the penultimate day before the window closes.

Don't blame me for these delays - it's not my choice to impose such
delays.  I'd really like to fix those broken platforms right now.  I
just can't do so without causing additional delays for other issues.
Blame Linus for imposing the "max one pull a week" rule on me.

What's inside the pxa tree for this merge window

[Jamie Lokier]

Russell King - ARM Linux wrote:
> Don't blame me for these delays - it's not my choice to impose such
> delays.  I'd really like to fix those broken platforms right now.  I
> just can't do so without causing additional delays for other issues.
> Blame Linus for imposing the "max one pull a week" rule on me.

Fwiw,I'm thinking the clrex-on-exception-return fix, at least, should
go to stable at kernel.org too if it's proving to be reliable, as it
affects userspace correctness on ARMv6+.

-- Jamie

arm tree in broken state (was Re: What's inside the pxa tree for this merge window)

[Pavel Machek]

> > > I discarded them _because_ Eric handled them, which is what I said in the
> > > comments when I discarded them.
> > 
> > Ok, I did do my best to get patches in the right order in the mainline, 
> > but it all failed. AFAICS, v4l and sh are already in the mainline with a 
> > _wrongly_ resolved mefge conflict, which, most likely, breaks the 
> > sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for 
> > which should have been applied before both those trees and still haven't 
> > been applied are broken until the patches do get in and the later those 
> > patches get applied the longer the interval with the broken for them 
> > bisection is going to be.
> 
> Meanwhile I have to consider that we have several bug fixes outstanding,
> and since I can't send Linus a pull request every day (max once a week)
> I have to be very careful about when I send stuff.
> 
> So I only get _two_ opportunities during a merge window to send a pull
> request.

Well, you should certainly try to keep your tree  unbroken, but when
it breaks, fixing it asap should be a priority. I don't know where you
got the 'once a week' rule, but it seems stupid.

> I'm going to wait until tomorrow before sending my final pull for this
> window, which is the penultimate day before the window closes.
> 
> Don't blame me for these delays - it's not my choice to impose such
> delays.  I'd really like to fix those broken platforms right now.  I
> just can't do so without causing additional delays for other issues.
> Blame Linus for imposing the "max one pull a week" rule on me.

Do you have maillist reference? Not even Linus should slow down
development like that.

If Linus really insists on that, perhaps possible solution would be to
make subarch maintainers send pull requests for simple fixes directly
to Linus?

								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

arm tree in broken state (was Re: What's inside the pxa tree for this merge window)

[Guennadi Liakhovetski]

Hi Pavel

On Wed, 30 Sep 2009, Pavel Machek wrote:

> > > > I discarded them _because_ Eric handled them, which is what I said in the
> > > > comments when I discarded them.
> > > 
> > > Ok, I did do my best to get patches in the right order in the mainline, 
> > > but it all failed. AFAICS, v4l and sh are already in the mainline with a 
> > > _wrongly_ resolved mefge conflict, which, most likely, breaks the 
> > > sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for 
> > > which should have been applied before both those trees and still haven't 
> > > been applied are broken until the patches do get in and the later those 
> > > patches get applied the longer the interval with the broken for them 
> > > bisection is going to be.
> > 
> > Meanwhile I have to consider that we have several bug fixes outstanding,
> > and since I can't send Linus a pull request every day (max once a week)
> > I have to be very careful about when I send stuff.
> > 
> > So I only get _two_ opportunities during a merge window to send a pull
> > request.
> 
> Well, you should certainly try to keep your tree  unbroken, but when
> it breaks, fixing it asap should be a priority. I don't know where you
> got the 'once a week' rule, but it seems stupid.
> 
> > I'm going to wait until tomorrow before sending my final pull for this
> > window, which is the penultimate day before the window closes.
> > 
> > Don't blame me for these delays - it's not my choice to impose such
> > delays.  I'd really like to fix those broken platforms right now.  I
> > just can't do so without causing additional delays for other issues.
> > Blame Linus for imposing the "max one pull a week" rule on me.
> 
> Do you have maillist reference? Not even Linus should slow down
> development like that.
> 
> If Linus really insists on that, perhaps possible solution would be to
> make subarch maintainers send pull requests for simple fixes directly
> to Linus?

Thanks for your concern, but the patches are long in mainline, no reason 
to worry any more.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/