From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 00/81] SH pin control and GPIO rework
Date: Mon, 07 Jan 2013 19:33:55 +0000 [thread overview]
Message-ID: <3937593.RWUOL6AydO@avalon> (raw)
In-Reply-To: <20130107030310.GA14865@verge.net.au>
Hi Simon,
On Monday 07 January 2013 12:03:10 Simon Horman wrote:
> On Thu, Jan 03, 2013 at 05:40:47PM +0100, Laurent Pinchart wrote:
> > On Sunday 30 December 2012 09:12:02 Simon Horman wrote:
> > > [ CC: linux-arm-kernel, Olof Johansson, Arnd Bergmann ]
> > >
> > > On Fri, Dec 28, 2012 at 11:53:42PM +0100, Laurent Pinchart wrote:
> > > > Hi everybody,
> > > >
> > > > Here's the fourth version of the SH pin control and GPIO rework
> > > > patches. The patches have been rebased on top of v3.8-rc1 but are
> > > > otherwise unchanged.
> > > >
> > > > The series starts with the same additional platform-specific fixes as
> > > > v3 (patches 4 to 7), I would appreciate if someone could review them
> > > > carefully.
> > > >
> > > > You can get the series from my git tree at
> > > >
> > > > git://linuxtv.org/pinchartl/fbdev.git pinmux
> > > >
> > > > I would like to push this set to v3.9 independently of the later
> > > > rework and OF-related sets. Simon, can you take it in your tree ?
> > >
> > > Sure.
> > >
> > > One inconvenience of my tree is that it goes via the arm-soc tree and as
> > > such things need to be split out into branches. I believe in the case of
> > > this series the patches will need to be split across soc, board and pfc
> > > branches. The branches may be based on each other.
> > >
> > > Do you think the following scheme might work:
> > >
> > > Patches 1 - 7: sh-soc
> > > Patches 8 - 21: pfc, based on sh-soc
> > > Patches 22 - 29: soc (ARM SoC), based on pfc
> > > Patches 30 - 42: sh-soc2, based on pfc
> > > Patches 43 - 50: pfc2, based on a merge of soc and sh-soc2
> > > Patches 51 - 54: soc2 (ARM SoC), based on pfc2
> > > Patches 55 - 66: pfc3, based on soc2
> > > Patches 67 - 78: sh-soc3, based on pfc3
> > > Patches 79 - 81: pfc4, based on sh-soc3
> >
> > That looks good to me. Alternatively you could base pfc3 on top of a merge
> > of soc and sh-soc2, and base pfc4 on top of a merge of soc2 and sh-soc3,
> > but you might get conflicts in Kconfig and Makefile (they should be
> > trivial to solve though).
>
> Thanks, I have used the modified scheme that you describe above and all
> seems well. In detail, I have done the following:
>
> Patches 1 - 7: sh-soc based on v3.8-rc1
> Patches 8 - 21: pfc, based on sh-soc
> Patches 22 - 29: soc (ARM SoC), based on pfc
> Patches 30 - 42: sh-soc2, based on pfc
> Patches 43 - 50 and 55 - 66: pfc2, based on a merge of soc and sh-soc2
> Patches 51 - 54: soc2 (ARM SoC), based on pfc2
> Patches 67 - 78: sh-soc3, based on pfc2
> Patches 79 - 81: pfc4, based on a merge of soc2 and sh-soc-3
>
> Assuming that nothing nasty crops I plan to push the result to
> the renesas tree later today.
Thank you.
Linus acked the next patch series but there are still two issues I need to
solve. I'll repost the patches and send a pull request in the near future.
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 00/81] SH pin control and GPIO rework
Date: Mon, 07 Jan 2013 20:33:55 +0100 [thread overview]
Message-ID: <3937593.RWUOL6AydO@avalon> (raw)
In-Reply-To: <20130107030310.GA14865@verge.net.au>
Hi Simon,
On Monday 07 January 2013 12:03:10 Simon Horman wrote:
> On Thu, Jan 03, 2013 at 05:40:47PM +0100, Laurent Pinchart wrote:
> > On Sunday 30 December 2012 09:12:02 Simon Horman wrote:
> > > [ CC: linux-arm-kernel, Olof Johansson, Arnd Bergmann ]
> > >
> > > On Fri, Dec 28, 2012 at 11:53:42PM +0100, Laurent Pinchart wrote:
> > > > Hi everybody,
> > > >
> > > > Here's the fourth version of the SH pin control and GPIO rework
> > > > patches. The patches have been rebased on top of v3.8-rc1 but are
> > > > otherwise unchanged.
> > > >
> > > > The series starts with the same additional platform-specific fixes as
> > > > v3 (patches 4 to 7), I would appreciate if someone could review them
> > > > carefully.
> > > >
> > > > You can get the series from my git tree at
> > > >
> > > > git://linuxtv.org/pinchartl/fbdev.git pinmux
> > > >
> > > > I would like to push this set to v3.9 independently of the later
> > > > rework and OF-related sets. Simon, can you take it in your tree ?
> > >
> > > Sure.
> > >
> > > One inconvenience of my tree is that it goes via the arm-soc tree and as
> > > such things need to be split out into branches. I believe in the case of
> > > this series the patches will need to be split across soc, board and pfc
> > > branches. The branches may be based on each other.
> > >
> > > Do you think the following scheme might work:
> > >
> > > Patches 1 - 7: sh-soc
> > > Patches 8 - 21: pfc, based on sh-soc
> > > Patches 22 - 29: soc (ARM SoC), based on pfc
> > > Patches 30 - 42: sh-soc2, based on pfc
> > > Patches 43 - 50: pfc2, based on a merge of soc and sh-soc2
> > > Patches 51 - 54: soc2 (ARM SoC), based on pfc2
> > > Patches 55 - 66: pfc3, based on soc2
> > > Patches 67 - 78: sh-soc3, based on pfc3
> > > Patches 79 - 81: pfc4, based on sh-soc3
> >
> > That looks good to me. Alternatively you could base pfc3 on top of a merge
> > of soc and sh-soc2, and base pfc4 on top of a merge of soc2 and sh-soc3,
> > but you might get conflicts in Kconfig and Makefile (they should be
> > trivial to solve though).
>
> Thanks, I have used the modified scheme that you describe above and all
> seems well. In detail, I have done the following:
>
> Patches 1 - 7: sh-soc based on v3.8-rc1
> Patches 8 - 21: pfc, based on sh-soc
> Patches 22 - 29: soc (ARM SoC), based on pfc
> Patches 30 - 42: sh-soc2, based on pfc
> Patches 43 - 50 and 55 - 66: pfc2, based on a merge of soc and sh-soc2
> Patches 51 - 54: soc2 (ARM SoC), based on pfc2
> Patches 67 - 78: sh-soc3, based on pfc2
> Patches 79 - 81: pfc4, based on a merge of soc2 and sh-soc-3
>
> Assuming that nothing nasty crops I plan to push the result to
> the renesas tree later today.
Thank you.
Linus acked the next patch series but there are still two issues I need to
solve. I'll repost the patches and send a pull request in the near future.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-01-07 19:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 22:53 [PATCH v4 00/81] SH pin control and GPIO rework Laurent Pinchart
2012-12-30 0:12 ` Simon Horman
2012-12-30 0:12 ` Simon Horman
2013-01-03 16:40 ` Laurent Pinchart
2013-01-03 16:40 ` Laurent Pinchart
2013-01-07 3:03 ` Simon Horman
2013-01-07 3:03 ` Simon Horman
2013-01-07 19:33 ` Laurent Pinchart [this message]
2013-01-07 19:33 ` Laurent Pinchart
2013-01-08 1:32 ` Simon Horman
2013-01-08 1:32 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3937593.RWUOL6AydO@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.