From: Peng Fan <b51431@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] imx-common: fix iomux settings
Date: Tue, 22 Sep 2015 08:36:09 +0800 [thread overview]
Message-ID: <20150922003607.GA18030@shlinux2> (raw)
In-Reply-To: <560064F6.5010608@denx.de>
Hi Stefano, Benoit,
On Mon, Sep 21, 2015 at 10:13:42PM +0200, Stefano Babic wrote:
>Hi Benoit, Peng,
>
>On 21/09/2015 20:41, Beno?t Th?baudeau wrote:
>> Hi Peng,
>>
>> On Mon, Sep 21, 2015 at 3:05 AM, Peng Fan <b51431@freescale.com> wrote:
>>> On Sun, Sep 20, 2015 at 05:02:58PM +0200, Beno?t Th?baudeau wrote:
>>>> On Sun, Sep 20, 2015 at 3:02 PM, Peng Fan <b51431@freescale.com> wrote:
>>>>> On Sun, Sep 20, 2015 at 01:33:20PM +0200, Beno?t Th?baudeau wrote:
>>>>>>>> Also If still checking mux_ctrl_ofs, we have no chance to set iomux
>>>>>>>> for i.MX7D IOMUXC_LPSR_SW_MUX_CTL_PAD_GPIO1_IO00, because the mux_ctrl_ofs
>>>>>>>> for this register is 0.
>>>>>>
>>>>>> The need is clear, but then the test mechanism should be changed, not
>>>>>> removed. You could find a free bit in mux_ctrl_ofs or in mux_mode or
>>>>>> elsewhere in IOMUX_PAD (e.g. bit 63, which is currently reserved),
>>>>>> something like NO_PAD_CTRL, or create a reserved value other than
>>>>>> __NA_ for mux_ctrl_ofs/mux_mode.
>>>>>
>>>>> Stefano,
>>>>>
>>>>> There is '#define NO_PAD_CTRL (1 << 17)' now,
>>>>> we can add'NO_MUX_CTRL' and 'NO_SEL_CTRL(select input)', but need to check
>>>>> whether the __NA__ pads are used or not now.
>>>>> also need a big change for the layout and related macro definition:
>>>>> 39 * MUX_CTRL_OFS: 0..11 (12)
>>>>> 40 * PAD_CTRL_OFS: 12..23 (12)
>>>>> 41 * SEL_INPUT_OFS: 24..35 (12)
>>>>> 42 * MUX_MODE + SION: 36..40 (5)
>>>>> 43 * PAD_CTRL + NO_PAD_CTRL: 41..58 (18)
>>>>> 44 * SEL_INP: 59..62 (4)
>>>>> 45 * reserved: 63 (1)
>>>>>
>>>>> Can we just use the following way, since only i.mx7 has the requirement of
>>>>> mux_ctrl_ofs maybe at 0.
>>>>> if (is_soc_type(MX7)) {
>>>>> __raw_writel(mux_mode, base + mux_ctrl_ofs);
>>>>> } else {
>>>>> if (mux_ctrl_ofs)
>>>>> __raw_writel(mux_mode, base + mux_ctrl_ofs);
>>>>> }
>>>>> I prefer this simple way for now, since we are at RC2 now. Later we can
>>>>> refactor the code using the way to provide macros NO_MUX_CTRL or NO_SEL_CTRL.
>>>>> What do you think?
>>>>
>>>> Maybe, but instead of NO_MUX_CTRL and the like we could also just
>>>> define __NA_ to (-1) instead of 0 and mask the passed values
>>>> appropriately in IOMUX_PAD(). This should be done for all types of
>>>> offsets, and __NA_ should be used everywhere instead of raw 0x000
>>>> values. -1 is guaranteed not to be needed by any SoC because of the
>>>> word alignment requirement for valid offsets. That would keep the
>>>> changes small.
>>>
>>> We can not just simple use __NA_ with value -1.
>>> see
>>> 70 #define IOMUX_PAD(pad_ctrl_ofs, mux_ctrl_ofs, mux_mode, sel_input_ofs, \
>>> 71 sel_input, pad_ctrl) \
>>> 72 (((iomux_v3_cfg_t)(mux_ctrl_ofs) << MUX_CTRL_OFS_SHIFT) | \
>>> 73 ((iomux_v3_cfg_t)(mux_mode) << MUX_MODE_SHIFT) | \
>>> 74 ((iomux_v3_cfg_t)(pad_ctrl_ofs) << MUX_PAD_CTRL_OFS_SHIFT) | \
>>> 75 ((iomux_v3_cfg_t)(pad_ctrl) << MUX_PAD_CTRL_SHIFT) | \
>>> 76 ((iomux_v3_cfg_t)(sel_input_ofs) << MUX_SEL_INPUT_OFS_SHIFT)| \
>>> 77 ((iomux_v3_cfg_t)(sel_input) << MUX_SEL_INPUT_SHIFT))
>>>
>>> iomux_v3_cfg_t(mux_ctrl_ofs) << MUX_CTRL_OFS_SHIFT should be changed to
>>> `iomux_v3_cfg_t((mux_ctrl_ofs) << MUX_CTRL_OFS_SHIFT) & MUX_CTRL_OFS_MASK`,
>>
>> Yes. That's why I said "mask the passed values appropriately in IOMUX_PAD()".
>>
>>> in iomux-v3.c, need to test if (!(mux_ctrl_ofs & 1)) {xxxxx}.
>>
>> Yes, of course.
>>
>>> I am not sure whether this will incur unexpected things or not,
>>
>> There's no reason.
>>
>>> also
>>> the IOMUX_PAD with 0, but not __NA_ need to change to use __NA_.
>>
>> And also, as I said, do the same for pad_ctrl_ofs and sel_input_ofs in
>> order to be consistent, and replace definitions like:
>> MX25_PAD_CTL_GRP_DVS_MISC = IOMUX_PAD(0x418,
>> 0x000, 0, 0, 0, NO_PAD_CTRL),
>> with:
>> MX25_PAD_CTL_GRP_DVS_MISC = IOMUX_PAD(0x418,
>> __NA_, 0, __NA_, 0, NO_PAD_CTRL),
>>
>>> So I prefer to use is_soc_type(MXC_CPU_MX7) for now.
I have sent out one patch: https://patchwork.ozlabs.org/patch/520204/
>>
>> Yes, that's OK for now. I was suggesting that as a longterm approach.
>
>Agree.
>
>> This change would be simple, but many definitions would have to be
>> updated.
>
>Yes - so let it after next release.
I'll prepare the patch for next release.
Regards,
Peng.
>
>Best regards,
>Stefano
>
>--
>=====================================================================
>DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
>=====================================================================
--
prev parent reply other threads:[~2015-09-22 0:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 5:34 [U-Boot] [PATCH 1/3] imx-common: fix iomux settings Peng Fan
2015-09-14 5:34 ` [U-Boot] [PATCH 2/3] imx: wdog: correct wcr register settings Peng Fan
2015-09-14 12:09 ` Fabio Estevam
2015-09-14 12:11 ` Fabio Estevam
2015-09-14 11:46 ` Peng Fan
2015-09-20 7:42 ` Stefano Babic
2015-09-14 5:34 ` [U-Boot] [PATCH 3/3] imx: mx7dsabresd set wdog SRS bit Peng Fan
2015-09-14 12:09 ` Fabio Estevam
2015-09-14 12:08 ` [U-Boot] [PATCH 1/3] imx-common: fix iomux settings Fabio Estevam
2015-09-20 7:43 ` Stefano Babic
2015-09-20 11:33 ` Benoît Thébaudeau
2015-09-20 13:02 ` Peng Fan
2015-09-20 14:57 ` Stefano Babic
2015-09-20 15:02 ` Benoît Thébaudeau
2015-09-21 1:05 ` Peng Fan
2015-09-21 18:41 ` Benoît Thébaudeau
2015-09-21 20:13 ` Stefano Babic
2015-09-22 0:36 ` Peng Fan [this message]
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=20150922003607.GA18030@shlinux2 \
--to=b51431@freescale.com \
--cc=u-boot@lists.denx.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