On Thu, Dec 05, 2013 at 04:03:43PM +0900, Simon Horman wrote: > On Thu, Dec 05, 2013 at 06:53:41AM +0100, Laurent Pinchart wrote: > > Hi Simon, > > > > On Thursday 05 December 2013 12:33:23 Simon Horman wrote: > > > On Tue, Dec 03, 2013 at 07:28:47PM +0100, Laurent Pinchart wrote: > > > > On Tuesday 03 December 2013 10:09:53 Greg KH wrote: > > > > > On Thu, Nov 21, 2013 at 08:17:27AM +0100, Laurent Pinchart wrote: > > > > > > On Thursday 21 November 2013 13:40:38 Simon Horman wrote: > > > > > > > On Tue, Nov 19, 2013 at 03:02:01PM +0100, Laurent Pinchart wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > This is the third version of the patch set adds device tree > > > > > > > > bindings for the sh sci serial port devices and adds OF parsing to > > > > > > > > the sh-sci driver. > > > > > > > > > > > > > > > > The bindings are based on Bastian Hecht's proposal (see > > > > > > > > http://www.spinics.net/lists/arm-kernel/msg228129.html). The > > > > > > > > approach taken here is more minimalistic: instead of describing > > > > > > > > all hardware characteristics that vary between the SCI device > > > > > > > > revisions in DT (such as registers layout), that information is > > > > > > > > stored in the driver and selected based on the compatible property > > > > > > > > value. Only SCI revisions used on ARM devices are supported > > > > > > > > through DT, as DT support for SuperH is nowhere down the line. > > > > > > > > > > > > > > > > Patches 01/29 to 06/29 clean up the sh-sci driver. Patches 07/29 > > > > > > > > to 27/29 replace memory and interrupt resources passed through > > > > > > > > platform data with platform resources. Beside replacing a custom > > > > > > > > mechanism with a standard one, it will also make the DT parsing > > > > > > > > code simpler as resource allocation will be shared between DT and > > > > > > > > non-DT code paths. Finally, patches 28/29 to 29/29 add OF parsing > > > > > > > > to the sh-sci driver and create DT bindings documentation. > > > > > > > > > > > > > > > > The patches have been test on a Lager board (r8a7790-based) and a > > > > > > > > Koelsch board (r8a7791-based). Support for other SoCs will be > > > > > > > > added as needed. Note that all current Renesas ARM SoCs seem to be > > > > > > > > compatible with the generic (H)SCI(F)(AB) devices, but the plan is > > > > > > > > for their DT bindings to list the SoC-specific version in case > > > > > > > > incompatibilities are found later. > > > > > > > > > > > > > > > > The series will need to be split in three parts to go to mainline. > > > > > > > > Patches 01/29 to 07/29 should go through Greg's tree, patches > > > > > > > > 08/29 to 26/29 through Simon's tree, and patches 27/29 to 29/29 > > > > > > > > through Greg's tree again. Greg, when applying the first seven > > > > > > > > patches, could you please provide a stable branch for Simon to > > > > > > > > base his branch on (I can send you a pull request rebased on top > > > > > > > > of v3.13-rc1 if that can help) ? Simon will in turn provide a > > > > > > > > stable branch to base the last three patches on. > > > > > > > > > > > > > > Perhaps you meant to CC Greg? > > > > > > > > > > > > Indeed :-) > > > > > > > > > > That's a mess, how about Simon just take all of these in his tree: > > > > > > > > We all seem to agree that it's the best solution, so let's do that. There > > > > will be a couple of other sh-sci patches for the next kernel version that > > > > should then go through Simon's tree as well. I will make sure to post > > > > them for review on the linux-serial list and CC you to get your ack (from > > > > what I've been told the ARM SoC maintainer usually dislike driver patches > > > > going through their tree without the driver subsystem maintainer ack). > > > > > > > > > Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > > > > > Thank you. > > > > > > Yes, thanks Greg. > > > > > > Laurent, I have v4 of these patches sitting in patchwork. > > > Would you like me to look at queuing them up as-is or > > > are you planning v5? > > > > I'm not planning for a v5, but there's another patch series ("[PATCH 00/16] > > sh-sci: Remove unnecessary fields from platform data") that is similarly > > organized as sh-sci / platform / sh-sci patches on top of this. Would you like > > me to reorganize the all the 45 patches in one big series with a single set of > > platform patches in-between two sets of sh-sci patches ? > > That sounds nice, thanks. > > To be clear, we are planning sh-sci -> soc -> sh-sci ? > > If so, I'll have a word with Olof (CCed) as he tends to want > to avoid such circular dependencies if possible. What are the platform changes in the middle that you need? -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
