Hello, On Friday, December 10, 2010 1:01 PM Sylwester Nawrocki wrote: > On 2010-12-10 10:12, Marek Szyprowski wrote: > > On Friday, December 10, 2010 6:14 AM Kukjin Kim wrote: > >> Sylwester Nawrocki wrote: > >>> > >>> MIPI DPHY control register requires special handling since it is shared > >>> between CSI (camera serial interface) and DSI (display serial interface). > >>> By creating this clock a serialized interface is provided for mipi-csis > >>> and mipi-dsim drivers, so DPHYs may be safely controlled by both drivers. > >>> Similarly dsim_dphy clock could be added for mipi-dsim. > >>> > >>> --- > >>> > >>> I am not quite sure about_"dphy_clock", perhaps power domain > >>> handling code would be better place for it. > >>> > >> Yeah, it is MIPI DPHY enable/disable control register not clock control. > >> So its proper position is not here... > >> > >> Hmm...how about driver's probe/open or some kind of setup in machine > >> directory? > > > > I'm not sure that this is the best way of handling this phy controller. Please > > notice that mipi phy controller has different register location on S5PC110 and > > S5PC210. Please also notice that S5PC210 has 2 mipi csci controllers and phy > > interfaces, while s5pc110 has only one. Hiding all the logic and register > > specific writes behind this 'csi_dphy' clock easily resolves all these issues > > on all different samsung platforms and makes it easy to use it from the driver. > > Similar patch has been proposed some time ago for usb_phy interface and imho > > this is the right way to go. > > > More importantly S5P_MIPI_DPHY_CONTROL* register is shared between two > devices - MIPI-CSIS and MIPI-DSIM. It means some kind of serialization > mechanism need to be employed while accessing this register, a spinlock > seems to fit best here. It also means that if we decided to create the > platform callback such a code would have to be placed in a common > compilation unit which would be built when either mipi-csis or mipi-dsim > is selected. And this callback would have to account the differences > between various SoC flavours or it would have to be repeated for each > mach-s5pvXXX. > So if the platform callback is the preferred way, where do we put an > implementation of it? That's yet another advantage of clock-based approach. All clock related operations are automatically serialized by global clock API spinlock. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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
 |