From: Chanwoo Choi <cw00.choi@samsung.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: sameo@linux.intel.com, myungjoo.ham@samsung.com,
kyungmin.park@samsung.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mfd: MAX77693: Fix bug of interrupt handlding for MAX77693 devices
Date: Wed, 18 Jul 2012 09:50:13 +0900 [thread overview]
Message-ID: <50060845.8090100@samsung.com> (raw)
In-Reply-To: <20120717191451.GK4477@opensource.wolfsonmicro.com>
On 07/18/2012 04:14 AM, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 08:30:17AM +0900, Chanwoo Choi wrote:
>> On 07/16/2012 10:36 PM, Mark Brown wrote:
>>> On Mon, Jul 16, 2012 at 06:41:05PM +0900, Chanwoo Choi wrote:
>
>>>> This patch fix bug related to interrupt handling for MAX77693 devices.
>>>> - Unmask interrupt masking bit for charger/flash/muic to revolve
>>>> that interrupt isn't happened when external connector is attached.
>
>>> Shouldn't this be happening when the IRQ is requested?
>
>> The interrupt isn't happened when external connector is attached
>> because muic interrupt of MAX77693 is masked on INTSRC_MASK(
>> Interrupt Source Mask) register. So, I should set zero to muic interrupt
>> masking bit of INTSRC_MASK before requesting IRQ.
>
> Right, but normally that unmasking happens in the unmask() callback of
> the irq_chip which is called when the interrupt is requested. Why isn't
> that working here?
As previous reply, Maxim MAX77693 has INTSRC_MASK(Interrput Source Mask,
0x23)
which mask or unmask Charger/Top/Flash/MUIC interrupt. And MAX77693 has
additional 'Interrupt Source Mask' for sub interrupt of each
Charger/Top/Flash/MUIC device.
In case of MUIC device, MUIC device has 16 sub interrupts and then MUIC
device need
separate Interrupt Source Mask(0x1,0x2,0x3) which is included in
register map of
MUIC i2c device and isn't equal to INTSRC_MASK(0x23). As you said,
unmasking sub interrupt of MUIC is happened in unmask() callback using
separate Interrupt Source Mask(0x1, 0x2, 0x3).
The MAX77693 mfd driver handle only INTSRC_MASK(0x23) to activate
Charger/Top/Flash/MUIC interrupt which isn't equal to sub interrupt of
each device before requesting
IRQ. If mfd driver wouldn't unmask Charger/Top/Flash/MUIC interrupt of
INTSRC_MASK(0x23),
it mean that Charger/Top/Flash/MUIC interrupt is inactive state and mfd
driver can't get the any interrupt.
Thank you,
Chanwoo Choi
prev parent reply other threads:[~2012-07-18 0:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-16 9:41 [PATCH] mfd: MAX77693: Fix bug of interrupt handlding for MAX77693 devices Chanwoo Choi
2012-07-16 13:36 ` Mark Brown
2012-07-16 23:30 ` Chanwoo Choi
2012-07-17 19:14 ` Mark Brown
2012-07-18 0:50 ` Chanwoo Choi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50060845.8090100@samsung.com \
--to=cw00.choi@samsung.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox