Based on 1 normalized pattern(s):
this software is licensed under the terms of the gnu general public
license version 2 as published by the free software foundation and
may be copied distributed and modified under those terms this
program is distributed in the hope that it will be useful but
without any warranty without even the implied warranty of
merchantability or fitness for a particular purpose see the gnu
general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 285 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141900.642774971@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds the necessary data for handling io voltage domains on PX30.
As interesting tidbit, the PX30 contains two separate iodomain areas.
One in the regular General Register Files (GRF) and one in PMUGRF in the
pmu power domain.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This driver creates a number of const structures that it stores in the
data field of an of_device_id array.
The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.
Furthermore, adding const to the declaration of the location that
receives a const value from such a field ensures that the compiler
will continue to check that the value is not modified. The
const-discarding cast on the extraction from the data field is
thus no longer needed.
Done using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This adds the necessary data for handling io voltage domains on the RV1108.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This adds the necessary data for handling io voltage domains on the rk3228.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This adds the necessary data for handling io voltage domains on the rk3328.
As interesting tidbit, the rk3328 only contains one iodomain area in the
regular General Register Files (GRF).
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When testing SD hotplug automatically, I got bunch of
useless log like this:
[ 588.357838] mmc0: card 0007 removed
[ 589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.500698] vccio_sd: ramp_delay not set
[ 589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.669705] rockchip-iodomain ff770000.syscon:io-domains: Setting to 3300000 done
[ 589.677593] vccio_sd: ramp_delay not set
[ 589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to 1800000 done
[ 590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully tuned phase to 140
[ 590.039725] mmc0: new ultra high speed SDR50 SDHC card at address 0007
[ 590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
[ 590.052163] mmcblk0: p1
Moreover the code is intent to print the 'uV' for debug but
later print it using dev_info. It looks more like to me that
it should be the real intention of the code. Anyway, let's
mark this verbose log as debug message.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
IO-domain handling is part of the general register files, so should live
under the grf directly. This change allows the grf to be a simple-mfd and
the io-domains fetching the syscon regmap from that parent-node.
The old binding is of course preserved, though deprecated.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The permissions of this file were modified by commit (f447671b9e PM /
AVS: rockchip-io: add io selectors and supplies for rk3399) by mistake,
so fix them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This adds the necessary data for handling io voltage domains on the rk3399.
As interesting tidbit, the rk3399 contains two separate iodomain areas.
One in the regular General Register Files (GRF) and one in PMUGRF in the
pmu power domain.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This adds the necessary data for handling io voltage domains on the rk3368.
As interesting tidbit, the rk3368 contains two separate iodomain areas.
One in the regular General Register Files (GRF) and one in PMUGRF in the
pmu power domain.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
IO domain voltages on some Rockchip SoCs are variable but need to be
kept in sync between the regulators and the SoC using a special
register.
A specific example using rk3288:
- If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
Said another way, this driver simply handles keeping bits in the SoC's
general register file (GRF) in sync with the actual value of a voltage
hooked up to the pins.
Note that this driver specifically doesn't include:
- any logic for deciding what voltage we should set regulators to
- any logic for deciding whether regulators (or internal SoC blocks)
should have power or not have power
If there were some other software that had the smarts of making
decisions about regulators, it would work in conjunction with this
driver. When that other software adjusted a regulator's voltage then
this driver would handle telling the SoC about it. A good example is
vqmmc for SD. In that case the dw_mmc driver simply is told about a
regulator. It changes the regulator between 3.3V and 1.8V at the
right time. This driver notices the change and makes sure that the
SoC is on the same page.
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman: fix compiler warnings]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Thomas Gleixner