"Varadarajan, Charulatha" <charu@xxxxxx> writes: >> >> >> -----Original Message----- >> >> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >> >> Sent: Saturday, May 01, 2010 5:34 AM >> >> To: Varadarajan, Charulatha >> >> Cc: linux-omap@xxxxxxxxxxxxxxx; Nayak, Rajendra; paul@xxxxxxxxx; >> tony@xxxxxxxxxxx >> >> Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device >> >> > [...] >> >> > >> >> > +static int init_gpio_info(void) >> >> > +{ >> >> > + gpio_bank_bits = 32; >> >> > + >> >> > + if (cpu_is_omap15xx()) { >> >> > + gpio_bank_count = 2; >> >> > + gpio_bank_bits = 16; >> >> > + } else if (cpu_is_omap16xx()) { >> >> > + gpio_bank_count = 5; >> >> > + gpio_bank_bits = 16; >> >> > + } else if (cpu_is_omap7xx()) >> >> > + gpio_bank_count = 7; >> >> > + else if (cpu_is_omap242x()) >> >> > + gpio_bank_count = 4; >> >> > + else if (cpu_is_omap243x()) >> >> > + gpio_bank_count = 5; >> >> > + else if (cpu_is_omap34xx() || cpu_is_omap44xx()) >> >> > + gpio_bank_count = OMAP34XX_NR_GPIOS; >> >> >> >> Both the bank count and bank bits could be part of platform_data >> >> and set in the SoC specific init. This is the GPIO driver part >> >> and we're trying to make this as SoC independent as possible. Anytime >> >> you need to add a cpu_is* or #ifdef in this code indicates something >> >> that should be part of SoC specific init and passed in. >> > >> > bank count and bank bits are not specific to each device, but SoC specific. >> > Hence I did not consider passing it as part of platform_data, because this >> information would be duplicated across all devices in that SoC. >> > >> > It would be good if we have a way to pass the SoC specific data which is >> > common for all the devices rather than duplicating them by sending them via >> > platform_data. >> > >> > Anyways, I can move it to platform_data if there is no other way. >> >> Probably the right place for the SoC specifics is attached to the SoC >> specific hwmod using the dev_attr pointer. That struct can then >> be passed in via platform_data. >> >> You can see how Thara did this for SmartReflex as an example. >> > > Using dev_attr for OMAP2PLUS is fine. How about OMAP1? > 1. To be implemented in a uniform way, may I get this info as > part of platform_data? > 2. Use dev_attr for OMAP2PLUS and use platform_data for OMAP1? Not sure I understand the question. You should be able to use a dev_attr struct in OMAP1 and OMAP2+, as there is technically nothing hwmod specific in the dev_attr. It is attached to the hwmod as a 'void *' and should be passed into the driver as the platform_data. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
