Linux RTC
 help / color / mirror / Atom feed
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.

  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