lkml.org 
[lkml]   [2009]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core
    Date
    On Thursday 22 October 2009 02:13:11 ext Samuel Ortiz wrote:
    > As Mark noticed already, you dont really want users to explicitely select
    > this obscure mfd driver to get their audio and vibre driver selectable. It
    > should be the other way around, and I think you already agreed with that.

    Yes, I have already made the modification.

    >
    > > +static struct device *
    > > +twl4030_codec_new_child(const char *name, void *pdata, unsigned
    > > pdata_len) +{

    ...

    > This could really use the mfd-core API, and avoid duplicating code.
    > You just would have to define a couple cells, and call mfd_add_devices on
    > them.

    Good point. When I wrote this driver I have been looking at the twl4030-core
    driver, which is not using the mfd-core API. I'll make the change.

    >
    > > +static int __devexit twl4030_codec_remove(struct platform_device *pdev)
    > > +{
    > > + struct twl4030_codec *codec = platform_get_drvdata(pdev);
    > > +
    > > + platform_set_drvdata(pdev, NULL);
    > > + kfree(codec);
    > > + twl4030_codec_dev = NULL;
    > > +
    > > + return 0;
    > > +}
    >
    > I think you're missing a platform_device_unregister() here (or an
    > mfd_remove_devices() if you're going to switch to the mfd-core API)

    You are right, although I have used the bool in the Kconfig for the twl4030-
    codec in a same way as the twl4030-core (and the core did not unregister the
    devices either), but yes, this is not correct so I'll fix it.

    I have now question about the practicalities on how this series would be taken,
    and via which tree.
    The final patch for the soc codec driver depends on the change in MFD and in the
    OMAP board files.
    The change in the OMAP board files depends on the MFD changes, obviously.

    So in order to have the soc codec changes the MFD and OMAP part has to be
    applied before, otherwise the audio will be broken.

    the mfd-2.6:for-next branch has some patches against the twl4030-core in
    addition to the ones in l-o and in sound-2.6:topic/asoc.

    I'll check, if the MFD patch applies to mfd-2.6:for-next also, but to have the
    soc codec changes the MFD patch should go to the sound-2.6 tree as well to make
    sure it is not braking things.

    All-in-all, how these things can be handled?

    Thanks,
    Péter
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-10-22 08:07    [W:2.043 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site