commit fefe948bd273 ("karo: fdt: support 'panel-dpi' in DT")
inadvertedly copies the 'phandle' property from the 'display-timing'
node. This creates a new property in the 'panel-timing' node which
invalidates all FDT offsets being used by the
karo_fixup_panel_timing() routine.
Add a whitelist of properties to copy and recalculate all FDT offsets
after possible creation of a new property in the panel-timing node.
Also delete properties in the panel-timing node that don't exist in
the display-timings node.
Fixes: fefe948bd273 ("karo: fdt: support 'panel-dpi' in DT")
Andy Shevchenko [Fri, 29 Nov 2019 17:47:59 +0000 (19:47 +0200)]
gcc-9: silence 'address-of-packed-member' warning
GCC 9.x starts complaining about potential misalignment of the pointer to
the array (in this case alignment=2) in the packed (alignment=1) structures.
Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel.
Original commit message:
We already did this for clang, but now gcc has that warning too.
Yes, yes, the address may be unaligned. And that's kind of the point.
This in particular hides the warnings like
drivers/usb/gadget/composite.c:545:23: warning: taking address of packed member of ‘struct usb_string_descriptor’ may result in an unaligned pointer value [-Waddress-of-packed-member]
545 | collect_langs(sp, s->wData);
drivers/usb/gadget/composite.c:550:24: warning: taking address of packed member of ‘struct usb_string_descriptor’ may result in an unaligned pointer value [-Waddress-of-packed-member]
550 | collect_langs(sp, s->wData);
drivers/usb/gadget/composite.c:555:25: warning: taking address of packed member of ‘struct usb_string_descriptor’ may result in an unaligned pointer value [-Waddress-of-packed-member]
555 | collect_langs(sp, s->wData);
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Lothar Waßmann [Tue, 16 Jun 2020 07:08:54 +0000 (09:08 +0200)]
karo: fdt: support 'panel-dpi' in DT
Check, if the LCD panel's compatible string is 'panel-dpi' and fill in
the 'panel-timing' data from the display-timings node selected by the
'video_mode' variable.
Tom Rini [Mon, 29 Feb 2016 16:34:15 +0000 (11:34 -0500)]
compiler*.h: sync include/linux/compiler*.h with Linux 4.5-rc6
Copy these from Linux v4.5-rc6 tag.
This is needed so that we can keep up with newer gcc versions. Note
that we don't have the uapi/ hierarchy from the kernel so continue to
use <linux/types.h>
Lothar Waßmann [Thu, 9 May 2019 13:41:59 +0000 (15:41 +0200)]
karo: common: remove '_' from DT property names
DT property names should not contain underscores but dashes as word
delimiters. The DT files in Linux have been updated to reflect this.
For compatibility with older DTBs support both variants of certain
property names.
Lothar Waßmann [Wed, 30 Jan 2019 12:25:45 +0000 (13:25 +0100)]
karo: txul: fix LDO4 output voltage
Currently the LDO4 which supplies the pins of the CSI interface is
programmed for a voltage of 1.8V (default setting for this LDO of the
RN5T567).
Change this to 3.3V to match the specification of the TXUL modules.
Also configure the sleep state voltages for the LDOs.
Lothar Waßmann [Mon, 8 Jan 2018 12:21:28 +0000 (13:21 +0100)]
karo: txul: remove i2c_gpio_pads
The I2C bus for accessing the PMIC uses the soft I2C driver via GPIO
pins. There is no need for reconfiguring the pads for I2C recovery and
no need for a special i2c_gpio_pads definition.
Lothar Waßmann [Mon, 8 Jan 2018 12:14:01 +0000 (13:14 +0100)]
karo: tx6: change drive strength of Ethernet related pads to improve EMC
EMC measurements have revealed excessive noise at multiples of the
50MHz ethernet reference clock on TX6 modules. Changing the drive
strength of the ENET_REF_CLK pad vastly reduces this noise and
improves the signal waveform substanitally.
On TXUL also the MDC and MDIO pads contribute to this noise, since
they are routed off-board for connecting an optional second ethernet
PHY. Adjusting the drive strength for those pads on the TXUL modules
also improves the signal quality and reduces EMI.
Lothar Waßmann [Mon, 8 Jan 2018 11:47:34 +0000 (12:47 +0100)]
imx: mx6: align the SPEED_MED setting with the reset default
The PAD_CTL SPEED settings 0x1 and 0x2 both designate 'Medium
Speed'. The PAD_CTL register HW reset default value is '0x2' for
most pads, so use this value for the PAD_CTL_SPEED_MED definition.
This partially reverts commit 9b2cc7dbfd46 ("imx: mx6 add
PAD_CTL_SPEED_LOW for i.MX6SX/UL") which inadvertently changed the
definition from '2' to '1'.
karo: tx6: prevent DTB from either being out of reach of kernel or overwritten during uncompress
The current setting of fdtaddr and fdt_high has proven to be
inappropriate in that either the FDT may be out of reach of the
kernel or may be overwritten by the uncompressing Linux kernel.
Set fdt_high to an offset of 256MiB from SDRAM start, so that it is
valid for any board regardless of memory size while preventing the
described problems.
Lothar Waßmann [Fri, 23 Dec 2016 11:56:32 +0000 (12:56 +0100)]
karo: tx6: support MIPI variant in board name
The TX6Q-1230 is physically the same as TX6Q-1030 with the
distinction, that the MIPI interface is used rather than the LCD
interface. This is only a cosmetic change to adjust the displayed
board name.
Lothar Waßmann [Thu, 30 Jun 2016 13:40:18 +0000 (15:40 +0200)]
mxs_gpio: correctly use the GPIO API
The GPIO API expects a linear GPIO number as parameter to the gpio_*()
functions. The current implementation of the mxs_gpio driver operates on
iomux_cfg_t cookies instead. Therefore the 'gpio' command cannot be
used with this driver.
Change the driver to implement the correct API and introduce some
checks to catch users that still use the old semantics.
1. assert the most sigificant bit in the iomux_cfg_t pad definitions,
so that using such a cookie in place of a GPIO number will
decisively generate an invalid GPIO number and flag an error at runtime.
2. introduce a compile switch CONFIG_MXS_IOMUX_COMPILE_CHECK to make
the iomux_cfg_t cookie a 64 bit variable, so that passing an
iomux_cfg_t value to a gpio_*() function will generate a compile
time error.
Lothar Waßmann [Wed, 29 Jun 2016 09:06:58 +0000 (11:06 +0200)]
fs/fs.c: correctly interpret the '(max)len' parameter to fs_read()
The 'len' parameter passed to fs_read() actually denotes the maximum
number of bytes that fit into the callers buffer, not an expected
amount of data to be read.
Rename the parameter accordingly and honor the maxlen requested by the
caller appropriately.
Also remove the bogus warning message printed when the number of bytes
read is smaller than maxlen.
Lothar Waßmann [Wed, 29 Jun 2016 08:46:49 +0000 (10:46 +0200)]
common/cmd_misc.c: fix return code of sleep command
-1 is equivalent to CMD_RET_USAGE and makes the sleep command print
its usage information when aborted by <CTRL-C> which is most probably
not intended.
The I2C access to the PMIC requires the TAMPER pins of the i.MX6UL to
be useable as GPIOs. This is only possible after the TAMPER_PIN_DISABLE
fuses are programmed which is usually done via U-Boot.
Resolve this catch 22 situation by disabling the PMIC in the '_noenv'
U-Boot variant which is usually used in the manufacturing
environment.