From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Laxman Dewangan <ldewangan@nvidia.com>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>,
lee.jones@linaro.org, alexandre.belloni@free-electrons.com
Cc: cw00.choi@samsung.com, linux-kernel@vger.kernel.org,
rtc-linux@googlegroups.com
Subject: [rtc-linux] Re: [PATCH V3 5/5] rtc: max77686: move initialisation of rtc regmap, irq chip locally
Date: Thu, 4 Feb 2016 14:35:24 -0300 [thread overview]
Message-ID: <56B38BDC.8070706@osg.samsung.com> (raw)
In-Reply-To: <56B3242E.1060504@nvidia.com>
Hello Laxman,
On 02/04/2016 07:13 AM, Laxman Dewangan wrote:
>
> On Thursday 04 February 2016 02:38 PM, Krzysztof Kozlowski wrote:
>> On 04.02.2016 15:58, Krzysztof Kozlowski wrote:
>>> On 04.02.2016 11:03, Laxman Dewangan wrote:
>>>> 3. Can you try locally to not use devm_regmap_init_i2c() and just use
>>>> the regmap_init_i2c() and proper removal of this from error path and
>>>> remove callback?
>>> I'll try to find some time for that. Maybe tomorrow.
>> regmap_init_i2c does not help. However helps commenting out the:
>> regmap_del_irq_chip(info->rtc_irq, info->rtc_irq_data);
>> from remove() callback.
>>
>>
>
> Thanks for debugging. I do not see anything on regmap_del_irq_chip() which can be suspected. Is this because of sharing interrupt between mfd and rtc driver?
I don't think so, as long as all the callers pass the IRQF_SHARED flag,
there shouldn't be issues if different drivers call request / free irq.
AFAIK the only thing to take into account is that all callers should
pass a non-NULL cookie (the void * parameter in request and free irq)
so the kernel has a way to differentiate at request / free time.
And this is the case for regmap irq since the regmap_irq_chip_data *
that is passed to regmap_{add,del}_irq_chip() is used as the cookie.
>
> What is your suggestion here? Should we avoid this inside RTC driver (creating this in mfd) and pass this information to the rtc driver using customized platform driver?
>
That wouldn't be the right approach IMHO, that would just mask the real
issue by making the call to regmap_del_irq_chip() to never happen since
the MFD device is not usually unbound due regulators being too critical.
I think we should find the real cause why this is happening and fix it.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2016-02-04 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 13:47 [rtc-linux] [PATCH V3 0/5] rtc: max77686: make max77686 rtc driver as IP driver Laxman Dewangan
2016-02-03 13:47 ` [rtc-linux] [PATCH V3 1/5] rtc: max77686: fix checkpatch error Laxman Dewangan
2016-02-03 13:47 ` [rtc-linux] [PATCH V3 2/5] rtc: max77686: use rtc regmap to access RTC registers Laxman Dewangan
2016-02-03 13:47 ` [rtc-linux] [PATCH V3 3/5] rtc: max77686: avoid reference of parent device info multiple places Laxman Dewangan
2016-02-03 13:47 ` [rtc-linux] [PATCH V3 4/5] mfd: max77686: do not set i2c client data for rtc i2c client Laxman Dewangan
2016-02-03 13:47 ` [rtc-linux] [PATCH V3 5/5] rtc: max77686: move initialisation of rtc regmap, irq chip locally Laxman Dewangan
2016-02-04 0:10 ` [rtc-linux] " Krzysztof Kozlowski
2016-02-04 2:03 ` Laxman Dewangan
2016-02-04 2:50 ` Laxman Dewangan
2016-02-04 3:04 ` Javier Martinez Canillas
2016-02-04 16:49 ` Javier Martinez Canillas
2016-02-04 6:58 ` Krzysztof Kozlowski
2016-02-04 9:08 ` Krzysztof Kozlowski
2016-02-04 10:13 ` Laxman Dewangan
2016-02-04 17:35 ` Javier Martinez Canillas [this message]
2016-02-05 14:37 ` Laxman Dewangan
2016-02-06 5:30 ` Javier Martinez Canillas
2016-02-06 6:29 ` Laxman Dewangan
2016-02-06 13:01 ` Javier Martinez Canillas
2016-02-06 13:40 ` Laxman Dewangan
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=56B38BDC.8070706@osg.samsung.com \
--to=javier@osg.samsung.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=cw00.choi@samsung.com \
--cc=k.kozlowski@samsung.com \
--cc=ldewangan@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rtc-linux@googlegroups.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