[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM2zO=BJkSTe1p+cGh++4T14G1ZUMJJnRbUDysoWaDUb_QF4UA@mail.gmail.com>
Date: Wed, 14 Sep 2011 17:15:14 +0800
From: Yong Zhang <yong.zhang0@...il.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: Clemens Ladisch <clemens@...isch.de>, linux-kernel@...r.kernel.org,
Jaroslav Kysela <perex@...ex.cz>, alsa-devel@...a-project.org
Subject: Re: [RFC] [PATCH 02/62] mpu401:snd_mpu401_uart_new(): split semantic
of irq_flags
On Wed, Sep 14, 2011 at 5:06 PM, Takashi Iwai <tiwai@...e.de> wrote:
> At Wed, 14 Sep 2011 16:49:57 +0800,
> Yong Zhang wrote:
>>
>> On Tue, Sep 13, 2011 at 11:24:41AM +0200, Clemens Ladisch wrote:
>> [snip]
>> >
>> > completely untested:
>> >
>> > --8<---------------------------------------------------------------->8--
>> > ALSA: mpu401: clean up interrupt specification
>> >
>> > The semantics of snd_mpu401_uart_new()'s interrupt parameters are
>> > somewhat counterintuitive: To prevent the function from allocating its
>> > own interrupt, either the irq number must be invalid, or the irq_flags
>> > parameter must be zero. At the same time, the irq parameter being
>> > invalid specifies that the mpu401 code has to work without an interrupt
>> > allocated by the caller. This implies that, if there is an interrupt
>> > and it is allocated by the caller, the irq parameter must be set to
>> > a valid-looking number which then isn't actually used.
>> >
>> > With the removal of IRQF_DISABLED, zero becomes a valid irq_flags value,
>> > which forces us to handle the parameters differently.
>> >
>> > This patch introduces a new flag MPU401_INFO_IRQ_HOOK for when the
>> > device interrupt is handled by the caller, and makes the allocation of
>> > the interrupt to depend only on the irq parameter. As suggested by
>> > Takashi, the irq_flags parameter was dropped because, when used, it had
>> > the constant value IRQF_DISABLED.
>>
>> Thanks Clemens. Your patch will eventually save much lines from mine ,
>> actually I only need to touch request_irq() in snd_mpu401_uart_new().
>>
>> But do you have any idea by which tree this patch will go to mainline?
>> Thus I could make a new patch based on it :)
>
> I applied Clemens' patch now to sound git tree.
> The temporary location is:
> git://github.com/tiwai/sound.git
>
> In general, such cross-tree patches should be based on linux-next,
> which should contain the latest subsystem tree. But as kernel.org is
> down now, you can check each subsystem tree.
Thanks for your guide, Takashi !
Will refresh my patch based on that.
Thanks,
Yong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists