From: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 1/5] lib: Add wait_for_bit
Date: Wed, 20 Jan 2016 22:03:40 +0100 [thread overview]
Message-ID: <569FF62C.6000906@gmail.com> (raw)
In-Reply-To: <CAPnjgZ0b0Dnyv_2QOKpao6d30FVWRfqtk3GK9dtOc7okszPT0w@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
On 20.01.2016 05:34, Simon Glass wrote:
[...]
> On 27 December 2015 at 10:28, Mateusz Kulikowski
> <mateusz.kulikowski@gmail.com> wrote:
>> Add function to poll register waiting for specific bit(s).
>> Similar functions are implemented in few drivers - they are almost
>> identical and can be generalized.
[...]
>
> Sorry I only just saw this, but thought I'd make a few comments.
Nooo, I was expecting at least this to be merged during this merge window :)
[...]
>> + *
>> + * @param prefix Prefix added to timeout messagge (message visible only
>> + * with debug enabled)
>> + * @param reg Register that will be read (using readl())
>> + * @param mask Bit(s) of register that must be active
>> + * @param set Selects wait condition (bit set or clear)
>> + * @param timeout Timeout (in miliseconds)
>> + * @param breakable Enables CTRL-C interruption
>> + * @return 0 on success, -ETIMEDOUT or -EINTR on failure
>> + */
>> +static inline int wait_for_bit(const char *prefix, const u32 *reg,
>> + const u32 mask, const bool set,
>> + const unsigned int timeout,
>
> timeout_ms would be more obvious
This may be a good idea to make it more foolproof -
@trini: Will v4 with small change like that delay merging this series into mainline?
>
>> + const bool breakable)
>
> Wow this is a pretty big inline function.
I personally probably could just drop inline and leave "static" but still
keep it in header (so it may not be inlined),
but it would probably violate some unwritten holy rules :)
First version was compiled into object file, but then either it would require
extra config option, or would pollute rodata of all boards (which is bad).
>
> Do you need the 'prefix' parameter? It seems that the callers print
> messages anyway. How about adding a flags word for @set and
> @breakable? Those params could then be combined, and you end up with 4
> parameters instead of 6.
I prefer to keep it as is (for now).
This function is supposed to be drop-in replacement for four almost the same
functions in drivers (dwc2, ohci-lpc..., ehci-mx6 and zynq_gem).
My intent was to keep all changes as small as possible so I would not cause
regressions, but will make some people happy.
As for argument count - there was already request to add new feature [1],
which is nice (I appended it to my task queue), so I can rework it a bit later
(and perhaps use it in even more places where it would be useful).
As long as this function is inlined - argument count doesn't matter that much
imo - as long as one remembers argument order or has smart IDE that does it for him.
>
>> +{
>> + u32 val;
>> + unsigned long start = get_timer(0);
>> +
>> + while (1) {
>> + val = readl(reg);
>> +
>> + if (!set)
>> + val = ~val;
>> +
>> + if ((val & mask) == mask)
>> + return 0;
>> +
>> + if (get_timer(start) > timeout)
>> + break;
>> +
>> + if (breakable && ctrlc()) {
>> + puts("Abort\n");
>
> This is bad if used from drivers. We try not to output things. It it necessary?
Same arguments as above apply.
Although I agree that in future it may be useful not to have puts here.
Is it ok with you (timeout -> timeout_ms if possible I'll do now, rest + [1]
in future)?
[1] http://lists.denx.de/pipermail/u-boot/2015-December/239468.html
Regards,
Mateusz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWn/YnAAoJELvtohmVtQzBMFMIAITNu+ORG3trzOpc3xaM2QXC
4WZG89SDkM/KW26LpZEj5I/aARr5rPwO637zCfc7Vf6k1VX1CohdRPv7E3wiiOQ3
Lt6NL6yyLQfIzQkFQb5373ao7GbuyKUqvsbsQkd2TGDUTtEgo9tRWLtpt9wTstMT
H0YK2uNb9Zg6pJ6Z/0xCLua723DXcSXPgx8PV2Wbo3nR3BIlz70HYLHKvAMw2O2w
phSX2/TIx7LjCUw4lvIfGJXapnZV3z9hmCOLsHCPEZAbcE5MYKqX/t7GJu3reuao
j9MzZzpxr6CTzdavPhWxcpsNUwVsg7Q9KOIq7DQMA5qoW6EKLeOSKdr6FxKReFg=
=fVR7
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2016-01-20 21:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-27 17:28 [U-Boot] [PATCH v3 0/5] Add wait_for_bit() Mateusz Kulikowski
2015-12-27 17:28 ` [U-Boot] [PATCH v3 1/5] lib: Add wait_for_bit Mateusz Kulikowski
2015-12-31 13:07 ` Mateusz Kulikowski
2016-01-14 20:08 ` Tom Rini
2016-01-20 4:34 ` Simon Glass
2016-01-20 21:03 ` Mateusz Kulikowski [this message]
2016-01-21 2:45 ` Simon Glass
2016-01-21 19:11 ` Tom Rini
2015-12-27 17:28 ` [U-Boot] [PATCH v3 2/5] usb: dwc2: Use shared wait_for_bit Mateusz Kulikowski
2015-12-27 22:17 ` Stefan Bruens
2015-12-31 11:31 ` Mateusz Kulikowski
2016-01-14 20:08 ` Tom Rini
2015-12-27 17:28 ` [U-Boot] [PATCH v3 3/5] usb: ohci-lpc32xx: " Mateusz Kulikowski
2016-01-14 20:08 ` Tom Rini
2015-12-27 17:28 ` [U-Boot] [PATCH v3 4/5] usb: ehci-mx6: " Mateusz Kulikowski
2016-01-14 20:08 ` Tom Rini
2015-12-27 17:28 ` [U-Boot] [PATCH v3 5/5] net: zynq_gem: " Mateusz Kulikowski
2016-01-14 20:08 ` Tom Rini
2016-01-15 21:31 ` Moritz Fischer
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=569FF62C.6000906@gmail.com \
--to=mateusz.kulikowski@gmail.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