The Olinuxino board uses DDR3L chips which are supposed to be driven
with 1.35V. The reset default of the AXP is properly set to 1.36V.
While technically the chips can also run at 1.5 volts, changing the
voltage on the fly while booting Linux is asking for trouble. Also
running at a lower voltage saves power.
So fix the DCDC5 value to match the actual board design.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Martin Lucina <martin@lucina.net>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win board uses the AXP's ALDO1 power rail to drive the
VCC-CSI line, which, according to the schematic, needs to be set to 2.8V.
Also the ELDO3 power rail is connected to the CSI, with somewhat unclear
voltage requirements. Add this regulator and allow the voltage to be set
between 1.5V and 1.8V, which are the voltages mentioned in the
schematic.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win comes with 2 MB SPI flash, add the node.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win features a soldered WiFi chip on the board, connected
via the SDIO interface. Add the required DT nodes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has a green status LED, add the DT node for it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win exposes several UARTs on header pins, and connects one
to the on-board WiFi/Bluetooth chip.
Add the pinmux definitions to the UART nodes, but keep them disabled.
Enable the UART1, which is wired to the Bluetooth chip, and add a serdev
node. There is no binding for the BT8723 yet, so leave this mostly empty
for now.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has the usual Gigabit PHY connected to the EMAC.
Its power is controlled by GPIO PD14.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has a micro USB-B socket, connected to the SoC's
USB-OTG port. Its power is supplied by the AXP PMIC, and the ID pin is
connected to GPIO PH9. It can serve both as a host or a client port.
Add the respective DT nodes to enable it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
[wens@csie.org: enable paired EHCI/OHCI device nodes and regulator supply]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has four standard USB-A sockets, connected to an
on-board USB hub. The hub's and socket's power regulators are enabled by
GPIO PD7.
Add the regulator to the DT to enable the power supply.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has a microSD card slot which is connected via all
four SD data lines. As the DT was not mentioning this fact, we got the
default single bit transfers, losing out on performance.
Also, as microSD does not have a write protect switch, we disable this
feature in the DT node.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Pine64-LTS is a variant of the Pine64 board, from the software
visible side resembling a SoPine module on a baseboard, though the
board has the SoC and DRAM integrated on one PCB.
Due to this it basically shares the DT with the SoPine baseboard, which
we mimic in our DT by inclucing the boardboard .dts into the new file,
just overwriting the model name.
Having a separate .dts for this seems useful, since we don't know yet if
there are subtle differences between the two. Also the SoC on the LTS
board is technically an "R18" instead of the original "A64", although as
far as we know this is just a relabelled version of the original SoC.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Current kernels complain when booting on an A64 Soc:
....
[ 1.904297] cacheinfo: Unable to detect cache hierarchy for CPU 0
....
Not a real biggie on this flat topology, but also easy enough to fix.
Add the L2 cache node and let each CPU point to it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Currently the enabled MMC controllers on Pine H64 do not have bus-width
set, which make them fall back to 1-bit mode and become quite slow.
Fix this by add the corresponding bus-width properties.
Fixes: ecbd611882 ("arm64: allwinner: h6: enable MMC0/2 on Pine H64")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Another user of cd-inverted seems to have crept in. Switch it away from
cd-inverted to be consistent with other sunxi boards.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
It may happen that clock framework finds optimal video PLL rate above
that which is really supported by HW.
User manual doesn't really say what is upper limit for video PLLs on
A83T. Because of that, use the maximum rate defined in BSP clk driver
which is 3 GHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Some, if not most, NKMP PLLs can be set to higher rate that is really
supported by HW.
Implement support for maximum frequency constrain for NKMP PLLs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Video PLLs on R40 can be set to higher rate that it is actually
supported by HW.
Limit maximum rate to 1008 MHz. This is the maximum allowed rate by BSP
clock driver. Interestengly, user manual specifies maximum frequency to
be 600 MHz. Historically, this data was wrong in some user manuals for
other SoCs, so more faith is put in BSP clock driver.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
As it turns out, pll-video can be set to higher rate that it is really
supported by HW.
For example, one monitor requested 185.58 MHz pixel clock. Clock
framework calculated that minimum rate error would be when pll-video
is set to 2040 MHz. This is clearly out of specs.
Both H3 and H5 user manuals specify 600 MHz as maximum supported rate.
However, BSP clock drivers allow up to 912 MHz and 1008 MHz
respectively. Here 912 MHz is chosen because user manuals were already
proven wrong once for lower limits.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
On some NM PLLs, frequency can be set above PLL working range.
Add a constraint for maximum supported rate. This way, drivers can
specify which is maximum allowed rate for PLL.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Another user of cd-inverted seems to have crept in. Switch it away from
cd-inverted to be consistent with other sunxi boards.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The A64 have a SID controller which consist of EFUSE (starting at 0x200)
and three registers to read/write some of the protected efuses.
Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
imx6sl-evk, imx6sll-evk and imx6sx-sdb boards use a Seiko 43WVF1G panel.
Now that the DRM mxsfb driver is the one selected by default, let's
also select CONFIG_DRM_PANEL_SEIKO_43WVF1G so that these boards continue
to have a working display by default.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx23-evk and imx28-evk boards use a Seiko 43WVF1G panel.
Now that the DRM mxsfb driver is the one selected by default, let's
also select CONFIG_DRM_PANEL_SEIKO_43WVF1G so that these boards continue
to have a working display by default.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx23-evk board has a Seiko 43WVF1G parallel display.
Instead of hardcoding the display timings in the device tree, use
the "sii,43wvf1g" compatible instead.
This aligns with the new mxsfb bindings scheme documented at:
Documentation/devicetree/bindings/display/mxsfb.txt
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
It is recommended to place regulators outside simple-bus, so move them
accordingly.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx28-evk board has a Seiko 43WVF1G parallel display.
Instead of hardcoding the display timings in the device tree, use
the "sii,43wvf1g" compatible instead.
This aligns with the new mxsfb bindings scheme documented at:
Documentation/devicetree/bindings/display/mxsfb.txt
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
It is recommended to place regulators outside simple-bus, so move them
accordingly.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This reverts commit 1c86c9dd82.
That commit followed the reference manual but unfortunately the imx7d
manual is incorrect.
Tested with ath9k pcie card and confirmed internally.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Fixes: 1c86c9dd82 ("ARM: dts: imx7d: Invert legacy PCI irq mapping")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
If the xen bus exists but does not expose the proper interface, it is
possible to get a non-zero length but still some error, leading to
strcmp failing trying to load invalid memory addresses e.g.
fffffffffffffffe.
There is then no need to check length when there is no error, as the
xenbus driver guarantees that the string is nul-terminated.
Link: http://lkml.kernel.org/r/1534236007-10170-1-git-send-email-asmadeus@codewreck.org
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>
If the destination of the rename(2) system call exists, the inode's
link count (i_nlinks) must be non-zero. If it is, the inode can end
up on the orphan list prematurely, leading to all sorts of hilarity,
including a use-after-free.
https://bugzilla.kernel.org/show_bug.cgi?id=200931
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: stable@vger.kernel.org
The following patch introduced an issue.
commit f6206f00d8 ("dmaengine: mic_x100_dma: use the new helper to simplify the code")
This issue is :
kfree(mic_dma_dev)
.....
dma_async_device_unregister(mic_dma_dev->device);
Free the memory, and use it again.
So use devm_kzalloc to allocate mic_dma_dev to fix it.
When the Devres try to release the resources, it will call release at the
following order:
dma_async_device_unregister(mic_dma_dev->device);
.....
kfree(mic_dma_dev)
Fixes: f6206f00d8 ("dmaengine: mic_x100_dma: use the new helper to simplify the code")
Signed-off-by: Huang Shijie <sjhuang@iluvatar.ai>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In __snd_pcm_lib_xfer(), when capture, if state is PREPARED
and size is less than start_threshold nothing can be done.
As there is no error, 0 is returned.
Signed-off-by: Ricardo Biehl Pasquali <pasqualirb@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This suppresses some false positives in gcc 8's -Wstringop-truncation
Suggested by Miguel Ojeda (hopefully the __nonstring definition will
eventually get accepted in the compiler-gcc.h header file).
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
As part of sdw_stream_remove_master(), sdw_stream_remove_slave() is called
which results in bus lock being acquired twice.
So, fix it by performing specific Slave remove operations in
sdw_release_master_stream() instead of calling sdw_stream_remove_slave().
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In sdw_stream_add_master() after the Master ports are configured,
the stream is released incorrectly.
So, fix it by avoiding stream release after configuring the Master
for the stream.
While at it, rename the label appropriately.
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For a SoundWire stream it is expected that a Slave is added to the
stream before Master is added.
So, move the stream state to CONFIGURED after the first Slave is
added and remove the stream state assignment for Master add.
Along with these changes, add additional comments to explain the same.
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In case of error, we can dereference uninitialized 'adev'
drivers/soundwire/intel_init.c:154 sdw_intel_acpi_cb()
error: uninitialized symbol 'adev'.
Fix that by not using adev for warn print and make it pr_err.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
To support multi link on Intel platforms, we need to update
SDW SHIM registers.
So, add pre/post bank switch ops for the same in Intel driver.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
A multi link bankswitch can be done if the hardware supports and
the stream is handled by multiple Master(s).
This preparatory patch adds support to track m_rt in a stream.
Modifying m_rt_count and usage is added as part of the next patch.
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In cases of multiple Masters in a stream, synchronization
between multiple Master(s) is achieved by performing bank switch
together and using Master methods.
Add sdw_ml_bank_switch() to wait for completion of bank switch.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For each SoundWire stream operation, we need to parse master
list and operate upon all master runtime.
This is a preparatory patch to do the boilerplate conversion
of stream handling from single master runtime to handle a
list of master runtime. The code to support bank switch for
multiple master instances is added in the next patch.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Currently, the stream concept is limited to single Master and one
or more Codecs.
This patch extends the concept to support multiple Master(s)
sharing the same reference clock and synchronized in the hardware.
Modify sdw_stream_runtime to support a list of sdw_master_runtime
for the same. The existing reference to a single m_rt is removed
in the next patch.
Typically to lock, one would acquire a global lock and then lock
bus instances. In this case, the caller framework(ASoC DPCM)
guarantees that stream operations on a card are always serialized.
So, there is no race condition and hence no need for global lock.
Bus lock(s) are acquired to reconfigure the bus while the stream
is set-up.
So, we add sdw_acquire_bus_lock()/sdw_release_bus_lock() APIs which
are used only to reconfigure the bus.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Deferred messages are async messages used to synchronize
transitions mostly while doing a bank switch on multi links.
On successful transitions these messages are marked complete
and thereby confirming that all the buses performed bank switch
successfully.
So, initialize the completion structure for the same.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add example and documentation to describe multi link streams
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Shreyas NC <shreyas.nc@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add new device IDs for family 17h, models 10h-2fh.
This is required by amd64_edac_mod in order to properly detect PCI
device functions 0 and 6.
Signed-off-by: Michael Jin <mikhail.jin@gmail.com>
Reviewed-by: Yazen Ghannam <Yazen.Ghannam@amd.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180816192840.31166-1-mikhail.jin@gmail.com
Signed-off-by: Borislav Petkov <bp@suse.de>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the
vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by
a special output only gpio pin labeled "gpiomut_pmuio_iout",
corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&grf_gpio 0>, thanks to the
gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Adding a GRF GPIO controller labled "grf_gpio" to rk3328, currently
providing access to the GPIO_MUTE pin, which is manupulated by the
GRF_SOC_CON10 register.
The GPIO_MUTE pin is referred to as <&grf_gpio 0>.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
[dropped default-status disabled]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
It is necessary for the io domain setting of the SoC to match the voltage
supplied by the regulators.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
