On 11/18/14 09:45, James Hogan wrote:
On 18/11/14 00:26, Andrew Bresticker wrote:
Hi Naidu,
On Mon, Nov 17, 2014 at 4:12 PM, Naidu Tellapati
<Naidu.Tellapati@xxxxxxxxxx> wrote:
Hi Andrew,
(We will respond to James Hogan's remaining review comments in a separate email)
+obj-$(CONFIG_SOC_IMG) += pistachio/
What is CONFIG_SOC_IMG? It sounds very generic.
May I have your suggestions on the above.
(Assuming we create drivers/soc/img/ instead of drivers/soc/pistachio/)
What would "belong" in there?
Basically anything that doesn't belong in some particular subsystem?
I don't have much visibility into ImgTec SoCs other than Pistachio,
but I think introducing a SOC_IMG Kconfig symbol is a good idea as it
gives drivers for various pieces of IP present on ImgTec SoCs
(watchdog, I2C, DMA, etc.) a more specific dependency than say MIPS or
METAG. Maybe James has a suggestion for how to deal with this?
I have very limited experience with IMG based SoCs other than Chorus2
and TZ1090, but I'm not convinced an SOC_IMG adds any value tbh if it is
simply a way to group drivers. Both SOC_IMG and METAG || MIPS would end
up being fuzzy/inexact convenience dependencies to reduce clutter on
other platforms, so perhaps it would be best kept simple, flexible and
easily understandable. I don't feel strongly about it either way though.
I suspect certain IP blocks may potentially get licensed separately and
require exceptions (PDP springs to mind?), so it probably is technically
a per-IP block thing. James Hartley might have a better idea about that.
Cheers
James
I think there is value in keeping the clutter down in the kernel config,
so if there is already precedent for using a symbol such as IMG_SOC then
I don't see a strong reason not to do it. IP blocks present in
pistachio may also be used in other (non MIPS or META) SoCs, so provided
it is acceptable to expect other SoC providers to add their own symbols
when required I think we should go ahead with it.
James.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
