Emlid Neutis N5 is a SoM based on Allwinner H5, has a WiFi & BT
module, DDR3 RAM and eMMC.
- add neutis n5 dtsi file for SoM needs
- add neutis devboard dts file
- add neutis devboard target to dtb makefile
Signed-off-by: Aleksandr Aleksandrov <aleksandr.aleksandrov@emlid.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Add vendor Emlid Ltd to vendor-prefixes.txt
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Aleksandr Aleksandrov <aleksandr.aleksandrov@emlid.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The Orange Pi Plus board lacks voltage scaling capabilities in its
current form. This results in random freezes during boot when cpufreq is
enabled, probably due to wrong voltages.
This patch (more or less copy/paste from 06139c) does the following
things on this board:
- enable r_i2c
- add sy8106a to the r_i2c bus
- have the sy8106a regulate VDD of cpu
Since the Orange Pi Plus has the same PMU setup as the Orange Pi PC, I
simply took min/max/fixed/ramp from the latter DTS. In that file the
origin of the values are described by the following comment:
"The datasheet uses 1.1V as the minimum value of VDD-CPUX,
however both the Armbian DVFS table and the official one
have operating points with voltage under 1.1V, and both
DVFS table are known to work properly at the lowest
operating point.
Use 1.0V as the minimum voltage instead."
I have tested this on patch two Orange Pi Plus boards, by running a
kernel with this patch and do intermettent runs of cpuburn while
monitoring voltage, frequency and temperature. The board runs stable
across its operatiing points while showing a reasonable (< 40C)
temperature. My Orange Pi PC, when put to the same test, yields similar
stable results.
Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Backlight power is controlled by PH6 GPIO, so add corresponding
regulator-fixed node for it. Otherwise backlight won't light up
if bootloader doesn't enable it.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The actual hardware has 4 data lines. Use them.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner H6 SoC is paired with the X-Powers AXP805 PMIC
connected via I2C.
Enable the driver for this PMIC.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # OPI-1+
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
In the user manual of A64 SoC, the bit 22 and 23 of pll-mipi control
register is called "LDO{1,2}_EN", and according to the BSP source code
from Allwinner , the LDOs are enabled during the clock's enabling
process.
The clock failed to generate output if the two LDOs are not enabled.
Add the two bits to the clock's gate bits, so that the LDOs are enabled
when the PLL is enabled.
Fixes: c6a0637460 ("clk: sunxi-ng: Add A64 clocks")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
option that is set by DOCG3 breaks setting variable parameters for any
other users of the BCH library code.
The only other user we have today is the MTD_NAND software BCH
implementation (most flash controllers use hardware BCH these days
and are not affected). I considered removing BCH_CONST_PARAMS entirely
because of the inherent conflict, but according to the description in
lib/bch.c there is a significant performance benefit in keeping it.
To avoid the immediate problem of the conflict between MTD_NAND_BCH
and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
is disabled, which should fix the problem for all cases that
are affected. This should also work for all stable kernels.
Note that there is only one machine that actually seems to use the
DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
the driver disabled, but it almost certainly shows up if we wanted
to test random kernels on machines that use software BCH in MTD.
Fixes: d13d19ece3 ("mtd: docg3: add ECC correction code")
Cc: stable@vger.kernel.org
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
On some SoCs(e.g. MX7ULP), GPIO clock is gatable and maybe
disabled by default. Users have to make sure it's enabled before
being able to access controller registers, otherwise an external
abort error may occur. Let's add the optional clocks property to
handle this case.
For ULP GPIO clock, it includes two separate clocks: one is for
GPIO controller Input/Output function clock while another is
GPIO port control clock for interrupt function.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: linux-gpio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiod_request_commit() copies the pointer to the label passed as
an argument only to be used later. But there's a chance the caller
could immediately free the passed string(e.g., local variable).
This could trigger a use after free when we use gpio label(e.g.,
gpiochip_unlock_as_irq(), gpiochip_is_requested()).
To be on the safe side: duplicate the string with kstrdup_const()
so that if an unaware user passes an address to a stack-allocated
buffer, we won't get the arbitrary label.
Also fix gpiod_set_consumer_name().
Signed-off-by: Muchun Song <smuchun@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Trivial fix to clean up an indentation issue, remove space
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Keeping the irq_chip definition static will make it shared with multiple
giochips in the system. This practice is considered to be bad and now we
will get the below warning from gpiolib core:
"detected irqchip that is shared with multiple gpiochips: please fix the
driver."
Hence, move the irq_chip definition from static to `struct pl061` for
using a unique irq_chip for each gpiochip.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is hardly any reason to call devm_gpiochip_remove() because the
driver core handles calling gpiochip_remove() automatically.
To make it harder to introduce new (and probably unneeded) callers, drop
the function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch masks the read inputs with the word mask in order to ensure
only requested input states are returned in the bits array.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With a new subsystem co-maintainer on board it is good to draw
up the ongoing changes and future plans for the subsystem, i.e.
what is in my head and being worked on long term.
What better way is there than simply adding a TODO right in the
code and send it out to the mailing list.
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The backlight is for the eDP panel and it has the connector on the excavator baseboard.
Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
After commit 88ba95bedb ("backlight: pwm_bl: Compute brightness of LED
linearly to human eye") the pwm_bl driver is able to calculate a default
brightness table. The calculated table for this PWM will have more
granularity and will be adjusted to change the brightness linearly to
the human eye. Use that table instead of have a DT-defined table with
less granularity.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In order to use earlycon, the stdout-path property needs to be set
in the chosen node.
Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
eMMC that's sold by Pine64 can do HS200, rk3328 can do it
as well, so update DTS to enable it.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Sapphire board has a 12V fan. So, adding it to the DTS.
There is no power supply directly connected, it needs the baseboard to
work.
If the board is used standalone then a hardware modification is needed.
On the Sapphire board there is an unpopulated resistor to connect it to
VBUS_TYPEC, which is usually 5V (too low) and can range up to 20V
(too high).
I tested it for a week connected to VCC_SYS which is 8.4V and proved to
be more than enough for the required cooling needs. This is the
connection described in the comment.
Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add spi dma channels as specified by the rk3399 TRM.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Since connectors can be created dynamically, fbdev should be initialized
even if there are no connectors at the moment. Otherwise fbdev will
not be created even after connector's appearance.
The patch fixes lack of fbdev on rinato and trats boards.
Fixes: 6afb7721e2 ("drm/exynos: move connector creation to attach callback")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DSI device can be attached after DRM device is registered. In such
case newly created connector must be registered by exynos_dsi.
The patch fixes exynos_drm on rinato and trats boards.
Fixes: 6afb7721e2 ("drm/exynos: move connector creation to attach callback")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This reverts commit 0586feba32
This patch makes it to need get_vblank_counter callback in crtc
to get frame counter from decon driver.
However, drm_dev->max_vblank_count is a member unique to
vendor's DRM driver but in case of ARM DRM, some CRTC devices
don't provide the frame counter value. As a result, this patch
made extension and clone mode not working.
Instead of this patch, we may need separated max_vblank_count
which belongs to each CRTC device, or need to implement frame
counter emulation for them who don't support HW frame counter.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The of_drm_find_panel() function returns error pointers and never NULL
but we the driver assumes that ->panel is NULL when it's not present.
Fixes: 6afb7721e2 ("drm/exynos: move connector creation to attach callback")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
When the performance governor is set as default, the rock960 hangs
around one minute after booting, whatever the activity is (idle, key
pressed, loaded, ...).
Based on the commit log found at https://patchwork.kernel.org/patch/10092377/
"vdd_log has no consumer and therefore will not be set to a specific
voltage. Still the PWM output pin gets configured and thence the vdd_log
output voltage will changed from it's default. Depending on the idle
state of the PWM this will slightly over or undervoltage the logic supply
of the RK3399 and cause instability with GbE (undervoltage) and PCIe
(overvoltage). Since the default value set by a voltage divider is the
correct supply voltage and we don't need to change it during runtime we
remove the rail from the devicetree completely so the PWM pin will not
be configured."
After removing the vdd-log from the rock960's specific DT, the board
does no longer hang and shows a stable behavior.
Apply the same change for the rock960 by removing the vdd-log from the
DT.
Fixes: 874846f1fc ("arm64: dts: rockchip: add 96boards RK3399 Ficus board")
Cc: stable@vger.kernel.org
Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The first group of warnings is caused by a "/**" kernel-doc notation
marker but the function comments are not in kernel-doc format.
Also add another error return value here.
../kernel/resource.c:337: warning: Function parameter or member 'start' not described in 'find_next_iomem_res'
../kernel/resource.c:337: warning: Function parameter or member 'end' not described in 'find_next_iomem_res'
../kernel/resource.c:337: warning: Function parameter or member 'flags' not described in 'find_next_iomem_res'
../kernel/resource.c:337: warning: Function parameter or member 'desc' not described in 'find_next_iomem_res'
../kernel/resource.c:337: warning: Function parameter or member 'first_lvl' not described in 'find_next_iomem_res'
../kernel/resource.c:337: warning: Function parameter or member 'res' not described in 'find_next_iomem_res'
Add the missing function parameter documentation for the other warnings:
../kernel/resource.c:409: warning: Function parameter or member 'arg' not described in 'walk_iomem_res_desc'
../kernel/resource.c:409: warning: Function parameter or member 'func' not described in 'walk_iomem_res_desc'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: b69c2e20f6 ("resource: Clean it up a bit")
Link: http://lkml.kernel.org/r/dda2e4d8-bedd-3167-20fe-8c7d2d35b354@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The NPU IOMMU is setup to mirror the parent PCIe device IOMMU
setup. Therefore it does not make sense to call dma operations such as
dma_map_page(), etc. directly on these devices. The existing dma_ops
simply print a warning if they are ever called, however this is
unnecessary and the warnings are likely to go unnoticed.
It is instead simpler to remove these operations and let the generic
DMA code print warnings (eg. via a NULL pointer deref) in cases of
buggy drivers attempting dma operations on NVLink devices.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
dma_slave_config direction was marked as deprecated quite some
time back, remove the usage from this driver so that the field
can be removed
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The LX2160A QorIQ Development System (QDS) is a test, evaluation, and
development platform, supporting QorIQ LX2160A processor.
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Drop reg property from fixed regulator and remove the unncessary bus
node.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This would help us to get early boot logs by passing "earlycon" to
kernel bootargs.
Further, by adding this we don't have to depend on complex earlyprintk
configs for early boot logs.
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shyam Saini <shyam.saini@amarulasolutions.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
