Add support for the Ingenic JZ4740 System-on-a-Chip
in [Kernel]
|
Prev: drivers/media/IR/imon.c: Use pr_err instead of err
Next: [PATCH] HID: Fixing offset errors in bin_attribute read functions of roccat kone
From: Lars-Peter Clausen on 20 Jun 2010 12:50 Thomas Bogendoerfer wrote: > On Sun, Jun 20, 2010 at 04:31:26PM +0200, Lars-Peter Clausen wrote: > >> Another issue with naming is that while a component might be similar in >> JZ4730 and JZ4740 it might be completely different in a different JZ47xx >> SoC. So naming a driver 'jz47xx_driver' instead of 'jz4740_driver' wont >> work either. >> > > so ? call it xx for the common part an exact number for special part. > It might be just jugglin with pieces, but getting it better in the first > run is always a plus. > > Thomas. > As I said, parts might be common between JZ4730 and JZ4740 but be different to JZ4750 and JZ4760. So JZ47xx wont fit either. Right now there is no practical use to moving things around, and there wont be until somebody who can actually test it starts adding support for a different JZ47XX SoC. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Fainelli on 20 Jun 2010 14:00 Hi, Le Sunday 20 June 2010 19:01:11, Thomas Bogendoerfer a �crit : > On Sun, Jun 20, 2010 at 06:49:01PM +0200, Lars-Peter Clausen wrote: > > different to JZ4750 and JZ4760. So JZ47xx wont fit either. > > Right now there is no practical use to moving things around, and there > > wont be until somebody who can actually test it starts adding support > > for a different JZ47XX SoC. > > great, I like such attitude:-( I have to agree with Thomas here, if your concern is about the naming, then just have a look at the vendor sources and find similarities for what is worth being named JZ47XX and what deserves a name which is more specific. Also, it is much easier to do that factoring job now instead of when there will be 3 or more flavors of that SoC to be supported. Take a look at BCM63xx for instance, it is named like that because it supports 4 different versions of the family SoC, even though the internals of the SoC have been varying a lot, still we support it with a single kernel and what is really family specific is named accordingly from what is chip-specific. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Lars-Peter Clausen on 20 Jun 2010 14:40 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Fainelli wrote: > Hi, > > Le Sunday 20 June 2010 19:01:11, Thomas Bogendoerfer a �crit : >> On Sun, Jun 20, 2010 at 06:49:01PM +0200, Lars-Peter Clausen wrote: >>> different to JZ4750 and JZ4760. So JZ47xx wont fit either. >>> Right now there is no practical use to moving things around, and there >>> wont be until somebody who can actually test it starts adding support >>> for a different JZ47XX SoC. >> great, I like such attitude:-( > > I have to agree with Thomas here, if your concern is about the naming, then > just have a look at the vendor sources and find similarities for what is worth > being named JZ47XX and what deserves a name which is more specific. Also, it is > much easier to do that factoring job now instead of when there will be 3 or > more flavors of that SoC to be supported. Well, it's not like somebody who wants to add support for e.g. JZ4730 would start from scratch and add a complete implementation which then has to be merged with JZ4740. You would start adding it on-top of the existing JZ4740 platform support and generalize it where necessary. Renaming is cheap! This is not part of an API thats set into stone... Seriously, it doesn't make any sense to waste time and try to generalize now while it is uncertain if there will be support of a different JZ47xx SoC anytime soon. Furthermore the likelihood of over- or under-generalizing is pretty high if you do not know exactly what you want or what you need. I strongly disagree that it is easier to do the factoring job now. It will be easier when you actually know what requirements you'll have based on hard facts instead of having some loose ideas of what might work and what not. That said, the platform support has been designed with having the idea of support for multiple JZ47XX SoCs at some point. So it will mostly be picking up the components shared between different SoCs and put them in a shared folder (and maybe do a 's/jz4740/jz47xx/g'). But right now there is only JZ4740 support... - - Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkweXl0ACgkQBX4mSR26RiM7hACfRMhD54TJEdI11AgsaaWRiDaK xrYAnRR+0VT3CurJm2Xc9DgC9+bcrFfv =SFR2 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Xiangfu Liu on 20 Jun 2010 23:00
On 06/20/2010 05:26 PM, Thomas Bogendoerfer wrote: > great stuff. I have a JZ4730 based netbook, for which I started magling > the provided sources quite some time ago, but I didn't reach the > point of submitting patches... there are a lot of common stuff between > JZ4730 and JZ4740 so IMHO it would be a good thing not to nail > everthing to JZ4740 namewise. It might also a good idea to select > something like arch/mips/jzrisc as base directory, put the Hi Thomas I would advice "xburst" instead jzrisc. because the Ingenic call their cpu "XBurst" series. like: XBurst JZ4740, XBurst JZ4750 ... > factored out code there and add JZ4730/JZ4740 in either seperate > files or directories. -- Best Regards Xiangfu Liu http://www.openmobilefree.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |