>-----Original Message----- >From: Anand Gadiyar [mailto:gadiyar@xxxxxx] >Sent: Saturday, January 29, 2011 2:19 AM >To: Sricharan R; linux-omap@xxxxxxxxxxxxxxx >Cc: Santosh Shilimkar; tony@xxxxxxxxxxx; paul@xxxxxxxxx >Subject: RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as >static and dynamic. > >sricharan wrote: >> >> 1) All the pads of a hwmod for the device are classified >> as static/dynamic. If a pad requires remuxing during >> the device transitions between enable/idle transitions >> then it is added to the dynamic list, static otherwise. >> >> 2) Both the static/dynamic pads of a hwmod are initialised >> when the device gets enabled. When the device transitions >> between enable/idle the dynamic pads are remuxed and >> static pads are skipped. >> >> 3) When the driver gets removed both the static and the >> dynamic pads are muxed to safe mode as default. >> > >I haven't taken a look at the code. I do have a few >concerns (which may really be non-issues, but I'm >pointing them out anyway): > >- Not all pads have a safe mode. >--- And why would you want statically muxed pads to be remuxed >into safe mode anyway? What is the advantage of such a change, >as against leaving them in a functional mode? There is an option to mux the pads to different mode than safe mode when the driver is removed. Those which do not specify are put to safe mode. With safe mode, the pins becomes a input with no functional interface connected to it. This avoids the either omap or outside device seeing any false logic from the pin. > >- Many signals are muxed on more than one pad. >- Many peripherals need pads to be configured in different > mux modes depending on the way a board is wired up. > > >With this, moving pad info to hwmod databases does not sound >useful to me. Maybe I do not understand the need for this >change, in place of what we have today. > The structure for containing the mux data is part of hwmod for the device. The hwmod is not static and it is dynamically populated during the device init, with the data being passed from board files if it is different across boards. The device state transitions (enable/idle) passes the through the hwmod layer, which takes caring of muxing the pins right way for each transition. This helps to mux correctly the 1) shared pins 2) Initialsing the pads 3) Remux only pads that require change during enable/idle transitions. 4) Put the pads to safemode( default) when the driver is unplugged. >- Anand -- 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
