hwmod and insertable modules

hwmod and insertable modules

[Premi, Sanjeev]

Hi all,

I was trying to use hwmod in one of the modules that user could choose
to insert via insmod.

During module_init I used omap_device_build() to create the omap_device.
But when trying to implement the module_exit, I couldn't find the
corresponding 'destructor'.

I do see 4 kzalloc()s being called for each omap_device_build(). I do
have a half-implemented destructor; but before I proceeded ahead I
wanted to pose few questions which can help undertand if I am on a
good track:

1) Is the omap_device supposed to be persistent? i.e. subsequent
   calls will return me the same device object?

2) Has someone else tried to to use omap_device and done multiple
   insmod and rmmod operations?

3) Is my fear of memory leak real? OR there is some magic behind
   omap_device_shutdown() that I haven't yet discovered? 

Best regards,
Sanjeev

RE: hwmod and insertable modules

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, October 22, 2010 2:43 PM
> To: linux-omap@vger.kernel.org
> Subject: hwmod and insertable modules
> 
> Hi all,
> 
> I was trying to use hwmod in one of the modules that user could choose
> to insert via insmod.
> 
> During module_init I used omap_device_build() to create the 
> omap_device.
> But when trying to implement the module_exit, I couldn't find the
> corresponding 'destructor'.
> 
> I do see 4 kzalloc()s being called for each omap_device_build(). I do
> have a half-implemented destructor; but before I proceeded ahead I
> wanted to pose few questions which can help undertand if I am on a
> good track:
> 
> 1) Is the omap_device supposed to be persistent? i.e. subsequent
>    calls will return me the same device object?
> 
> 2) Has someone else tried to to use omap_device and done multiple
>    insmod and rmmod operations?
> 
> 3) Is my fear of memory leak real? OR there is some magic behind
>    omap_device_shutdown() that I haven't yet discovered? 
> 
> Best regards,
> Sanjeev

Forgot to add the destructor I had implemented - not yet tested.

void omap_device_destroy(struct omap_device *od)
{
	if (!od)
		return ERR_PTR(-EINVAL);

	kfree(od->pdev.name);
	kfree(od->pdev.resource);
	kfree(od->hwmods);
	kfree(od);
}

--
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: hwmod and insertable modules

[Nayak, Rajendra]

Sanjeev,

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, October 22, 2010 2:43 PM
> To: linux-omap@vger.kernel.org
> Subject: hwmod and insertable modules
> 
> Hi all,
> 
> I was trying to use hwmod in one of the modules that user could choose
> to insert via insmod.
> 
> During module_init I used omap_device_build() to create the omap_device.
> But when trying to implement the module_exit, I couldn't find the
> corresponding 'destructor'.

omap_device_build essentially does  a platform_device register today
and hence its not something to be done from a insmod'able 'driver'.

Device registrations should happen only once from a board file or some
other place appropriate. The insmod'able driver can then be inserted
and rmmoded as many times without removing the device registration.

Regards,
Rajendra

> 
> I do see 4 kzalloc()s being called for each omap_device_build(). I do
> have a half-implemented destructor; but before I proceeded ahead I
> wanted to pose few questions which can help undertand if I am on a
> good track:
> 
> 1) Is the omap_device supposed to be persistent? i.e. subsequent
>    calls will return me the same device object?
> 
> 2) Has someone else tried to to use omap_device and done multiple
>    insmod and rmmod operations?
> 
> 3) Is my fear of memory leak real? OR there is some magic behind
>    omap_device_shutdown() that I haven't yet discovered?
> 
> Best regards,
> Sanjeev--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: hwmod and insertable modules

[Premi, Sanjeev]

> -----Original Message-----
> From: Nayak, Rajendra 
> Sent: Friday, October 22, 2010 3:08 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: hwmod and insertable modules
> 
> Sanjeev,
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Premi, Sanjeev
> > Sent: Friday, October 22, 2010 2:43 PM
> > To: linux-omap@vger.kernel.org
> > Subject: hwmod and insertable modules
> > 
> > Hi all,
> > 
> > I was trying to use hwmod in one of the modules that user 
> could choose
> > to insert via insmod.
> > 
> > During module_init I used omap_device_build() to create the 
> omap_device.
> > But when trying to implement the module_exit, I couldn't find the
> > corresponding 'destructor'.
> 
> omap_device_build essentially does  a platform_device register today
> and hence its not something to be done from a insmod'able 'driver'.

[sp] How does this work for - say dspbridge - where the DSP as device
may not be 'registered' until it is really expected to be used?

> 
> Device registrations should happen only once from a board file or some
> other place appropriate. The insmod'able driver can then be inserted
> and rmmoded as many times without removing the device registration.
> 
> Regards,
> Rajendra
> 
> > 
> > I do see 4 kzalloc()s being called for each 
> omap_device_build(). I do
> > have a half-implemented destructor; but before I proceeded ahead I
> > wanted to pose few questions which can help undertand if I am on a
> > good track:
> > 
> > 1) Is the omap_device supposed to be persistent? i.e. subsequent
> >    calls will return me the same device object?
> > 
> > 2) Has someone else tried to to use omap_device and done multiple
> >    insmod and rmmod operations?
> > 
> > 3) Is my fear of memory leak real? OR there is some magic behind
> >    omap_device_shutdown() that I haven't yet discovered?
> > 
> > Best regards,
> > Sanjeev--
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: hwmod and insertable modules

[Nishanth Menon]

Premi, Sanjeev had written, on 10/22/2010 04:41 AM, the following:

