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: 24+ 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 ` [PATCH v7 1/5] ARM: tegra: export apb dma readl/writel Peter De Schrijver
2014-06-05 17:57 ` 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 ` [PATCH v7 3/5] misc: fuse: Add efuse driver for Tegra Peter De Schrijver
2014-06-05 17:01 ` Tuomas Tynkkynen
2014-06-05 18:09 ` Stephen Warren
2014-06-05 18:37 ` Stephen Warren
2014-06-05 22:09 ` Peter De Schrijver
2014-06-05 22:54 ` Stephen Warren
2014-06-06 7:35 ` Peter De Schrijver
2014-06-09 18:29 ` Stephen Warren
2014-06-11 12:47 ` Mikko Perttunen
2014-06-11 15:25 ` Peter De Schrijver
2014-06-11 15:58 ` Stephen Warren
2014-06-11 16:19 ` Peter De Schrijver
2014-06-11 16:29 ` Stephen Warren [this message]
2014-06-05 13:09 ` [PATCH v7 4/5] ARM: tegra: Add efuse and apbmisc bindings Peter De Schrijver
2014-06-05 18:41 ` Stephen Warren
2014-06-05 22:13 ` Peter De Schrijver
2014-06-05 22:55 ` Stephen Warren
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
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@wwwdotorg.org \
--cc=akpm@linux-foundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mperttunen@nvidia.com \
--cc=pdeschrijver@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=wsa@the-dreams.de \
/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