| Age | Commit message (Collapse) | Author |
|---|
|
For bit fields with 31 bits (e.g: DEFINE_BITFIELD(MYREG, 30, 0) ),
the calculation of mask value will go overflow:
"error: integer overflow in expression '-2147483648 - 1' of
type 'int' results in '2147483647'".
And for bit fields with 32 bits (e.g: DEFINE_BITFIELD(MYREG, 31, 0) ),
the error will be:
"error: left shift count >= width of type [-Werror=shift-count-overflow]"
To fix these issues, the bit field macros should always use unsigned
integers, and use 64bit integer when creating mask value.
Change-Id: Ie3cddf9df60b83de4e21243bfde6b79729fb06ef
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: I2fa3bad88bb5b068baa1cfc6bbcddaabb09da1c5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I730f80afd8aad250f26534435aec24bea75a849c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
This patch changes all existing instances of clrsetbits_leXX() to the
new endian-independent clrsetbitsXX(), after double-checking that
they're all in SoC-specific code operating on CPU registers and not
actually trying to make an endian conversion.
This patch was created by running
sed -i -e 's/\([cs][le][rt]bits\)_le\([136][624]\)/\1\2/g'
across the codebase and cleaning up formatting a bit.
Change-Id: I7fc3e736e5fe927da8960fdcd2aae607b62b5ff4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
This patch removes the recently added update8/16/32/64() API and
replaces it with clrsetbits8/16/32/64(). This is more in line with the
existing endian-specific clrsetbits_le16/32/64() functions that have
been used for this task on some platforms already. Rename clrsetbits_8()
to clrsetbits8() to be in line with the new naming.
Keep this stuff in <device/mmio.h> and get rid of <mmio.h> again because
having both is confusing and we seem to have been standardizing on
<device/mmio.h> as the standard arch-independent header that all
platforms should include already.
Also sync libpayload back up with what we have in coreboot. (I'm the
original author of the clrsetbits_le32-definitions so I'm relicensing
them to BSD here.)
Change-Id: Ie4f7b9fdbdf9e8c0174427b4288f79006d56978b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37432
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
buffer_to_fifo32() is a simple wrapper to buffer_to_fifo32_prefix(), but
unfortunately its arguments are swapped. This patch fixes the issue.
Change-Id: I6414bf51dd9de681b3b87bbaf4ea4efc815f7ae1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36942
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
For fields with single bit, it's easier to declare as
DEFINE_BIT(name, bit)
Change-Id: If20e6b1809073b2c0dc84190edc25b207bf332b7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
When accessing register with multiple bit fields, the common approach is
to use clrsetbits_le32, for example:
clrsetbits(®, (1 << 0) | (0x3 << 1) | (0x7 << 10),
(1 << 0) | (0x1 << 1) | (0x5 << 10));
This hard to maintain because we have to calculate the mask values
manually, make sure the duplicated shift (offset) was set correctly.
And it may be even worse if the value to set will be based on some
runtime values (that many developers will do a if-block with two very
similar argument list), and leaving lots of magic numbers.
We want to encourage developers always giving field names, and have a
better way of setting fields. The proposed utility macros are:
DEFINE_BITFIELD(name, high_bit, low_bit)
EXTRACT_BITFIELD(value, name)
WRITE32_BITFIELDS(addr, name, value, [name2, value2, ...])
READ32_BITFIELD(addr, name)
Where a developer can easily convert from data sheet like
BITS NAME
26:24 SEC_VIO
Into a declaration
DEFINE_BITFIELD(SEC_VIO, 26, 24)
Then, a simple call can set the field as:
WRITE32_BITFIELDS(®, SEC_VIO, 2);
That is much easier to understand than
clrsetbits_le32(®, 0x7 << 24, 0x2 << 24);
And to extract the value:
READ32_BITFIELD(®, SEC_VIO)
That is equivalent to:
(read32(®) & 0x3) >> 24
Change-Id: I8a1b17142f7a7dc6c441b0b1ee67d60d73ec8cc8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35463
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Many peripheral drivers across different SoCs regularly face the same
task of piping a transfer buffer into (or reading it out of) a 32-bit
FIFO register. Sometimes it's just one register, sometimes a whole array
of registers. Sometimes you actually transfer 4 bytes per register
read/write, sometimes only 2 (or even 1). Sometimes writes need to be
prefixed with one or two command bytes which makes the actual payload
buffer "misaligned" in relation to the FIFO and requires a bunch of
tricky bit packing logic to get right. Most of the times transfer
lengths are not guaranteed to be divisible by 4, which also requires a
bunch of logic to treat the potential unaligned end of the transfer
correctly.
We have a dozen different implementations of this same pattern across
coreboot. This patch introduces a new family of helper functions that
aims to solve all these use cases once and for all (*fingers crossed*).
Change-Id: Ia71f66c1cee530afa4c77c46a838b4de646ffcfb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ie32f1d43168c277be46cdbd7fbfa2445d9899689
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31699
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
MMIO operations are arch-agnostic so the include
path should not be arch/.
Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
