> -----Original Message----- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Wednesday, February 09, 2011 9:30 PM > To: Vishwanath Sripathy > Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath > Subject: Re: [PATCH 03/13] OMAP: Implement Basic DVFS > > Vishwanath Sripathy <vishwanath...@ti.com> writes: > > >> This needs a comment to, but I'm not sure I understand what's going > on > >> here. What it seems like: > >> > >> if this device has no OPP for this voltage, just silently move on to the > >> next device? doesn't seem quite right, but not sure I fully grok the > >> failure modes of omap_dvfs_find_voltage() > > > > Yes, your understanding is right. omap_dvfs_find_voltage will return > error > > if the device does not have an OPP table. > > Typically devices should not register with a vdd (using > > omap_dvfs_register_device) if it has no OPP table associated with it. > So > > ideally we should not hit this error case. But only exception so far is SR > > driver. SR hwmod has vdd_name field set so as to get voltagedomain > > pointers. But SR does not have any opp table. So there is no harm in > > ignoring the error and moving to next device. > > And what happens when other devices add voltage domains but don't > have > OPP tables? If someone does not have a OPP table, that means it's not a scalable device, so there is no need to scale that device.
Vishwa > > The point is that this error handling is 1) difficult to understand upon > first (or fifth) read and 2) very fragile with other changes. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
