From: Andre Przywara <andre.przywara@arm.com>
To: Chen-Yu Tsai <wens@csie.org>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
"Maxime Ripard" <maxime.ripard@free-electrons.com>,
"Emilio López" <emilio@elopez.com.ar>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@codeaurora.org>,
linux-clk <linux-clk@vger.kernel.org>,
linux-sunxi <linux-sunxi@googlegroups.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"Rob Herring" <rob.herring@linaro.org>,
"Mark Rutland" <mark.rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
"Grant Likely" <grant.likely@linaro.org>,
"Frank Rowand" <frowand.list@gmail.com>
Subject: Re: [linux-sunxi] Allwinner A64 MMC support
Date: Mon, 15 Feb 2016 15:22:43 +0000 [thread overview]
Message-ID: <56C1ED43.6010504@arm.com> (raw)
In-Reply-To: <CAGb2v67apAN0H_Nz2kQ4oYjtRwRfaM0L3KTv6uXLfp7m7DpnbA@mail.gmail.com>
Hi,
On 15/02/16 14:58, Chen-Yu Tsai wrote:
> On Mon, Feb 15, 2016 at 10:36 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Hi Chen-Yu,
>>
>> On 15/02/16 14:23, Chen-Yu Tsai wrote:
>>> On Mon, Feb 15, 2016 at 9:59 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>>>> Hi Hans,
>>>>
>>>> ....
>>>>
>>>>>
>>>>> p.s.
>>>>>
>>>>> I love the work you've been doing on the A64, I've not had a chance
>>>>> to try it out yet though. Have you made any progress with getting
>>>>> the mmc slot to work ? If not maybe I can make some time I've
>>>>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>>>>
>>>> Thanks for that!
>>>>
>>>> So we made some progress on the weekend (with the help of #linux-sunxi):
>>>> 1) The regulator node was stupidly put by me into a separate child node
>>>> without putting address and size cells into. So I just moved it into
>>>> /soc directly now and that seems to fixed the missing regulator.
>>>> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
>>>> get registered automatically, but by an explicit call from mach-sunxi/.
>>>> I wonder why we do this (yes, I saw that comment, but still...) and if
>>>> it would work with a normal MODULE_DEVICE_TABLE() declaration.
>>>> There is and will be no equivalent to the mach- directory on arm64.
>>>
>>> On sun6i, we supported the high resolution timer, which had a reset control.
>>> Timers (or clocksources) are registered before device model kicks in, so the
>>> reset had to be explicitly registered before the timer, or the system would
>>> hang. I think we phased that out though. Maxime should know.
>>
>> Ah, thanks for that insight!
>> So that sounds like we would get away with a normal registration for the
>> A64 - and actually many other SoCs as well?
>> Shall we guard the explicit sun6i_reset_init with MACH_SUN6I or
>> something and do the normal registration otherwise?
>> Or do I miss something here?
>
> You'll notice 2 reset control compatibles, one is
> "allwinner,sun6i-a31-ahb1-reset",
> while the other is "allwinner,sun6i-a31-clock-reset". The latter is a
> proper device
> model driver. We also don't have the hstimer device node for later
> SoCs. For A23, it
> was because the hardware had only 1 timer, while the driver needed 2,
> and I didn't
> want to deal with it at the time.
Oooh, now I see that those are actually the same driver, just the
initialization part is separate. Thanks for the hint!
> As long as you use "allwinner,sun6i-a31-clock-reset", no special code is needed.
Yeah, great, I will just replace the string in the DT.
Cheers,
Andre.
>> Cheers,
>> Andre
>>
>>>> 3) As Jens pointed out, the MMC IP block isn't really compatible.
>>>> Changing the clocks is easy (done already), but we need to come up with
>>>> code to cover the new phase setting registers in the A64 MMC register block.
>>>>
>>>> Interestingly somehow hacking this (pretending it is compatible) seems
>>>> to work, though I got reports from people about mysterious kernel
>>>> crashes, so I'm inclined to leave MMC out of the first patch series.
>>>>
>>>> So if you could take a look at the new registers (starting at offset
>>>> 0x140) and work out what we actually need to do here, that would be
>>>> great. I have no real clue about what they actually do and how they
>>>> relate to the current output and sample clock phase.
>>>> To me it looks like we might get away with just triggering the automatic
>>>> calibration and the hardware does the rest for us - keep your fingers
>>>> crossed ;-)
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
next prev parent reply other threads:[~2016-02-15 15:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 17:59 [RFC PATCH 0/4] clk: sunxi: fix DT compatibility issues Andre Przywara
2016-02-12 18:00 ` [RFC PATCH 4/4] DT: Allwinner H3: fix PLL8 clock Andre Przywara
[not found] ` <1455300000-18723-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2016-02-12 17:59 ` [RFC PATCH 1/4] clk: sunxi: rename new sun6i_a31_pll6 clock to sun6i_a31_pll clock Andre Przywara
2016-02-12 17:59 ` [RFC PATCH 2/4] clk: sunxi: re-add old sun6i_a31_pll6 clock Andre Przywara
2016-02-12 17:59 ` [RFC PATCH 3/4] clk: sunxi: revert .dtsi changes for DTs with a " Andre Przywara
2016-02-12 18:51 ` [linux-sunxi] [RFC PATCH 0/4] clk: sunxi: fix DT compatibility issues Hans de Goede
2016-02-15 10:16 ` (Still) breaking DT compatibility (was: [RFC PATCH 0/4] clk: sunxi: fix DT compatibility issues) Andre Przywara
2016-02-15 12:42 ` [linux-sunxi] (Still) breaking DT compatibility Hans de Goede
2016-02-15 13:59 ` Allwinner A64 MMC support Andre Przywara
2016-02-15 14:23 ` [linux-sunxi] " Chen-Yu Tsai
[not found] ` <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-15 14:36 ` Andre Przywara
[not found] ` <56C1E250.9070301-5wv7dgnIgG8@public.gmane.org>
2016-02-15 14:58 ` Chen-Yu Tsai
2016-02-15 15:22 ` Andre Przywara [this message]
2016-02-15 15:52 ` [linux-sunxi] " Hans de Goede
[not found] ` <56C1D9C0.6020601-5wv7dgnIgG8@public.gmane.org>
2016-02-16 9:33 ` Maxime Ripard
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=56C1ED43.6010504@arm.com \
--to=andre.przywara@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=emilio@elopez.com.ar \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@free-electrons.com \
--cc=mturquette@baylibre.com \
--cc=rob.herring@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).