From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Converting vrfb.c Date: Wed, 3 Oct 2012 11:41:50 -0700 Message-ID: <20121003184149.GG4840@atomide.com> References: <1348833847.2437.36.camel@deskari> <20120928150052.GA4840@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:48856 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964794Ab2JCSlx (ORCPT ); Wed, 3 Oct 2012 14:41:53 -0400 Content-Disposition: inline In-Reply-To: <20120928150052.GA4840@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tomi Valkeinen Cc: linux-omap , Paul Walmsley Hi, * Tony Lindgren [120928 08:02]: > * Tomi Valkeinen [120928 05:05]: > > Hi, > > > > I'm a bit at loss how to deal with drivers/video/omap2/vrfb.c. > > > > VRFB is part of the SDRAM controller on OMAP2 and OMAP3. vrfb.c uses the > > following functions from sdrc.h: > > > > omap2_sms_write_rot_control(); > > omap2_sms_write_rot_size(); > > omap2_sms_write_rot_physical_ba(); > > > > There are no other dependencies to the sdrc.c. > > > > Those functions are quite simple: > > > > void omap2_sms_write_rot_control(u32 val, unsigned ctx) > > { > > sms_write_reg(val, SMS_ROT_CONTROL(ctx)); > > } > > > > void omap2_sms_write_rot_size(u32 val, unsigned ctx) > > { > > sms_write_reg(val, SMS_ROT_SIZE(ctx)); > > } > > > > void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx) > > { > > sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx)); > > } > > > > vrfb.c is in turn used by omapfb and omap v4l2 driver. > > > > > > So... Should I just remove the sdrc.h dependency and make vrfb.c ioremap > > those SMS registers itself? Those three registers are VRFB specific, so > > they are not used by anyone else. In that case I'd need to pass the SMS > > base address to vrfb.c somehow. > > > > Or should I have some kind of platform data passed to vrfb.c, which > > contains func pointers to the above three functions? > > > > Or should vrfb.c be moved into mach-omap2/? But then how would omapfb > > call it? Passing vrfb functions as pointers in omapfb platform data? > > Maybe just export those functions in sdrc.c for now? Eventually > that should be just a regular device driver too.. Actually, if you're only using it to save and restore the hw context, why don't you let mach-omap2/sdrc.c do it based on runtime PM calls? It already has omap2_sms_save/restore_context. > Or maybe Paul has some better ideas? Regards, Tony