On Fri, 2012-03-30 at 14:02 +0200, Cousson, Benoit wrote: > On 3/30/2012 1:59 PM, Tomi Valkeinen wrote: > > On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote: > > > >> Exactly. That's what I mean. You tweak sysconfig or clockdomain, > >> both are messy. > >> > >> if one need to choose between two bad options, I guess sysconifig > >> one is better because that is local to IPs and there is some way today > >> for drivers to manage sysconfig directly. > > > > If the driver touches sysconfig, isn't it possible that hwmod/something > > just reverts the changes? I mean, sysconfig register is supposedly > > "owned" by the arch code, and if the driver modifies it there could be a > > race condition. > > No because we had to expose API from hwmod core code to do that already > because of various HW bugs. > So you will not access it directly but through the hwmod API. Ah. What functions would be needed to solve this case? > The only issue is that these API are exposed today through pdata > function pointers, and thus this is not usable in a DT case :-( That's ok (for now), we will anyway have this "omapdss" higer level driver, which is not HW driver (i.e. not mentioned in the DT data), but created in arch/arm code. I have put all the current function pointers there already, so I can add a few more. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