>>> During module_init I used omap_device_build() to create the 
>> omap_device.
>>> But when trying to implement the module_exit, I couldn't find the
>>> corresponding 'destructor'.
>> omap_device_build essentially does  a platform_device register today
>> and hence its not something to be done from a insmod'able 'driver'.
> 
> [sp] How does this work for - say dspbridge - where the DSP as device
> may not be 'registered' until it is really expected to be used?
> 
arch/arm/mach-omap2/dspbridge.c? ;)

-- 
Regards,
Nishanth Menon

RE: hwmod and insertable modules

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Friday, October 22, 2010 3:14 PM
> To: Premi, Sanjeev
> Cc: Nayak, Rajendra; linux-omap@vger.kernel.org
> Subject: Re: hwmod and insertable modules
> 
> Premi, Sanjeev had written, on 10/22/2010 04:41 AM, the following:
> 
> >>> During module_init I used omap_device_build() to create the 
> >> omap_device.
> >>> But when trying to implement the module_exit, I couldn't find the
> >>> corresponding 'destructor'.
> >> omap_device_build essentially does  a platform_device 
> register today
> >> and hence its not something to be done from a insmod'able 'driver'.
> > 
> > [sp] How does this work for - say dspbridge - where the DSP 
> as device
> > may not be 'registered' until it is really expected to be used?
> > 
> arch/arm/mach-omap2/dspbridge.c? ;)

Which repo? On the dspbridge branch on linux-omap, there is not such
file... and dsp.c doesn't seem to be using hwmod; and module_exit
does call platform_device_unregister().
I didn't find any function in omap_device.c that calls/leads to
platform_device_unregister().

This is exactly where I decided to post my query before putting more
effort in the function snippet I posted earlier.

> 
> -- 
> Regards,
> Nishanth Menon
> 

Re: hwmod and insertable modules

[Nishanth Menon]

Premi, Sanjeev had written, on 10/22/2010 05:01 AM, the following:

>>>>> During module_init I used omap_device_build() to create the 
>>>> omap_device.
>>>>> But when trying to implement the module_exit, I couldn't find the
>>>>> corresponding 'destructor'.
>>>> omap_device_build essentially does  a platform_device 
>> register today
>>>> and hence its not something to be done from a insmod'able 'driver'.
>>> [sp] How does this work for - say dspbridge - where the DSP 
>> as device
>>> may not be 'registered' until it is really expected to be used?
>>>
>> arch/arm/mach-omap2/dspbridge.c? ;)
> 
> Which repo? On the dspbridge branch on linux-omap, there is not such
:) it is not there as dspbridge is in staging at the moment - I believe 
there is some sort of rule of not depending on staging drivers or 
something like that.. but the point I was attempting to make is backing 
Rajendra's statement -> split your driver into silicon specific data and 
silicon independent driver -> the silicon dependent data (like hwmod) 
can be collected by a file located in arch/arm/mach-omap2 -> pass the 
data as platform_data(with stuff like baseaddress etc..) to the driver 
and things can happily function.. Would suggest posting out a RFC patch 
if you'd like better ideas from the community I guess.

-- 
Regards,
Nishanth Menon

RE: hwmod and insertable modules

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Friday, October 22, 2010 3:56 PM
> To: Premi, Sanjeev
> Cc: Nayak, Rajendra; linux-omap@vger.kernel.org
> Subject: Re: hwmod and insertable modules
> 
> Premi, Sanjeev had written, on 10/22/2010 05:01 AM, the following:
> 
> >>>>> During module_init I used omap_device_build() to create the 
> >>>> omap_device.
> >>>>> But when trying to implement the module_exit, I 
> couldn't find the
> >>>>> corresponding 'destructor'.
> >>>> omap_device_build essentially does  a platform_device 
> >> register today
> >>>> and hence its not something to be done from a 
> insmod'able 'driver'.
> >>> [sp] How does this work for - say dspbridge - where the DSP 
> >> as device
> >>> may not be 'registered' until it is really expected to be used?
> >>>
> >> arch/arm/mach-omap2/dspbridge.c? ;)
> > 
> > Which repo? On the dspbridge branch on linux-omap, there is not such
> :) it is not there as dspbridge is in staging at the moment - 
> I believe 
> there is some sort of rule of not depending on staging drivers or 
> something like that.. but the point I was attempting to make 
> is backing 
> Rajendra's statement -> split your driver into silicon 
> specific data and 
> silicon independent driver -> the silicon dependent data (like hwmod) 
> can be collected by a file located in arch/arm/mach-omap2 -> pass the

I am not really concerned for location of the file - but intent of the
original query was to understand if we ever thought of antonym of
omap_device_build() OR if it did come for discussion if there was an
accepted disposition.

> data as platform_data(with stuff like baseaddress etc..) to 
> the driver 
> and things can happily function... Would suggest posting out a 
> RFC patch 
> if you'd like better ideas from the community I guess.

I was trying other way - understand if there is an existing norm/
convention that I can follow - rather than (re)invent it!

Based on discussion so far, I will definitely have an RFC.

> 
> -- 
> Regards,
> Nishanth Menon
> 

Re: hwmod and insertable modules

[Kevin Hilman]

"Premi, Sanjeev" <premi@ti.com> writes:

> I was trying other way - understand if there is an existing norm/
> convention that I can follow - rather than (re)invent it!

The existing norm is that omap_devices are never destroyed.  The same is
true for the way we handle platform_devices that are not omap_devices.
That being said, it doesn't answer the question of how we would destroy
them if we wanted to, and that does indeed deserve some discussion.

However, I think your confusion is more about the separation between
device code and driver code.

It is the responsibility of device init code (arch/arm/*omap*) to create
and register devices with the system.  This is where platform_devices
and omap_devices are handled currently.

The drivers then register themselves (as platform_drivers) with the
driver core, and the driver core hooks them together.

The goal we're working towards is that the drivers be generic, and
should not know anything about device-specific registration.

Kevin