public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] ARM: pxa: lubbock: add pcmcia clock
Date: Mon, 05 Sep 2016 20:50:53 +0200	[thread overview]
Message-ID: <87zinmi3jm.fsf@belgarion.home> (raw)
In-Reply-To: <20160905160420.GQ1041@n2100.armlinux.org.uk> (Russell King's message of "Mon, 5 Sep 2016 17:04:20 +0100")

Russell King - ARM Linux <linux@armlinux.org.uk> writes:

> On Mon, Sep 05, 2016 at 04:37:23PM +0200, Robert Jarzmik wrote:
> From what I remember, the SA1111 takes the 3.6864MHz clock input as an
> input to its own PLL to generate the clocks it needs internally.  All
> the PCMCIA timing is handled by the SA1110 or PXA.
>
> The reason that we need to tell the SA1111 PCMCIA device about the PXA
> clock is not because the SA1111 uses it, but because the driver needs it
> to work out the correct timing information to program the SA1110 or PXA
> access times.

I've been pondering that last sentence for a bit and what appeared to me is that
between the PXA and the SA1111, as there is no clock from one to the other,
ie. that the SA1111 clock for PCMCIA signals is independent from any PXA clock
(well, excepting it's a PLL from a 3.6864MHz, but let's forget that), the
contract binding the PXA and the SA1111 is a _timings_ one rather that a clock
one.

Or said differently, the 2 IPs must agree on timing values in order to
inter-operate, and so should the device drivers. Their internal clock frequencies
are marginal, as on an asynchronous interface, what is important is that PXA
accepts nPIOR within [a .. b] and SA1111 accepts nPIOR within [c .. d], and the
intersection is used to setup them both.

I have not really looked into the PCMCIA structure, but I suppose it's clock
based today.

> This means that the current driver structure does _not_ fit the DT model
> at all - I hope that no one has plans to construct a DT model based on
> the current code structure, because that would be totally wrong.
Oh there are not that many candidates these days for PCMCIA nor PXA. I don't see
any other volunteer than me on the PXA front, and even if I find the time in 1
year or 2, I will remember this conversation and will discuss thoroughly before
trying to code.

> Thanks, the commit message is mostly fine, I think it ought to also
> point out that it's used by the driver to derive the timing information,
> and doesn't physically exist to the SA1111.

Something like ?
"The added clock doesn't actually exist, ie. there is no physical clock line
from the PXA to the SA1111 on lubbock used by the PCMCIA block on the
SA1111. The clocking information is only used to setup the memory bus timings."

Cheers.

-- 
Robert

  reply	other threads:[~2016-09-05 18:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-04 18:59 [PATCH 1/3] ARM: pxa: pxa_cplds: fix interrupt handling Robert Jarzmik
2016-09-04 18:59 ` [PATCH 2/3] ARM: pxa: lubbock: add pcmcia clock Robert Jarzmik
2016-09-04 20:08   ` Russell King - ARM Linux
2016-09-04 20:28     ` Russell King - ARM Linux
2016-09-05 14:37     ` Robert Jarzmik
2016-09-05 16:04       ` Russell King - ARM Linux
2016-09-05 18:50         ` Robert Jarzmik [this message]
2016-09-06 11:22           ` Russell King - ARM Linux
2016-09-04 18:59 ` [PATCH 3/3] [DO_NOT_REVIEW] sa1111: left up to Russell King Robert Jarzmik
2016-09-09 16:10 ` [PATCH 1/3] ARM: pxa: pxa_cplds: fix interrupt handling Robert Jarzmik

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=87zinmi3jm.fsf@belgarion.home \
    --to=robert.jarzmik@free.fr \
    --cc=daniel@zonque.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /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