Hi, On Wednesday, June 18 2014, Lee Jones wrote: > On Tue, 17 Jun 2014, Tomasz Figa wrote: > > On 17.06.2014 17:42, Arnd Bergmann wrote: > > > On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote: > > >> Currently a syscon entity can be only registered directly through a > > >> platform device that binds to a dedicated driver. However in > > >> certain use cases it is desirable to make a device used with > > >> another driver a syscon interface provider. For example, certain > > >> SoCs (e.g. Exynos) contain system controller blocks which perform > > >> various functions such as power domain control, CPU power > > >> management, low power mode control, but in addition contain certain > > >> IP integration glue, such as various signal masks, coprocessor > > >> power control, etc. In such case, there is a need to have a > > >> dedicated driver for such system controller but also share > > >> registers with other drivers. The latter is where the syscon interface is helpful. > > >> > > >> This patch decouples syscon object from syscon driver, so that it > > >> can be registered from any driver in addition to the original > > >> "syscon" platform driver. > > +1 for this approach. > > Michal, Pankay, > Does it also suit your needs? > Sorry for late reply. I tested this patch after changing exynos PMU to be a syscon provider and it's working well. So if we can address Arnd's comments, this patch will be helpful in making exynos PMU a complete platform driver. Thanks, Pankaj Dubey > > >> Signed-off-by: Tomasz Figa <t.figa@xxxxxxxxxxx> > > > > > > Hi Tomasz, > > > > > > This seems like a reasonable way of solving the problem, but I think > > > there is an even better one that we have about in the past: if we > > > promote syscon from a platform driver into a a drivers/base/ helper > > > that is independent of the platform device matching, we can use call > > > syscon_regmap_lookup_* for any device node, whether it's already > > > bound to a driver or not, which do what you need. It would also make > > > it easier to call the syscon code before the platform_device > > > infrastructure gets initialized, which is something a number of > > > people have asked for, e.g. for using regmap to do SMP bringup or > > > for clock registration. > > > > Basically, unless I'm missing your point, this is what my patch does, > > except that I don't move it to drivers/base/ and the registration > > function I added require a pointer to struct device. Indeed, > > decoupling it further from the driver model, by adding > > of_syscon_register() should be useful for early users. > > If agreed by Arnd, I think this work can be completed as a subsequent patch. > > > Should I move this to drivers/base/, even though from current location > > it can be used outside the platform driver anyway? > > If I'm being honest with myself, I'd say that Syscon wasn't really an MFD driver. I'm > happy to keep it in there any continue maintaining it, but wouldn't block a move > either. > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software > for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |