From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Peter De Schrijver
<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Mikko Perttunen
<mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v7 3/5] misc: fuse: Add efuse driver for Tegra
Date: Wed, 11 Jun 2014 10:29:22 -0600 [thread overview]
Message-ID: <539883E2.9040605@wwwdotorg.org> (raw)
In-Reply-To: <20140611161901.GI5961-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
On 06/11/2014 10:19 AM, Peter De Schrijver wrote:
> On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:
>> On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
>>> On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
>>>> On 05/06/14 16:09, Peter De Schrijver wrote:
>>>> ...
>>>>> +int tegra_fuse_readl(u32 offset, u32 *val)
>>>>> +{
>>>>> + if (!fuse_readl)
>>>>> + return -ENXIO;
>>>>> +
>>>>> + *val = fuse_readl(offset);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>
>>>> -EPROBE_DEFER would be a better error value, so that drivers can work
>>>
>>> Ok.
>>>
>>>> even if they are initially probed before the fuse driver. Of course, if
>>>> the fuse initialization is moved into machine init then this is a non-issue.
>>>
>>> The exported function will always be initialized later because on Tegra20 it
>>> requires APB DMA to be available. If you read the fuses directly, the system
>>> sometimes hangs.
>>
>> That's not true in the current code. IIRC, the bug was that *if* an APB
>> DMA access to anything and a CPU access to the fuses happen at the same
>> time, then there can be a hang. As such, the current fuse code accesses
>> the fuses directly (without potential for a hang) if the APB DMA driver
>> is not available, but once the driver becomes available, it reads the
>> fuses through DMA instead. Does the new code not do that?
>>
>
> I'm not so sure about that. I have seen the hang when dumping all fuses using
> sysfs in an otherwise idle system booted from initrd. I don't think there
> should be any APB DMA activity going on then?
Hmm. Perhaps I'm misremembering the trigger for the bug then. Still, the
existing code works as I described. Perhaps that's dangerous and it
shouldn't though. Either way, I think we should have a standalone commit
that removes tegra_apb_readl_using_dma()'s fallback to
tegra_apb_readl_direct(), so any behaviour change that causes a problem
can be bisected easily.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 3/5] misc: fuse: Add efuse driver for Tegra
Date: Wed, 11 Jun 2014 10:29:22 -0600 [thread overview]
Message-ID: <539883E2.9040605@wwwdotorg.org> (raw)
In-Reply-To: <20140611161901.GI5961@tbergstrom-lnx.Nvidia.com>
On 06/11/2014 10:19 AM, Peter De Schrijver wrote:
> On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:
>> On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
>>> On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
>>>> On 05/06/14 16:09, Peter De Schrijver wrote:
>>>> ...
>>>>> +int tegra_fuse_readl(u32 offset, u32 *val)
>>>>> +{
>>>>> + if (!fuse_readl)
>>>>> + return -ENXIO;
>>>>> +
>>>>> + *val = fuse_readl(offset);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>
>>>> -EPROBE_DEFER would be a better error value, so that drivers can work
>>>
>>> Ok.
>>>
>>>> even if they are initially probed before the fuse driver. Of course, if
>>>> the fuse initialization is moved into machine init then this is a non-issue.
>>>
>>> The exported function will always be initialized later because on Tegra20 it
>>> requires APB DMA to be available. If you read the fuses directly, the system
>>> sometimes hangs.
>>
>> That's not true in the current code. IIRC, the bug was that *if* an APB
>> DMA access to anything and a CPU access to the fuses happen at the same
>> time, then there can be a hang. As such, the current fuse code accesses
>> the fuses directly (without potential for a hang) if the APB DMA driver
>> is not available, but once the driver becomes available, it reads the
>> fuses through DMA instead. Does the new code not do that?
>>
>
> I'm not so sure about that. I have seen the hang when dumping all fuses using
> sysfs in an otherwise idle system booted from initrd. I don't think there
> should be any APB DMA activity going on then?
Hmm. Perhaps I'm misremembering the trigger for the bug then. Still, the
existing code works as I described. Perhaps that's dangerous and it
shouldn't though. Either way, I think we should have a standalone commit
that removes tegra_apb_readl_using_dma()'s fallback to
tegra_apb_readl_direct(), so any behaviour change that causes a problem
can be bisected easily.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Mikko Perttunen <mperttunen@nvidia.com>,
Russell King <linux@arm.linux.org.uk>,
Thierry Reding <thierry.reding@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 3/5] misc: fuse: Add efuse driver for Tegra
Date: Wed, 11 Jun 2014 10:29:22 -0600 [thread overview]
Message-ID: <539883E2.9040605@wwwdotorg.org> (raw)
In-Reply-To: <20140611161901.GI5961@tbergstrom-lnx.Nvidia.com>
On 06/11/2014 10:19 AM, Peter De Schrijver wrote:
> On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:
>> On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
>>> On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
>>>> On 05/06/14 16:09, Peter De Schrijver wrote:
>>>> ...
>>>>> +int tegra_fuse_readl(u32 offset, u32 *val)
>>>>> +{
>>>>> + if (!fuse_readl)
>>>>> + return -ENXIO;
>>>>> +
>>>>> + *val = fuse_readl(offset);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>
>>>> -EPROBE_DEFER would be a better error value, so that drivers can work
>>>
>>> Ok.
>>>
>>>> even if they are initially probed before the fuse driver. Of course, if
>>>> the fuse initialization is moved into machine init then this is a non-issue.
>>>
>>> The exported function will always be initialized later because on Tegra20 it
>>> requires APB DMA to be available. If you read the fuses directly, the system
>>> sometimes hangs.
>>
>> That's not true in the current code. IIRC, the bug was that *if* an APB
>> DMA access to anything and a CPU access to the fuses happen at the same
>> time, then there can be a hang. As such, the current fuse code accesses
>> the fuses directly (without potential for a hang) if the APB DMA driver
>> is not available, but once the driver becomes available, it reads the
>> fuses through DMA instead. Does the new code not do that?
>>
>
> I'm not so sure about that. I have seen the hang when dumping all fuses using
> sysfs in an otherwise idle system booted from initrd. I don't think there
> should be any APB DMA activity going on then?
Hmm. Perhaps I'm misremembering the trigger for the bug then. Still, the
existing code works as I described. Perhaps that's dangerous and it
shouldn't though. Either way, I think we should have a standalone commit
that removes tegra_apb_readl_using_dma()'s fallback to
tegra_apb_readl_direct(), so any behaviour change that causes a problem
can be bisected easily.
next prev parent reply other threads:[~2014-06-11 16:29 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 13:09 [PATCH v7 0/5] efuse driver for Tegra Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` [PATCH v7 1/5] ARM: tegra: export apb dma readl/writel Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
[not found] ` <1401973754-19701-2-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-05 17:57 ` Stephen Warren
2014-06-05 17:57 ` Stephen Warren
2014-06-05 17:57 ` Stephen Warren
[not found] ` <5390AF88.9050007-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-05 18:06 ` Stephen Warren
2014-06-05 18:06 ` Stephen Warren
2014-06-05 18:06 ` Stephen Warren
2014-06-05 13:09 ` [PATCH v7 2/5] ARM: tegra: move fuse exports to tegra-soc.h Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
[not found] ` <1401973754-19701-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-05 13:09 ` [PATCH v7 3/5] misc: fuse: Add efuse driver for Tegra Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
[not found] ` <1401973754-19701-4-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-05 17:01 ` Tuomas Tynkkynen
2014-06-05 17:01 ` Tuomas Tynkkynen
2014-06-05 17:01 ` Tuomas Tynkkynen
2014-06-05 18:09 ` Stephen Warren
2014-06-05 18:09 ` Stephen Warren
2014-06-05 18:09 ` Stephen Warren
2014-06-05 18:37 ` Stephen Warren
2014-06-05 18:37 ` Stephen Warren
2014-06-05 18:37 ` Stephen Warren
[not found] ` <5390B8E6.1050600-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-05 22:09 ` Peter De Schrijver
2014-06-05 22:09 ` Peter De Schrijver
2014-06-05 22:09 ` Peter De Schrijver
[not found] ` <20140605220946.GP5961-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-05 22:54 ` Stephen Warren
2014-06-05 22:54 ` Stephen Warren
2014-06-05 22:54 ` Stephen Warren
[not found] ` <5390F508.8080104-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-06 7:35 ` Peter De Schrijver
2014-06-06 7:35 ` Peter De Schrijver
2014-06-06 7:35 ` Peter De Schrijver
[not found] ` <20140606073507.GS5961-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-09 18:29 ` Stephen Warren
2014-06-09 18:29 ` Stephen Warren
2014-06-09 18:29 ` Stephen Warren
2014-06-11 12:47 ` Mikko Perttunen
2014-06-11 12:47 ` Mikko Perttunen
[not found] ` <53984FE3.6010509-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-11 15:25 ` Peter De Schrijver
2014-06-11 15:25 ` Peter De Schrijver
2014-06-11 15:25 ` Peter De Schrijver
2014-06-11 15:58 ` Stephen Warren
2014-06-11 15:58 ` Stephen Warren
2014-06-11 16:19 ` Peter De Schrijver
2014-06-11 16:19 ` Peter De Schrijver
[not found] ` <20140611161901.GI5961-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-11 16:29 ` Stephen Warren [this message]
2014-06-11 16:29 ` Stephen Warren
2014-06-11 16:29 ` Stephen Warren
2014-06-05 13:09 ` [PATCH v7 4/5] ARM: tegra: Add efuse and apbmisc bindings Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 18:41 ` Stephen Warren
2014-06-05 18:41 ` Stephen Warren
[not found] ` <5390B9F3.8030108-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-05 22:13 ` Peter De Schrijver
2014-06-05 22:13 ` Peter De Schrijver
2014-06-05 22:13 ` Peter De Schrijver
[not found] ` <20140605221301.GQ5961-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-05 22:55 ` Stephen Warren
2014-06-05 22:55 ` Stephen Warren
2014-06-05 22:55 ` Stephen Warren
[not found] ` <5390F55A.8090207-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-06 7:35 ` Peter De Schrijver
2014-06-06 7:35 ` Peter De Schrijver
2014-06-06 7:35 ` Peter De Schrijver
2014-06-05 13:09 ` [PATCH v7 5/5] ARM: tegra: build new fuse driver in drivers/misc Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
2014-06-05 13:09 ` Peter De Schrijver
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=539883E2.9040605@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.