src/acpi to src/lib: Fix spelling errors
These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
@@ -758,7 +758,7 @@ struct device_tree_node *dt_find_compat(struct device_tree_node *parent,
|
||||
}
|
||||
|
||||
/*
|
||||
* Find the next compatible child of a given parent. All children upto the
|
||||
* Find the next compatible child of a given parent. All children up to the
|
||||
* child passed in by caller are ignored. If child is NULL, it considers all the
|
||||
* children to find the first child which is compatible.
|
||||
*
|
||||
|
@@ -433,7 +433,7 @@ detailed_block(struct edid *result_edid, unsigned char *x, int in_extension,
|
||||
|
||||
/*
|
||||
* Slightly weird to return a global, but I've never
|
||||
* seen any EDID block wth two range descriptors, so
|
||||
* seen any EDID block with two range descriptors, so
|
||||
* it's harmless.
|
||||
*/
|
||||
return 1;
|
||||
@@ -481,7 +481,7 @@ detailed_block(struct edid *result_edid, unsigned char *x, int in_extension,
|
||||
We have no samples between those values, so put a
|
||||
threshold at 95000 kHz. If we get anything over
|
||||
95000 kHz with single channel, we can make this
|
||||
more sofisticated but it's currently not needed.
|
||||
more sophisticated but it's currently not needed.
|
||||
*/
|
||||
out->mode.lvds_dual_channel = (out->mode.pixel_clock >= 95000);
|
||||
extra_info.x_mm = (x[12] + ((x[14] & 0xF0) << 4));
|
||||
@@ -1094,7 +1094,7 @@ int set_display_mode(struct edid *edid, enum edid_modes mode)
|
||||
}
|
||||
|
||||
/*
|
||||
* Given a raw edid bloc, decode it into a form
|
||||
* Given a raw edid block, decode it into a form
|
||||
* that other parts of coreboot can use -- mainly
|
||||
* graphics bringup functions. The raw block is
|
||||
* required to be 128 bytes long, per the standard,
|
||||
|
@@ -126,7 +126,7 @@ struct nhlt_format *nhlt_add_format(struct nhlt_endpoint *endp,
|
||||
wave->channel_mask = speaker_mask;
|
||||
memcpy(&wave->sub_format, &pcm_subformat, sizeof(wave->sub_format));
|
||||
|
||||
/* Calculate the dervied fields. */
|
||||
/* Calculate the derived fields. */
|
||||
wave->block_align = wave->num_channels * wave->bits_per_sample / 8;
|
||||
wave->bytes_per_second = wave->block_align * wave->samples_per_second;
|
||||
|
||||
|
@@ -9,7 +9,7 @@
|
||||
* A region file provides generic support for appending new data
|
||||
* within a storage region. The book keeping is tracked in metadata
|
||||
* blocks where an offset pointer points to the last byte of a newly
|
||||
* allocated byte sequence. Thus, by taking 2 block offets one can
|
||||
* allocated byte sequence. Thus, by taking 2 block offsets one can
|
||||
* determine start and size of the latest update. The data does not
|
||||
* have to be the same consistent size, but the data size has be small
|
||||
* enough to fit a metadata block and one data write within the region.
|
||||
|
Reference in New Issue
Block a user