From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] kirkwood: add kirkwood_mpp_save/restore functions
Date: Tue, 29 May 2012 14:50:24 +0200 [thread overview]
Message-ID: <4FC4C610.1030203@keymile.com> (raw)
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A2FB9FBF7@SC-VEXCH4.marvell.com>
On 05/29/2012 02:06 PM, Prafulla Wadaskar wrote:
>
>
>> -----Original Message-----
>> From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
>> Sent: 29 May 2012 16:59
>> To: Prafulla Wadaskar
>> Cc: holger.brunck at keymile.com; u-boot at lists.denx.de
>> Subject: Re: [PATCH 1/3] kirkwood: add kirkwood_mpp_save/restore
>> functions
>>
>>>> -----Original Message-----
>>>> From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
>>>> Sent: 29 May 2012 14:15
>>>> To: Prafulla Wadaskar
>>>> Cc: holger.brunck at keymile.com; u-boot at lists.denx.de
>>>> Subject: Re: [PATCH 1/3] kirkwood: add kirkwood_mpp_save/restore
>>>> functions
>>>>
>>> ...snip...
>>>>>
>>>>>> +
>>>>>> +void kirkwood_mpp_save(void)
>>>>> This should be
>>>>> void kirkwood_mpp_save(unsigned int *mpp_ctrl, int len)
>>>>
>>>> Here we save _all_ mpp registers, with direct access to the
>> registers.
>>>> With your
>>>> proposed solution, I would save it in a dynamically allocated table
>> of
>>>> size len.
>>>>
>>>> That's fine for me, but I would then need to export MPP_NR_REGS,
>>>> because that is
>>>> what I would pass as len arg, is that OK ?
>>>
>>> I think in your case you need configuration of 4 MPPs, i.e. from
>> MPP6 to MPP11, so you may declare array of length 7 and backup and
>> restore the same MPPs using len = 6.
>>>
>>> No Need to backup and restore all MPPs.
>>>
>>
>> Sorry, but this is exactly what you did in the kirkwood_mpp_conf
>> function, you
>> read and write all the registers every time you need to change only
>> one pin, I
>> took it from there for consistency:
>>
>>> 4efb77d4 cpu/arm926ejs/kirkwood/mpp.c (Prafulla Wadaskar
>> 2009-06-20 11:01:53 +0200 76) for (i = 0; i < MPP_NR_REGS; i++)
>> {
>>> 4efb77d4 cpu/arm926ejs/kirkwood/mpp.c (Prafulla Wadaskar
>> 2009-06-20 11:01:53 +0200 77) writel(mpp_ctrl[i],
>> MPP_CTRL(i));
>>> 4efb77d4 cpu/arm926ejs/kirkwood/mpp.c (Prafulla Wadaskar
>> 2009-06-20 11:01:53 +0200 78) debug(" %08x",
>> mpp_ctrl[i]);
>>> 4efb77d4 cpu/arm926ejs/kirkwood/mpp.c (Prafulla Wadaskar
>> 2009-06-20 11:01:53 +0200 79) }
>>
>> And the way you did it is logical, if it was not done like that, a lot
>> of
>> reading/masking/rewriting would be needed, and this for every single
>> pin, so it
>> would be much less efficient than just reading all the regs and write
>> them all back.
>
> Yes, but the idea is that mpp_config function is called just once during initialization, we have exposed a simple array to do this configuration.
>
> but save/restore will be called very frequently, may be for each SPI transaction. So there must be some optimisation.
> Secondly, we should only tweak only needed MPPs in run time, why all? It may lead to some other side effects (I don't know).
>
With the proposed code, all are saved and restored, but not all are tweaked.
Furthermore, maybe reading and writing back 7 registers and is more efficient
than determining which one of the 7 have to be read/written back and then
performing the accesses.
However, if you tell me that mpp_config function is supposed to be called just
once during initialization, I will propose a new function that optimizes these
reg accesses as you would prefer it, but the best optimization potential is to
avoid to call the 2 mpp_config and mpp_save functions.
next prev parent reply other threads:[~2012-05-29 12:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 10:53 [U-Boot] [PATCH 0/3] kirkwood spi_claim/release_bus support Valentin Longchamp
2012-05-16 10:53 ` [U-Boot] [PATCH 1/3] kirkwood: add kirkwood_mpp_save/restore functions Valentin Longchamp
2012-05-24 8:26 ` Prafulla Wadaskar
2012-05-28 22:07 ` Michael Walle
2012-05-29 12:42 ` Prafulla Wadaskar
2012-05-29 17:02 ` Michael Walle
2012-05-29 8:44 ` Valentin Longchamp
2012-05-29 10:12 ` Prafulla Wadaskar
2012-05-29 11:28 ` Valentin Longchamp
2012-05-29 12:06 ` Prafulla Wadaskar
2012-05-29 12:50 ` Valentin Longchamp [this message]
2012-05-29 13:15 ` Prafulla Wadaskar
2012-05-29 14:47 ` Marek Vasut
2012-05-30 14:28 ` [U-Boot] patchwork cleanup Prafulla Wadaskar
2012-06-01 15:27 ` Marek Vasut
2012-05-16 10:53 ` [U-Boot] [PATCH 2/3] spi/kirkwood: support spi_claim/release_bus functions Valentin Longchamp
2012-05-24 8:35 ` Prafulla Wadaskar
2012-05-29 8:32 ` Valentin Longchamp
2012-05-29 10:29 ` Prafulla Wadaskar
2012-05-29 11:32 ` Valentin Longchamp
2012-05-16 10:53 ` [U-Boot] [PATCH 3/3] spi/kirkwood: add weak functions board_spi_claim/release_bus Valentin Longchamp
2012-05-24 8:38 ` Prafulla Wadaskar
2012-05-29 8:32 ` Valentin Longchamp
2012-05-29 12:13 ` Prafulla Wadaskar
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=4FC4C610.1030203@keymile.com \
--to=valentin.longchamp@keymile.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