After many years of struggle, commit fa2d0aa969 ("mmc: core: Allow
setting slot index via device tree alias") finally allows the use of
aliases to number SD/MMC slots. Let's do that for sc7180 SoCs so that
if eMMC and SD are both used they have consistent numbers across boots
and kernel changes.
Picking numbers can be tricky. Do we call these "1" and "2" to match
the name in documentation or "0" and "1" with the assertion that we
should always start at 0 and count up?
While the "start counting at 0" makes sense if there are not already
well-defined numbers for all sd/mmc controllers, in the case of sc7180
there _are_ well defined numbers. IMO it is less confusing to use
those and match the docs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201111073652.1.Ia5bccd9eab7d74ea1ea9a7780e3cdbf662f5a464@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add device tree support for Microsoft Lumia 950 XL smartphone.
It is based on the msm8994 chipset and is able to boot Linux
using a custom EDK2 implementation. EL2 core startup is possible
with spin-table, but for now, we'll stick with PSCI.
The board currently supports:
* Screen console via EFIFB
* SDHCI
* I2C
* UART
* PSCI core bringup
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20201005150313.149754-12-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add configs for lazor rev2 and rev3. There are no relevant deltas
between rev1 and rev2, so just add the rev2 compatible string to the
rev1 config.
One important delta in rev3 is a switch of the power supply for the
onboard USB hub from 'pp3300_l7c' to 'pp3300_a' + a load switch. The
actual regulator switch is done by the patch 'arm64: dts: qcom:
sc7180-trogdor: Make pp3300_a the default supply for pp3300_hub',
since it affects the entire trogdor platform. Here we only add the
.dts files for lazor rev3 and replace the generic compatible entries
in the rev1 .dts files.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20201106140125.v3.1.I5a75056d573808f40fed22ab7d28ea6be5819f84@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20201016090833.1892-3-thunder.leizhen@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We want userspace to represent the human perceived brightness.
Since the led drivers and the leds themselves don't have a
linear response to the value we give them in terms of perceived
brightness, we'll bake the curve into the dts.
The panel also doesn't have a good response under 5%, so we'll avoid
sending it anything lower than that.
Note: Ideally this patch should be coupled with the driver change from
"backlight: pwm_bl: Fix interpolation", but it can work without it,
without looking too ugly.
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Alexandru Stan <amstan@chromium.org>
Link: https://lore.kernel.org/r/20201021220404.v3.2.Ie4d84af5a85e8dcb8f575845518fa39f324a827d@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
When the chip select line is controlled by the QUP, changing CS is a
time consuming operation. We have to send a command over to the geni
and wait for it to Ack us every time we want to change (both making it
high and low). To send this command we have to make a choice in
software when we want to control the chip select, we have to either:
A) Wait for the Ack via interrupt which slows down all SPI transfers
(and incurrs extra processing associated with interrupts).
B) Sit in a loop and poll, waiting for the Ack.
Neither A) nor B) is a great option.
We can avoid all of this by realizing that, at least on some boards,
there is no advantage of considering this line to be a geni line.
While it's true that geni _can_ control the line, it's also true that
the line can be a GPIO and there is no downside of viewing it that
way. Setting a GPIO is a simple MMIO operation.
This patch provides definitions so a board can easily select the GPIO
mode.
NOTE: apparently, it's possible to run the geni in "GSI" mode. In GSI
the SPI port is allowed to be controlled by more than one user (like
firmware and Linux) and also the port can operate sequences of
operations in one go. In GSI mode it _would_ be invalid to look at
the chip select as a GPIO because that would prevent other users from
using it. In theory GSI mode would also avoid some overhead by
allowing us to sequence the chip select better. However, I'll argue
GSI is not relevant for all boards (and certainly not any boards
supported by mainline today). Why?
- Apparently to run a SPI chip in GSI mode you need to initialize it
(in the bootloader) with a different firmware and then it will
always run in GSI mode. Since there is no support for GSI mode in
the current Linux driver, it must be that existing boards don't have
firmware that's doing that. Note that the kernel device tree
describes hardware but also firmware, so it is legitimate to make
the assumption that we don't have GSI firmware in a given dts file.
- Some boards with sc7180 have SPI connected to the Chrome OS EC or
security chip (Cr50). The protocols for talking to cros_ec and cr50
are extremely complex. Both drivers in Linux fully lock the bus
across several distinct SPI transfers. While I am not an expert on
GSI mode it feels highly unlikely to me that we'd ever be able to
enable GSI mode for these devices.
From a testing perspective, running "flashrom -p ec -r /tmp/foo.bin"
in a loop after this patch shows almost no reduction in time, but the
number of interrupts per command goes from 32357 down to 30611 (about
a 5% reduction).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Akash Asthana <akashast@codeaurora.org>
Link: https://lore.kernel.org/r/20200921142655.v3.1.I997a428f58ef9d48b37a27a028360f34e66c00ec@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
s1 (VDDCX) and l3 (VDDMX) are now managed by rpmpd as power domains.
This allows us to vote for voltage corners instead of voting for raw
voltages. But we cannot manage these as regulator and power domain at
the same time: The votes by rpmpd would conflict with the ones from
the regulator driver.
All users of these regulators have been converted to power domains.
Make sure that no new users are added by removing s1 and l3 from
the regulator definitions.
This also allows us to remove the arbitrary voltage constraints
we have been using for these regulators. Not all of the voltages
listed there would actually have been safe for the boards.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-11-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
So far we have been making proxy votes for the remote processors
through the regulator interface. Now that we have rpmpd it's better
to vote for performance states through the power domain interface.
This also allows us to move these supplies back to msm8916.dtsi
because the device tree binding for RPMPD is independent of the
underlying regulator/PMIC.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-10-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
MSM8916 has two RPM power domains: VDDCX and VDDMX.
So far we have been managing them by voting for raw voltages through
the regulator subsystem, but it's better to manage them with corners
as actual power domains.
Add the device tree node for rpmpd so we can manage them as real
power domains instead of using the regulators.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In commit e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number
of interconnect cells") we missed increasing the cells on one
interconnect. That's no bueno. Fix it.
NOTE: it appears that things aren't totally broken without this fix,
but clearly something isn't going to be working right. If nothing
else, without this fix I see this in the logs:
OF: /soc@0/mdss@ae00000: could not get #interconnect-cells for /soc@0/interrupt-controller@17a00000
Fixes: e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number of interconnect cells")
Reviewed-by: Georgi Djakov <georgi.djakov@linaro.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201001141838.1.I08054d1d976eed64ffa1b0e21d568e0dc6040b54@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
