From: Dmitry Artamonow <mad_soft-aPYA7nAdAYY@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andi <andi.shyti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>,
Mike Rapoport <mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2 2/2] arm/tegra: add timeout to PCIe PLL lock detection loop
Date: Mon, 12 Mar 2012 23:30:21 +0400 [thread overview]
Message-ID: <20120312193020.GA1584@rainbow> (raw)
In-Reply-To: <4F5E3BE7.4080207-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 12:09 Mon 12 Mar , Stephen Warren wrote:
> Thierry pointed out that one of NVIDIA's downstream kernels uses a
> timeout of 300 here, rather than 2000 above. Do you see a specific need
> for this timeout for be 2000 rather than 300? It might be nice to be
> consistent.
No, there's no specific need for it to be 2000 - it may as well be 300.
I just wanted to stay on the safe side, but I think 300 should be still
more than enough time for PLL to lock.
>
> Olof, I notice you've already applied V1 of this, which has the return
> statement issue. Can you replace it with this, or should Dmitry send an
> incremental patch?
Yes, V1 breaks more things than it fixes, so it would be nice if
it can be replaced with fixed version (I hope it's not too late yet).
BTW, regarding timeout discussion above - should I resend patch with
adjusted timeout, or can you change it while applying? (of course,
if we settle on incremental patch, I'll roll this change in)
--
Best regards,
Dmitry "MAD" Artamonow
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Artamonow <mad_soft@inbox.ru>
To: Stephen Warren <swarren@wwwdotorg.org>, Olof Johansson <olof@lixom.net>
Cc: linux-tegra@vger.kernel.org, Andi <andi.shyti@gmail.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
linux-kernel@vger.kernel.org, Colin Cross <ccross@android.com>,
Mike Rapoport <mike@compulab.co.il>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] arm/tegra: add timeout to PCIe PLL lock detection loop
Date: Mon, 12 Mar 2012 23:30:21 +0400 [thread overview]
Message-ID: <20120312193020.GA1584@rainbow> (raw)
In-Reply-To: <4F5E3BE7.4080207@wwwdotorg.org>
On 12:09 Mon 12 Mar , Stephen Warren wrote:
> Thierry pointed out that one of NVIDIA's downstream kernels uses a
> timeout of 300 here, rather than 2000 above. Do you see a specific need
> for this timeout for be 2000 rather than 300? It might be nice to be
> consistent.
No, there's no specific need for it to be 2000 - it may as well be 300.
I just wanted to stay on the safe side, but I think 300 should be still
more than enough time for PLL to lock.
>
> Olof, I notice you've already applied V1 of this, which has the return
> statement issue. Can you replace it with this, or should Dmitry send an
> incremental patch?
Yes, V1 breaks more things than it fixes, so it would be nice if
it can be replaced with fixed version (I hope it's not too late yet).
BTW, regarding timeout discussion above - should I resend patch with
adjusted timeout, or can you change it while applying? (of course,
if we settle on incremental patch, I'll roll this change in)
--
Best regards,
Dmitry "MAD" Artamonow
WARNING: multiple messages have this Message-ID (diff)
From: mad_soft@inbox.ru (Dmitry Artamonow)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] arm/tegra: add timeout to PCIe PLL lock detection loop
Date: Mon, 12 Mar 2012 23:30:21 +0400 [thread overview]
Message-ID: <20120312193020.GA1584@rainbow> (raw)
In-Reply-To: <4F5E3BE7.4080207@wwwdotorg.org>
On 12:09 Mon 12 Mar , Stephen Warren wrote:
> Thierry pointed out that one of NVIDIA's downstream kernels uses a
> timeout of 300 here, rather than 2000 above. Do you see a specific need
> for this timeout for be 2000 rather than 300? It might be nice to be
> consistent.
No, there's no specific need for it to be 2000 - it may as well be 300.
I just wanted to stay on the safe side, but I think 300 should be still
more than enough time for PLL to lock.
>
> Olof, I notice you've already applied V1 of this, which has the return
> statement issue. Can you replace it with this, or should Dmitry send an
> incremental patch?
Yes, V1 breaks more things than it fixes, so it would be nice if
it can be replaced with fixed version (I hope it's not too late yet).
BTW, regarding timeout discussion above - should I resend patch with
adjusted timeout, or can you change it while applying? (of course,
if we settle on incremental patch, I'll roll this change in)
--
Best regards,
Dmitry "MAD" Artamonow
next prev parent reply other threads:[~2012-03-12 19:30 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 8:45 [PATCH/RFC 0/2] Couple of Tegra2 PCIe fixes(?) Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
2012-03-06 8:45 ` [PATCH/RFC 1/2] arm/tegra: fix harmony pinmux for PCIe Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
2012-03-06 16:55 ` Stephen Warren
2012-03-06 16:55 ` Stephen Warren
2012-03-06 16:55 ` Stephen Warren
2012-03-06 8:45 ` [PATCH/RFC 2/2] arm/tegra: add timeout to PCIe PLL lock detection loop Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
2012-03-06 8:45 ` Dmitry Artamonow
[not found] ` <1331023544-6439-3-git-send-email-mad_soft-aPYA7nAdAYY@public.gmane.org>
2012-03-06 9:38 ` Andi
2012-03-06 9:38 ` Andi
2012-03-06 9:38 ` Andi
[not found] ` <CANndwHav6JcqNOuOXcD1dSNUmVYAV=MJ+y+ud6202q6Dh42Vgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-06 11:19 ` Dmitry Artamonow
2012-03-06 11:19 ` Dmitry Artamonow
2012-03-06 11:19 ` Dmitry Artamonow
2012-03-07 6:38 ` Thierry Reding
2012-03-07 6:38 ` Thierry Reding
2012-03-07 6:38 ` Thierry Reding
2012-03-06 16:58 ` Stephen Warren
2012-03-06 16:58 ` Stephen Warren
2012-03-06 16:58 ` Stephen Warren
[not found] ` <4F56424A.3020305-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-06 19:09 ` Thierry Reding
2012-03-06 19:09 ` Thierry Reding
2012-03-06 19:09 ` Thierry Reding
2012-03-06 20:15 ` Dmitry Artamonow
2012-03-06 20:15 ` Dmitry Artamonow
2012-03-06 20:15 ` Dmitry Artamonow
2012-03-09 10:09 ` [PATCH v2 " Dmitry Artamonow
2012-03-09 10:09 ` Dmitry Artamonow
2012-03-09 10:09 ` Dmitry Artamonow
[not found] ` <1331287760-10546-1-git-send-email-mad_soft-aPYA7nAdAYY@public.gmane.org>
2012-03-12 18:09 ` Stephen Warren
2012-03-12 18:09 ` Stephen Warren
2012-03-12 18:09 ` Stephen Warren
[not found] ` <4F5E3BE7.4080207-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-12 19:30 ` Dmitry Artamonow [this message]
2012-03-12 19:30 ` Dmitry Artamonow
2012-03-12 19:30 ` Dmitry Artamonow
2012-03-12 19:56 ` Olof Johansson
2012-03-12 19:56 ` Olof Johansson
2012-03-12 19:56 ` Olof Johansson
[not found] ` <CAOesGMi0aqCjLsJ5wWXwFVQL2T8wtUuE14rFZ9h7NKHXcWAoqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-13 5:46 ` [PATCH] arm/tegra: pcie: fix return value of function Dmitry Artamonow
2012-03-13 5:46 ` Dmitry Artamonow
2012-03-13 5:46 ` Dmitry Artamonow
[not found] ` <1331617587-10714-1-git-send-email-mad_soft-aPYA7nAdAYY@public.gmane.org>
2012-03-13 19:36 ` Stephen Warren
2012-03-13 19:36 ` Stephen Warren
2012-03-13 19:36 ` Stephen Warren
[not found] ` <4F5FA1BB.5050002-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-18 17:27 ` Olof Johansson
2012-03-18 17:27 ` Olof Johansson
2012-03-18 17:27 ` Olof Johansson
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=20120312193020.GA1584@rainbow \
--to=mad_soft-apya7nadayy@public.gmane.org \
--cc=andi.shyti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@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.