Converting vrfb.c

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?

Quoted 38 lines · Tomi Valkeinen

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.

Quoted 5 lines

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..

Or maybe Paul has some better ideas?

Hi,

Quoted 45 lines · Tony Lindgren

Quoted 43 lines · Tomi Valkeinen

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?

Quoted 2 lines

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.

Quoted 51 lines · Tony Lindgren

Hi,

Quoted 47 lines · Tony Lindgren

Quoted 38 lines · Tomi Valkeinen

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.

Quoted 5 lines

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..

Quoted 3 lines

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.

No, the functions are used to configure the rotation parameters whenever the user asks for a new rotation.