Re: [PATCH v4 3/6] drivers:staging: ti-st: fmdrv_common sources

[halli manjunatha <manjunatha_halli@ti.com>]

Hans,

On Thu, Nov 18, 2010 at 1:49 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> >
> > These are the sources for the common interfaces required by the FM
> > V4L2 driver for TI WL127x and WL128x chips.
> >
<snip...>
>
> OK, I think the way interrupts are handled should be revamped. It is way too
> complex IMHO. All these action/response handlers have a similar structure,
> particularly for the response handlers as this part of the code is the same
> for all as far as I can tell:
>
>        del_timer(&fmdev->irq_info.int_timeout_timer);
>
>        ret = __check_cmdresp_status(fmdev, &skb);
>        if (ret < 0) {
>                pr_err("(fmdrv): Initiating irq recovery process\n");
>                mod_timer(&fmdev->irq_info.int_timeout_timer, jiffies +
>                          FM_DRV_TX_TIMEOUT);
>                return;
>        }
>
> What I think should happen is that rather than having each handler chain the
> other there is one core handler that is taking care of that. So the boilerplate
> code is in that core handler and it is calling the other handlers. So e.g. the
> hw_malfunction handler below could become something like this:
>
> static int fm_irq_handle_hw_malfunction(struct fmdrv_ops *fmdev, unsigned events)
> {
>        if (!(events & FM_MAL_EVENT))
>                pr_err("(fmdrv): irq: HW MAL int received - do nothing\n");
>        return FM_RDS_START_INDEX;
> }
>
> And unsigned events is set to fmdev->irq_info.flag & fmdev->irq_info.mask.
>
> This would refactor out a lot of code.

I tried out similar ways of handling interrupts and also tried out
having a single unified
interrupt handler/core handler and branching out onto various handlers
based on the
events received.
However, the way chip tends to send interrupts is slightly more complex here.

We have cases where 2 or more events are combined together which would
cause the FM interrupt, So when I do a FLAG_GET to request the cause
of interrupt, I will have to always check for each of the individual
bits (13 bits...)
More over when a bit is set say, RDS, and I am in the middle of doing
a GET_RDS, I have more interrupts coming in, which requires me to do a
FLAG_GET (generally a lot of low rssi, stereo/mono events..)

So at the moment all we can do is push the following into a function
and thereby reduce a bit of code size - But not complexity.

>        del_timer(&fmdev->irq_info.int_timeout_timer);
>
>        ret = __check_cmdresp_status(fmdev, &skb);
>        if (ret < 0) {
>                pr_err("(fmdrv): Initiating irq recovery process\n");
>                mod_timer(&fmdev->irq_info.int_timeout_timer, jiffies +
>                          FM_DRV_TX_TIMEOUT);
>                return;
>        }

So, Please suggest on how best such situation where multiple events
have caused 1 interrupt
can be handled ?

example:
After checking HW_MAL function, I begin to check for RDS - this is
where the handler branches out,

check hw malfunction
    |
check rds-----------------
    |                          |
  <true>               <false>--- check for tune_op_ended ---- check
for Tx power enabled
    |
send rds get command
    |
rds data response
    |
rds finish ------------ check for tune_op_ended.------- check for Tx
power enabled...

regards,
Manjunatha,

> > +static void fm_irq_handle_hw_malfunction(void *arg)
> > +{
> > +     struct fmdrv_ops *fmdev;
> > +
> > +     fmdev = arg;
> > +     if (fmdev->irq_info.flag & FM_MAL_EVENT & fmdev->irq_info.mask)
> > +             pr_err("(fmdrv): irq: HW MAL int received - do nothing\n");
> > +
> > +     /* Continue next function in interrupt handler table */
> > +     fmdev->irq_info.stage_index = FM_RDS_START_INDEX;
> > +     fmdev->irq_info.fm_int_handlers[fmdev->irq_info.stage_index](fmdev);
> > +}
>
> Regards,
>
>        Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by Cisco
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html