omapdss: dss: Make overlay manager source selection possible for multiple DPI IPs
DRA7x has 3 DPI IPs, out of these DPI1 has a configurable source while the
others don't. Create a func which allows us to select sources for different DPI
instances.
A new dss feat struct is needed for DRA7x, add it.
Signed-off-by: Archit Taneja <archit@ti.com>
DRA7x has 3 DPI IPs, out of these DPI1 has a configurable source while the
others don't. Create a func which allows us to select sources for different DPI
instances.
A new dss feat struct is needed for DRA7x, add it.
Signed-off-by: Archit Taneja <archit@ti.com>
omapdss: Add DRA7XX as an OMAPDSS version
DRA7xx has a slightly modified version of the DSS on OMAP5. Create a new OMAPDSS
version for it. Use omap5 structs for inititalizations in dss features, dss and
dispc.
Signed-off-by: Archit Taneja <archit@ti.com>
DRA7xx has a slightly modified version of the DSS on OMAP5. Create a new OMAPDSS
version for it. Use omap5 structs for inititalizations in dss features, dss and
dispc.
Signed-off-by: Archit Taneja <archit@ti.com>
omapdss: dss: add module_id param to dpi_select_source
DRA7x SoC has 3 DPI instances. DPI1 instance can receive it's pixels from either
LCD1, LCD2, LCD3 or TV vverlay Manager's video ports. The remaining two DPI
instances can receive pixels only from LCD2 and LCD3 respectively.
Add an argument which describes which DPI instance we are referring to when
chosing it's overlay manager.
Signed-off-by: Archit Taneja <archit@ti.com>
DRA7x SoC has 3 DPI instances. DPI1 instance can receive it's pixels from either
LCD1, LCD2, LCD3 or TV vverlay Manager's video ports. The remaining two DPI
instances can receive pixels only from LCD2 and LCD3 respectively.
Add an argument which describes which DPI instance we are referring to when
chosing it's overlay manager.
Signed-off-by: Archit Taneja <archit@ti.com>
Merge remote-tracking branch 'av-feat-tree/omap5_audio_video-3.8.y' into vayu_exp
Conflicts:
arch/arm/boot/dts/omap5-sevm.dts
arch/arm/boot/dts/omap5-uevm.dts
arch/arm/boot/dts/omap5.dtsi
arch/arm/configs/omap2plus_defconfig
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
Signed-off-by: Archit Taneja <archit@ti.com>
Conflicts:
arch/arm/boot/dts/omap5-sevm.dts
arch/arm/boot/dts/omap5-uevm.dts
arch/arm/boot/dts/omap5.dtsi
arch/arm/configs/omap2plus_defconfig
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
Signed-off-by: Archit Taneja <archit@ti.com>
Merge branch 'pm-linux-2.8.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.8.y
TI-Feature: power_management
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-linux-3.8.y
* 'pm-linux-3.8.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree: (60 commits)
ARM: DRA7: dts: Remove the non existent l3_main_3 entry
ARM: DRA7: dpll: No freqsel on DRA7
ARM: DRA7: dpll: Lock GMAC PLL at boot
ARM: DRA7: dpll: Lock ABE PLL according to ATL needs
ARM: DRA7: id: Change control_id_code register address
thermal: consider emul_temperature while computing trend
ARM: OMAP5: Add select tuples to enable CPUFREQ on OMAP5
ARM: DRA7XX: PM: add soc_is_dra7xx check to take care of freqsel absence
ARM: dts: dra7: add clock nodes for CPU and link avs_mpu regulator to cpu
Arm: DRA7XX: Clock: Update dpll_mpu_ck_ops
ARM: DTS: DRA7: Link the actual TPS659038 regulators to
ARM: DTS: DRA7: Add avs class 0 regulator nodes
regulator: ti-avs-class0: use regulator name based on device instance
regulator: ti-avs-class0: dont reserve efuse memory offsets
cpufreq: cpufreq-cpu0: defer probe when regulator is not ready(v2)
regulator: core: return err value for regulator_get if there is no DT binding
ARM/dts: dra7-evm: Enable tps659038 on i2c1 bus
arm: dts: dra7: add I2C devices to dra7 DeviceTree file
arm: omap2plus_defconfig: enable DRA752 thermal support by default
arm: mach-omap2: flag DRA7 as having bandgap
...
Conflicts:
arch/arm/configs/omap2plus_defconfig
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: power_management
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-linux-3.8.y
* 'pm-linux-3.8.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree: (60 commits)
ARM: DRA7: dts: Remove the non existent l3_main_3 entry
ARM: DRA7: dpll: No freqsel on DRA7
ARM: DRA7: dpll: Lock GMAC PLL at boot
ARM: DRA7: dpll: Lock ABE PLL according to ATL needs
ARM: DRA7: id: Change control_id_code register address
thermal: consider emul_temperature while computing trend
ARM: OMAP5: Add select tuples to enable CPUFREQ on OMAP5
ARM: DRA7XX: PM: add soc_is_dra7xx check to take care of freqsel absence
ARM: dts: dra7: add clock nodes for CPU and link avs_mpu regulator to cpu
Arm: DRA7XX: Clock: Update dpll_mpu_ck_ops
ARM: DTS: DRA7: Link the actual TPS659038 regulators to
ARM: DTS: DRA7: Add avs class 0 regulator nodes
regulator: ti-avs-class0: use regulator name based on device instance
regulator: ti-avs-class0: dont reserve efuse memory offsets
cpufreq: cpufreq-cpu0: defer probe when regulator is not ready(v2)
regulator: core: return err value for regulator_get if there is no DT binding
ARM/dts: dra7-evm: Enable tps659038 on i2c1 bus
arm: dts: dra7: add I2C devices to dra7 DeviceTree file
arm: omap2plus_defconfig: enable DRA752 thermal support by default
arm: mach-omap2: flag DRA7 as having bandgap
...
Conflicts:
arch/arm/configs/omap2plus_defconfig
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Merge remote-tracking branch 'rnayak/platform-base-3.8.y' into pm-linux-3.8.y
Conflicts:
arch/arm/mach-omap2/dpll3xxx.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Conflicts:
arch/arm/mach-omap2/dpll3xxx.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: dts: Remove the non existent l3_main_3 entry
l3_main_3 does not exist on dra7xx devices.
We see the below errors at boot because of it..
[ 0.144775] platform ocp.2: Cannot lookup hwmod 'l3_main_3'
[ 0.145050] omap_l3_noc ocp.2: couldn't find resource 0
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
l3_main_3 does not exist on dra7xx devices.
We see the below errors at boot because of it..
[ 0.144775] platform ocp.2: Cannot lookup hwmod 'l3_main_3'
[ 0.145050] omap_l3_noc ocp.2: couldn't find resource 0
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: dpll: No freqsel on DRA7
With the growing number of devices which *do not* support freqsel,
stop extending the checks and have checks based on the only device
(343x) family that supports it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
With the growing number of devices which *do not* support freqsel,
stop extending the checks and have checks based on the only device
(343x) family that supports it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: dpll: Lock GMAC PLL at boot
Lock GMAC PLL as per the Vayu PLL spec v0.3.2. Without
the GMAC PLL locked, we see the below hwmod init failures
at boot
[ 1.254333] clock: dpll_gmac_ck failed transition to 'locked'
[ 1.256835] omap_hwmod: pruss1: cannot be enabled for reset (3)
[ 2.415313] clock: dpll_gmac_ck failed transition to 'locked'
[ 2.417724] omap_hwmod: pruss2: cannot be enabled for reset (3)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Lock GMAC PLL as per the Vayu PLL spec v0.3.2. Without
the GMAC PLL locked, we see the below hwmod init failures
at boot
[ 1.254333] clock: dpll_gmac_ck failed transition to 'locked'
[ 1.256835] omap_hwmod: pruss1: cannot be enabled for reset (3)
[ 2.415313] clock: dpll_gmac_ck failed transition to 'locked'
[ 2.417724] omap_hwmod: pruss2: cannot be enabled for reset (3)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: dpll: Lock ABE PLL according to ATL needs
The ATL (Audio Tracking Logic) module within DRA7xx requires a
precise 44.1Kz clock. The only possible source for it that can
supply the clock was found to be ABE PLL.
So lock the ABE PLL at 361.2670Mhz, so ATL module can derive the
precise 44.1Khz out of it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
The ATL (Audio Tracking Logic) module within DRA7xx requires a
precise 44.1Kz clock. The only possible source for it that can
supply the clock was found to be ABE PLL.
So lock the ABE PLL at 361.2670Mhz, so ATL module can derive the
precise 44.1Khz out of it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: id: Change control_id_code register address
The CONTROL_ID_CODE register used for the device identification
is moved to CTRL_MODULE_WAKEUP partition. So updating the
register address for the same here.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The CONTROL_ID_CODE register used for the device identification
is moved to CTRL_MODULE_WAKEUP partition. So updating the
register address for the same here.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
thermal: consider emul_temperature while computing trend
In case emulated temperature is in use, using the trend
provided by driver layer can lead to bogus situation.
In this case, debugger user would set a temperature value,
but the trend would be from driver computation.
To avoid this situation, this patch changes the get_tz_trend()
to consider the emulated temperature whenever that is in use.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
[Backported to 3.8]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
In case emulated temperature is in use, using the trend
provided by driver layer can lead to bogus situation.
In this case, debugger user would set a temperature value,
but the trend would be from driver computation.
To avoid this situation, this patch changes the get_tz_trend()
to consider the emulated temperature whenever that is in use.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
[Backported to 3.8]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
ARM: OMAP5: Add select tuples to enable CPUFREQ on OMAP5
ARM: DRA7XX: PM: add soc_is_dra7xx check to take care of freqsel absence
add soc_is_dra7xx check to take care of freqsel absence.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
add soc_is_dra7xx check to take care of freqsel absence.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
ARM: dts: dra7: add clock nodes for CPU and link avs_mpu regulator to cpu
Add clock nodes for CPU and link avs_mpu regulator to cpu.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Add clock nodes for CPU and link avs_mpu regulator to cpu.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Arm: DRA7XX: Clock: Update dpll_mpu_ck_ops
Update dpll_mpu_ck_ops so as to have a custom dpll_set_rate
on the similar lines of OMAP5. The bit fields and the rates
are exactly the same hence reusing the same functions as that
of OMAP5.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Update dpll_mpu_ck_ops so as to have a custom dpll_set_rate
on the similar lines of OMAP5. The bit fields and the rates
are exactly the same hence reusing the same functions as that
of OMAP5.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
ARM: DTS: DRA7: Link the actual TPS659038 regulators to
Link the actual TPS659038 regulators to AVS class 0 regulators.
Referred Visio-Power_Diagram 20121109b.pdf a visio diagram
showing which SMPS feeds on to which voltage domain on DRA7.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Link the actual TPS659038 regulators to AVS class 0 regulators.
Referred Visio-Power_Diagram 20121109b.pdf a visio diagram
showing which SMPS feeds on to which voltage domain on DRA7.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
ARM: DTS: DRA7: Add avs class 0 regulator nodes
Add avs class 0 regulator nodes.
Referred:
DRA7xx_ES1.0_NDA_TRM_vC.pdf for the Efuse register addresses.
DMInputs-Voltages-2013-04-05.xlsx for the latest OPP voltages.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Add avs class 0 regulator nodes.
Referred:
DRA7xx_ES1.0_NDA_TRM_vC.pdf for the Efuse register addresses.
DMInputs-Voltages-2013-04-05.xlsx for the latest OPP voltages.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
regulator: ti-avs-class0: use regulator name based on device instance
Don't use the same regulator descriptor for all regulator instance,
as there will be a name conflict. Instead pick up the device name and
create the descriptor.
As part of this change, save on multiple kzallocs by moving the
descriptor allocation as part of tiavs_class0_data allocation and drop
the need for an temp descriptor.
Signed-off-by: Nishanth Menon <nm@ti.com>
Don't use the same regulator descriptor for all regulator instance,
as there will be a name conflict. Instead pick up the device name and
create the descriptor.
As part of this change, save on multiple kzallocs by moving the
descriptor allocation as part of tiavs_class0_data allocation and drop
the need for an temp descriptor.
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: ti-avs-class0: dont reserve efuse memory offsets
devm_request_and_ioremap reserves the efuse offsets for AVS class0,
However, these efuse offsets might be used by other drivers for
information from the same efuse offset ranges as well. hence just
remap the range with devm_ioremap_nocache and read the required data
out.
Signed-off-by: Nishanth Menon <nm@ti.com>
devm_request_and_ioremap reserves the efuse offsets for AVS class0,
However, these efuse offsets might be used by other drivers for
information from the same efuse offset ranges as well. hence just
remap the range with devm_ioremap_nocache and read the required data
out.
Signed-off-by: Nishanth Menon <nm@ti.com>
cpufreq: cpufreq-cpu0: defer probe when regulator is not ready(v2)
upstream posted https://patchwork.kernel.org/patch/2505311/
With commit 1e4b545, regulator_get will now return -EPROBE_DEFER
when the cpu0-supply node is present, but the regulator is not yet
registered.
It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not yet
instantiated. For example: an regulator which uses I2C and GPIO might
need both systems available before proceeding, in this case, the
regulator might defer it's registration.
However, the cpufreq-cpu0 driver assumes that any un-successful return
result is equivalent of failure.
When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed with
the assumption that only clock control is necessary in the platform.
With this change, we can now handle the following conditions:
a) cpu0-supply binding is not present, regulator_get will return
appropriate error result, resulting in cpufreq-cpu0 driver controlling
just the clock.
b) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver registering
later once the regulator is available.
c) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, however, regulator never registers, we retry until
cpufreq-cpu0 driver fails to register pointing at device tree
information bug. However, in this case, the fact that cpufreq-cpu0
operates with clock only when the DT binding clearly indicates need of
a supply is a bug of it's own.
d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
controls both the clock and regulator
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
upstream posted https://patchwork.kernel.org/patch/2505311/
With commit 1e4b545, regulator_get will now return -EPROBE_DEFER
when the cpu0-supply node is present, but the regulator is not yet
registered.
It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not yet
instantiated. For example: an regulator which uses I2C and GPIO might
need both systems available before proceeding, in this case, the
regulator might defer it's registration.
However, the cpufreq-cpu0 driver assumes that any un-successful return
result is equivalent of failure.
When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed with
the assumption that only clock control is necessary in the platform.
With this change, we can now handle the following conditions:
a) cpu0-supply binding is not present, regulator_get will return
appropriate error result, resulting in cpufreq-cpu0 driver controlling
just the clock.
b) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver registering
later once the regulator is available.
c) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, however, regulator never registers, we retry until
cpufreq-cpu0 driver fails to register pointing at device tree
information bug. However, in this case, the fact that cpufreq-cpu0
operates with clock only when the DT binding clearly indicates need of
a supply is a bug of it's own.
d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
controls both the clock and regulator
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: core: return err value for regulator_get if there is no DT binding
commit 1e4b545cdd93318379c6b1fb0a99536fa3260f53 upstream.
commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
(regulator: core: Don't defer probe if there's no DT binding for a supply)
Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.
However, ret value supplied by regulator_dev_lookup() is being
ignored by regulator_get(). So, exit with the appropriate return value.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit 1e4b545cdd93318379c6b1fb0a99536fa3260f53 upstream.
commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
(regulator: core: Don't defer probe if there's no DT binding for a supply)
Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.
However, ret value supplied by regulator_dev_lookup() is being
ignored by regulator_get(). So, exit with the appropriate return value.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
ARM/dts: dra7-evm: Enable tps659038 on i2c1 bus
Enable tps659038 on i2c1 bus.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Enable tps659038 on i2c1 bus.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
arm: dts: dra7: add I2C devices to dra7 DeviceTree file
Add all 5 I2C instances to dra7.dtsi file.
Also populate the i2c nodes in dra board file.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Add all 5 I2C instances to dra7.dtsi file.
Also populate the i2c nodes in dra board file.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
arm: omap2plus_defconfig: enable DRA752 thermal support by default
Make DRA752 thermal support enabled on omap2plus_defconfig
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Make DRA752 thermal support enabled on omap2plus_defconfig
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
arm: mach-omap2: flag DRA7 as having bandgap
Make sure bandgap feature is available for building DRA7 chips
support.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Make sure bandgap feature is available for building DRA7 chips
support.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
arm: dts: add bandgap entry for DRA752 chips
Add bandgap DT entry.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Add bandgap DT entry.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
staging: ti-soc-thermal: add DT example for DRA752 chip
Update documentation by adding an example for DRA752 on DT description.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Update documentation by adding an example for DRA752 on DT description.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
staging: ti-soc-thermal: remove external heat while extrapolating hotspot
For boards that provide a PCB sensor close to SoC junction
temperature, it is possible to remove the cumulative heat
reported by the SoC temperature sensor.
This patch changes the extrapolation computation to consider
an external sensor in the extrapolation equations.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
For boards that provide a PCB sensor close to SoC junction
temperature, it is possible to remove the cumulative heat
reported by the SoC temperature sensor.
This patch changes the extrapolation computation to consider
an external sensor in the extrapolation equations.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
thermal: expose thermal_zone_get_temp API
This patch exports the thermal_zone_get_temp API so that driver
writers can fetch temperature of thermal zones managed by other
drivers.
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
This patch exports the thermal_zone_get_temp API so that driver
writers can fetch temperature of thermal zones managed by other
drivers.
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
thermal: introduce thermal_zone_get_zone_by_name helper function
This patch adds a helper function to get a reference of
a thermal zone, based on the zone type name.
It will perform a zone name lookup and return a reference
to a thermal zone device that matches the name requested.
In case the zone is not found or when several zones match
same name or if the required parameters are invalid, it will return
the corresponding error code (ERR_PTR).
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
This patch adds a helper function to get a reference of
a thermal zone, based on the zone type name.
It will perform a zone name lookup and return a reference
to a thermal zone device that matches the name requested.
In case the zone is not found or when several zones match
same name or if the required parameters are invalid, it will return
the corresponding error code (ERR_PTR).
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
staging: ti-soc-thermal: add dra752 chip to device table
Add support to TI dra752 chips by adapting the driver
device table.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Add support to TI dra752 chips by adapting the driver
device table.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
staging: ti-soc-thermal: add thermal data for DRA752 chips
This patch adds the thermal data for TI DRA752 chips.
In this change it includes (autogen):
. Register offset definitions
. Bitfields and masks for all registers
. Conversion table
Also, the thermal limits, thresholds and extrapolation
rules are included. The extrapolation rule is simply
add +2C as margin.
All 5 sensors, MPU, GPU, CORE, DSPEVE and IVA, are defined
and exposed. Only MPU has cooling device.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
This patch adds the thermal data for TI DRA752 chips.
In this change it includes (autogen):
. Register offset definitions
. Bitfields and masks for all registers
. Conversion table
Also, the thermal limits, thresholds and extrapolation
rules are included. The extrapolation rule is simply
add +2C as margin.
All 5 sensors, MPU, GPU, CORE, DSPEVE and IVA, are defined
and exposed. Only MPU has cooling device.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
regulator: introduce TI AVS class 0 driver
OMAP5 technology based processors such as DRA7XX[1] has an simplified AVS
strategy called SmartReflex[2] Class 0. Texas Instrument's nomenclature for
this is: Class - 0: Production Test Calibration
This, in it's simplistic form implies that the voltage value for each OPP
is now encoded into an efuse location.
On entering an OPP, the voltage value to be selected is no longer the
traditional nominal voltage, but the voltage meant from the efuse offset
encoded in millivolts. Each device will have it's own unique voltage for a
given OPP. Therefore, it is not possible to encode a range of voltage
representing an OPP voltage.
DRA processors may be powered using various PMICs - I2C based ones such
as TPS659039 or SPI / GPIO controlled ones as well.
cpufreq/devfreq driver which controls voltage and frequency pairs traditionally
used:
cpufreq/devfreq --> PMIC regulator
\-> clock framework
This opens up a few issues:
a) PMIC regulator is designed for platforms that maynot use SmartReflex class 0
based SoCs, encoding the efuse offsets into every possible PMIC regulator
driver is practically in-efficient.
b) Voltage values are not known a-priori to be encoded into DTB as they are
device specific.
Another option might have been to start off with the nominal voltages in
DT and then fixup the voltage entries in the OPP table by reading the
eFuse information.
However, such an approach introduces formidable constraints:
A) OPP tables once added are not modifiable beyond enable/disable - that
was the entire design constraint we wanted on OPP tables
B) We need some indexing value for uniquely identifying what to do for
an given OPP voltage - if OPP voltage by itself changes, how do we index
various subsystems? - read abb/avs class 2 based class 1.
C) We have n voltage domains and m devices per domain. - we no longer
want to maintain an centralized OPP table.
D) We also need to support multiple platforms which have "ganged voltage
rails" each domain with variable voltages.
E) Modification of the OPP data itself is hard - considering that we do
not have a centralized OPP repository, architecture independent drivers
like cpufreq-cpu0 driver does the "adding of OPPs".
Options:
a) modify arch generic drivers such as cpufreq-cpu0 driver with an OMAP
specific an efuse offset and OMAP specific handling is a bad idea.
b) we are able to overlay OPP table entried *before* cpufreq driver
comes active
- I am not sure we have ability to do that in kernel yet
- I am not even sure we can modify the dtb being loaded by all
bootloaders we may have (thinking beyond u-boot).
To simplify this, we introduce:
cpufreq/devfreq --> SmartReflex Class 0 regulator --> PMIC regulator
\-> clock framework
Class 0 Regulator has information of translating the "nominal voltage" into
voltage value stored in efuse offset.
Example encoding:
uVolts mVolt --> stored as 16 bit hex value of mV
975000 975 --> 0x03CF
1075000 1075 --> 0x0433
1200000 1200 --> 0x04B0
[1] http://www.ti.com/lit/ds/sprt659/sprt659.pdf
[2] http://www.ti.com/lit/wp/swpy015a/swpy015a.pdf
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP5 technology based processors such as DRA7XX[1] has an simplified AVS
strategy called SmartReflex[2] Class 0. Texas Instrument's nomenclature for
this is: Class - 0: Production Test Calibration
This, in it's simplistic form implies that the voltage value for each OPP
is now encoded into an efuse location.
On entering an OPP, the voltage value to be selected is no longer the
traditional nominal voltage, but the voltage meant from the efuse offset
encoded in millivolts. Each device will have it's own unique voltage for a
given OPP. Therefore, it is not possible to encode a range of voltage
representing an OPP voltage.
DRA processors may be powered using various PMICs - I2C based ones such
as TPS659039 or SPI / GPIO controlled ones as well.
cpufreq/devfreq driver which controls voltage and frequency pairs traditionally
used:
cpufreq/devfreq --> PMIC regulator
\-> clock framework
This opens up a few issues:
a) PMIC regulator is designed for platforms that maynot use SmartReflex class 0
based SoCs, encoding the efuse offsets into every possible PMIC regulator
driver is practically in-efficient.
b) Voltage values are not known a-priori to be encoded into DTB as they are
device specific.
Another option might have been to start off with the nominal voltages in
DT and then fixup the voltage entries in the OPP table by reading the
eFuse information.
However, such an approach introduces formidable constraints:
A) OPP tables once added are not modifiable beyond enable/disable - that
was the entire design constraint we wanted on OPP tables
B) We need some indexing value for uniquely identifying what to do for
an given OPP voltage - if OPP voltage by itself changes, how do we index
various subsystems? - read abb/avs class 2 based class 1.
C) We have n voltage domains and m devices per domain. - we no longer
want to maintain an centralized OPP table.
D) We also need to support multiple platforms which have "ganged voltage
rails" each domain with variable voltages.
E) Modification of the OPP data itself is hard - considering that we do
not have a centralized OPP repository, architecture independent drivers
like cpufreq-cpu0 driver does the "adding of OPPs".
Options:
a) modify arch generic drivers such as cpufreq-cpu0 driver with an OMAP
specific an efuse offset and OMAP specific handling is a bad idea.
b) we are able to overlay OPP table entried *before* cpufreq driver
comes active
- I am not sure we have ability to do that in kernel yet
- I am not even sure we can modify the dtb being loaded by all
bootloaders we may have (thinking beyond u-boot).
To simplify this, we introduce:
cpufreq/devfreq --> SmartReflex Class 0 regulator --> PMIC regulator
\-> clock framework
Class 0 Regulator has information of translating the "nominal voltage" into
voltage value stored in efuse offset.
Example encoding:
uVolts mVolt --> stored as 16 bit hex value of mV
975000 975 --> 0x03CF
1075000 1075 --> 0x0433
1200000 1200 --> 0x04B0
[1] http://www.ti.com/lit/ds/sprt659/sprt659.pdf
[2] http://www.ti.com/lit/wp/swpy015a/swpy015a.pdf
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: introduce regulator chain locking scheme
In some cases the regulators may be organized in a chain like:
->regA->regB->regC
where regA is supplier for regB and regB is supplier for regC.
Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.
Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside. To
achieve this goal the root Regulator (which has no supply defined, like
regA) in chain is used to protect the whole chain.
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
In some cases the regulators may be organized in a chain like:
->regA->regB->regC
where regA is supplier for regB and regB is supplier for regC.
Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.
Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside. To
achieve this goal the root Regulator (which has no supply defined, like
regA) in chain is used to protect the whole chain.
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
regulators: abstract locking out into helper functions
Create locking helpers for the regulator mutex. These helpers will be
needed for the next patch which introduces Regulator chain locking
scheme.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Create locking helpers for the regulator mutex. These helpers will be
needed for the next patch which introduces Regulator chain locking
scheme.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
rtc: palmas: Enable device tree support for Palmas RTC.
Enable device tree support for Palmas RTC.
The Documentation is updated here:
Documentation/devicetree/bindings/rtc/palmas-rtc.txt
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Enable device tree support for Palmas RTC.
The Documentation is updated here:
Documentation/devicetree/bindings/rtc/palmas-rtc.txt
Signed-off-by: J Keerthy <j-keerthy@ti.com>
rtc: palmas: Add RTC driver Palmas series PMIC
TI Palmas series PMIC support the RTC and alarm functionality.
Add RTC driver with alarm support for this device.
This patch is picked from the mainline kernel.
https://patchwork.kernel.org/patch/1926921/
Commit id: 0101e53cbb1c653738de8dfddc80c0faa5a4fd39
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 0101e53cbb1c653738de8dfddc80c0faa5a4fd39]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
TI Palmas series PMIC support the RTC and alarm functionality.
Add RTC driver with alarm support for this device.
This patch is picked from the mainline kernel.
https://patchwork.kernel.org/patch/1926921/
Commit id: 0101e53cbb1c653738de8dfddc80c0faa5a4fd39
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 0101e53cbb1c653738de8dfddc80c0faa5a4fd39]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
rtc: Revert rtc-palmas driver for palmas PMIC
This reverts commit 5e3935c6e9d8d1bd05d39fde55b913f85a1b42a4.
(rtc: rtc-palmas a new driver for palmas PMIC). Removing
the intermediate version of the driver to absorb the upstreamed
driver.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
This reverts commit 5e3935c6e9d8d1bd05d39fde55b913f85a1b42a4.
(rtc: rtc-palmas a new driver for palmas PMIC). Removing
the intermediate version of the driver to absorb the upstreamed
driver.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
mfd: palmas: Add rtc irq number as irq resource for palmas-rtc
Palma RTC is capable of generating alarm interrupt. Pass the alarm interrupt
as IRQ_RESOURCE for palmas-rtc sub device driver so that rtc driver can get
irq as platform_get_irq().
Also pass the irq domain in mfd_add_devices() to properly offset the irqs for
sub devices. This is needed when adding device through DT.
This patch is absorbed from the Mainline kernel:
http://lkml.indiana.edu/hypermail/linux/kernel/1301.0/00559.html
Commit id: a36516b016f52f0f6e5284025e3487f63b4be33b
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream a36516b016f52f0f6e5284025e3487f63b4be33b]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Palma RTC is capable of generating alarm interrupt. Pass the alarm interrupt
as IRQ_RESOURCE for palmas-rtc sub device driver so that rtc driver can get
irq as platform_get_irq().
Also pass the irq domain in mfd_add_devices() to properly offset the irqs for
sub devices. This is needed when adding device through DT.
This patch is absorbed from the Mainline kernel:
http://lkml.indiana.edu/hypermail/linux/kernel/1301.0/00559.html
Commit id: a36516b016f52f0f6e5284025e3487f63b4be33b
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream a36516b016f52f0f6e5284025e3487f63b4be33b]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
mfd: palmas: Add APIs to access the Palmas' registers
Palmas register set is divided into different blocks (base and offset)
and hence different i2c addresses. The i2c address offsets are derived
from base address of block of registers.
Add inline APIs to access the Palma's registers which takes the base of
register block and register offset. The i2c address offset is derived
from the base address of register blocks.
This patch is picked up from Mainline kernel:
https://patchwork.kernel.org/patch/1926911/
Commit id: 60c185f059c88ad4b9b170b1f9322e3adcccca07
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 60c185f059c88ad4b9b170b1f9322e3adcccca07]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Palmas register set is divided into different blocks (base and offset)
and hence different i2c addresses. The i2c address offsets are derived
from base address of block of registers.
Add inline APIs to access the Palma's registers which takes the base of
register block and register offset. The i2c address offset is derived
from the base address of register blocks.
This patch is picked up from Mainline kernel:
https://patchwork.kernel.org/patch/1926911/
Commit id: 60c185f059c88ad4b9b170b1f9322e3adcccca07
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[j-keerthy@ti.com: backport from upstream 60c185f059c88ad4b9b170b1f9322e3adcccca07]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
ARM/dts: add dtsi file for TPS659038 device
Add dtsi file for TPS659038 device.
The Documents referred:
1) TPS659039-Q1 POWER MANAGEMENT UNIT (PMU) FOR PROCESSOR Data Manual
2) TPS659038/39-Q1 Functional Register Descriptions.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Add dtsi file for TPS659038 device.
The Documents referred:
1) TPS659039-Q1 POWER MANAGEMENT UNIT (PMU) FOR PROCESSOR Data Manual
2) TPS659038/39-Q1 Functional Register Descriptions.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
regulators: palmas: Add TPS659038 support
Add TPS659038 support. The TPS659038 belongs to PALMAS family.
The only difference between TPS659038 and TWL6035 w.r.t
regulators is the SMPS10 is not present in TPS659038.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Add TPS659038 support. The TPS659038 belongs to PALMAS family.
The only difference between TPS659038 and TWL6035 w.r.t
regulators is the SMPS10 is not present in TPS659038.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
mfd: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) TPS659038 has something more than Palmas in one case it is called
Sync clock Functionality.
5) can use an external crystal unit or 16MHz oscillator to generate clock.
6) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Hence some of the IRQs are reserved in case of TPS659038 but the
remaining are bit exact compared to TWL6035.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) TPS659038 has something more than Palmas in one case it is called
Sync clock Functionality.
5) can use an external crystal unit or 16MHz oscillator to generate clock.
6) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Hence some of the IRQs are reserved in case of TPS659038 but the
remaining are bit exact compared to TWL6035.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
mfd: Palmas: Introduce palmas_pmic_data structure
Introduce palmas_pmic_data structure so that Palmas variants
like TWL6035, TWL6037, TPS65913 can populate data specific
to them. This enables driver to support variants.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Introduce palmas_pmic_data structure so that Palmas variants
like TWL6035, TWL6037, TPS65913 can populate data specific
to them. This enables driver to support variants.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
mfd: DT bindings for the palmas family MFD (v10)
Add the various binding files for the palmas family of chips.
There is a top level MFD binding then a seperate binding for IP blocks on chips.
This patch is picked up from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
[j-keerthy@ti.com: backport from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Ian Lartey <ian@slimlogic.co.uk>
Add the various binding files for the palmas family of chips.
There is a top level MFD binding then a seperate binding for IP blocks on chips.
This patch is picked up from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
[j-keerthy@ti.com: backport from v10 of the palmas patch set:
https://patchwork.kernel.org/patch/2321171/]
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Ian Lartey <ian@slimlogic.co.uk>
Merge remote-tracking branch 'rnayak/platform-base-vayu-3.8.y' into vayu-pm-linux-3.8.y
Conflicts:
arch/arm/mach-omap2/clockdomain.h
arch/arm/mach-omap2/control.h
arch/arm/mach-omap2/omap-hotplug.c
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/pm_omap4plus.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Conflicts:
arch/arm/mach-omap2/clockdomain.h
arch/arm/mach-omap2/control.h
arch/arm/mach-omap2/omap-hotplug.c
arch/arm/mach-omap2/omap-mpuss-lowpower.c
arch/arm/mach-omap2/pm_omap4plus.c
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: Prevent any low power entry in suspend
On DRA7 we do not support low power for MPU in either suspend or
cpuidle.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
On DRA7 we do not support low power for MPU in either suspend or
cpuidle.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: Add the build support
Adding the build support required for DRA7xx soc
in to omap2+ config.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Adding the build support required for DRA7xx soc
in to omap2+ config.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: Add PRM dev_inst module offset in global_warm_reset function
Currently omap4_prminst_global_warm_reset function is invoked by
OMAP4/5 socs upon a system reboot command. Add the right PRM module
device_inst offset for DRA_7xx devices, to reuse it for
DRA7xx as well.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Currently omap4_prminst_global_warm_reset function is invoked by
OMAP4/5 socs upon a system reboot command. Add the right PRM module
device_inst offset for DRA_7xx devices, to reuse it for
DRA7xx as well.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
ARM: DRA7: Enable framework initializations
Initialise the power, HWMOD, clock domains and the clock tree.
Signed-off-by: Ambresh K <ambresh@ti.com>
Initialise the power, HWMOD, clock domains and the clock tree.
Signed-off-by: Ambresh K <ambresh@ti.com>
ARM: DRA7: hwmod data: Create initial DRA7XX SOC hwmod data
Adding the hwmod data for DRA7XX platforms.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Adding the hwmod data for DRA7XX platforms.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: clock data: Add DRA7XX full clock tree and headers
Add the clock tree related data for DRA7XX platforms.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the clock tree related data for DRA7XX platforms.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: powerdomain data: Add DRA7XX data and update the header
Add the data file to describe all power domains inside the DRA7XX soc.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the data file to describe all power domains inside the DRA7XX soc.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: clockdomain data: Add DRA7XX data and update the header
Add the data file to describe all clock domains inside the DRA7XX SOC
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the data file to describe all clock domains inside the DRA7XX SOC
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
Add the PRCM MPU registers for DRA7XX platforms
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rnayak@ti.com: Added PRCM partition information]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Add the PRCM MPU registers for DRA7XX platforms
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rnayak@ti.com: Added PRCM partition information]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: CM: Add DRA7XX register and bitfield files
Add the new defines for DRA7XX CM registers.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Add the new defines for DRA7XX CM registers.
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
ARM: DRA7: PRM: Add DRA7XX register and bitfield files
Add the new defines for DRA7xx prm module registers.
Signed-off-by: Ambresh K <ambresh@ti.com>
Add the new defines for DRA7xx prm module registers.
Signed-off-by: Ambresh K <ambresh@ti.com>
ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.
DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.
Adding the minimum device tree files required for
DRA7xx based socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.
DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.
Adding the minimum device tree files required for
DRA7xx based socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: PM: Avoid all SAR save on dra7
Get rid of all assumptions about always having a sar base on *all*
omap4+ platforms. We dont need one on DRA7.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Get rid of all assumptions about always having a sar base on *all*
omap4+ platforms. We dont need one on DRA7.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: Add static dep from EMIF to MPU
Enable the static dependency between EMIF and MPU.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Enable the static dependency between EMIF and MPU.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
10 years agoARM: OMAP2+: Powerdomains: Remove the hard requirement to always have a voltdm assoca...
ARM: OMAP2+: Powerdomains: Remove the hard requirement to always have a voltdm assocaited to a pwrdm
The powerdomain framework expects all powerdomains to be asoociated with
a corresponding voltage domain. For some SoCs (like the DRA7 family) which
does not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association (since they are really non scalable, even
though the volatge domains exist in place).
Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
The powerdomain framework expects all powerdomains to be asoociated with
a corresponding voltage domain. For some SoCs (like the DRA7 family) which
does not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association (since they are really non scalable, even
though the volatge domains exist in place).
Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA7: Kconfig: Increase the default gpio count
DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: board-generic: Add device tree support
Adding the minimal support for DRA7xx soc with
device tree.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Adding the minimal support for DRA7xx soc with
device tree.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: timer: Add clocksource, clockevent support
Reusing all the OMAP5 timer code here.
So just adding SOC_DRA7XX check to enable on single
platform build.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reusing all the OMAP5 timer code here.
So just adding SOC_DRA7XX check to enable on single
platform build.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: Add minimal support for DRA7xx SOC
The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.
The architecture is designed for advanced graphical HMI and
Navigation, Digital and Analog Radio, Rear Seat Entertainment
and Multimedia playback, providing Advanced Driver Assistance
integration capabilities with Video analytics support, and
best-in-class CPU performance, video, image, and graphics
processing.
DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.
In this patch:
Most of the minimal support code is reused from OMAP5.
- A new early init function is added.
- The machine specific header is updated for base address
changes.
- Makefile updates
- hwmod file is updated to include the common functions.
- Updated the sram size
Signed-off-by: R Sricharan <r.sricharan@ti.com>
The DRA7xx is a high-performance, infotainment application
device, based on enhanced OMAP architecture integrated on a
28-nm technology.
The architecture is designed for advanced graphical HMI and
Navigation, Digital and Analog Radio, Rear Seat Entertainment
and Multimedia playback, providing Advanced Driver Assistance
integration capabilities with Video analytics support, and
best-in-class CPU performance, video, image, and graphics
processing.
DRA75x, DRA74x belong to the DRA7xx family.
DRA75x and DRA74x are dual core CORTEX A15 SOCs with GIC used
for interrupt handling and with an integrated L2 cache
controller.
In this patch:
Most of the minimal support code is reused from OMAP5.
- A new early init function is added.
- The machine specific header is updated for base address
changes.
- Makefile updates
- hwmod file is updated to include the common functions.
- Updated the sram size
Signed-off-by: R Sricharan <r.sricharan@ti.com>
ARM: DRA7: id: Add cpu detection support for DRA7xx based socs
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture. DRA7xx family is composed
of DRA75x and DRA74x devices.
Adding the DRA752 ES1.0 cpu revision detection support.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture. DRA7xx family is composed
of DRA75x and DRA74x devices.
Adding the DRA752 ES1.0 cpu revision detection support.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
10 years agoMerge branch 'platform-base-3.8.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platf...
Merge branch 'platform-base-3.8.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.8.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-base-3.8.y
* 'platform-base-3.8.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
arm: omap2+: omap_device: remove no_idle_on_suspend
arm: omap2+: serial: remove no_console_suspend support
driver: serial: omap: prevent runtime PM for "no_console_suspend"
driver: tty: serial: Move "uart_console" def to core header file.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-base-3.8.y
* 'platform-base-3.8.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
arm: omap2+: omap_device: remove no_idle_on_suspend
arm: omap2+: serial: remove no_console_suspend support
driver: serial: omap: prevent runtime PM for "no_console_suspend"
driver: tty: serial: Move "uart_console" def to core header file.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
arm: omap2+: omap_device: remove no_idle_on_suspend
Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Remove "no_idle_on_suspend" check, since respective
driver should be able to prevent idling of an
omap device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their ->runtime_suspend only during suspend.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
arm: omap2+: serial: remove no_console_suspend support
"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
"no_console_suspend" is no longer handled in platform file,
Since the omap serial driver is now adapted to prevent
console UART idleing during suspend.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
driver: serial: omap: prevent runtime PM for "no_console_suspend"
The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
driver: tty: serial: Move "uart_console" def to core header file.
Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion from mpc52xx_uart driver.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Move "uart_console" definition to serial core header file, so that it can be
used by serial drivers.
Get rid of the uart_console defintion from mpc52xx_uart driver.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Merge tag 'v3.8.13' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-3.8.y
* tag 'v3.8.13' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (74 commits)
Linux 3.8.13
x86/mm: account for PGDIR_SIZE alignment
kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
NFSv4.x: Fix handling of partially delegated locks
EDAC: Don't give write permission to read-only files
Btrfs: fix extent logging with O_DIRECT into prealloc
Btrfs: compare relevant parts of delayed tree refs
tracing: Fix ftrace_dump()
drm/radeon: fix handling of v6 power tables
drm/radeon: add new richland pci ids
drm/radeon: fix possible segfault when parsing pm tables
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
drm/radeon: Always flush the VM
drm/radeon: fix typo in si_select_se_sh()
drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
drm/radeon: cleanup properly if mmio mapping fails
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS
drm/radeon: add some new SI PCI ids
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
...
Signed-off-by: Dan Murphy <dmurphy@ti.com>
* tag 'v3.8.13' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (74 commits)
Linux 3.8.13
x86/mm: account for PGDIR_SIZE alignment
kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
NFSv4.x: Fix handling of partially delegated locks
EDAC: Don't give write permission to read-only files
Btrfs: fix extent logging with O_DIRECT into prealloc
Btrfs: compare relevant parts of delayed tree refs
tracing: Fix ftrace_dump()
drm/radeon: fix handling of v6 power tables
drm/radeon: add new richland pci ids
drm/radeon: fix possible segfault when parsing pm tables
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
drm/radeon: Always flush the VM
drm/radeon: fix typo in si_select_se_sh()
drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
drm/radeon: cleanup properly if mmio mapping fails
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS
drm/radeon: add some new SI PCI ids
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
...
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Linux 3.8.13
x86/mm: account for PGDIR_SIZE alignment
Patch for -stable. Function find_early_table_space removed upstream.
Fixes panic in alloc_low_page due to pgt_buf overflow during
init_memory_mapping.
find_early_table_space sizes pgt_buf based upon the size of the
memory being mapped, but it does not take into account the alignment
of the memory. When the region being mapped spans a 512GB (PGDIR_SIZE)
alignment, a panic from alloc_low_pages occurs.
kernel_physical_mapping_init takes into account PGDIR_SIZE alignment.
This causes an extra call to alloc_low_page to be made. This extra call
isn't accounted for by find_early_table_space and causes a kernel panic.
Change is to take into account PGDIR_SIZE alignment in find_early_table_space.
Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patch for -stable. Function find_early_table_space removed upstream.
Fixes panic in alloc_low_page due to pgt_buf overflow during
init_memory_mapping.
find_early_table_space sizes pgt_buf based upon the size of the
memory being mapped, but it does not take into account the alignment
of the memory. When the region being mapped spans a 512GB (PGDIR_SIZE)
alignment, a panic from alloc_low_pages occurs.
kernel_physical_mapping_init takes into account PGDIR_SIZE alignment.
This causes an extra call to alloc_low_page to be made. This extra call
isn't accounted for by find_early_table_space and causes a kernel panic.
Change is to take into account PGDIR_SIZE alignment in find_early_table_space.
Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream.
audit_trim_trees() calls get_tree(). If a failure occurs we must call
put_tree().
[akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream.
audit_trim_trees() calls get_tree(). If a failure occurs we must call
put_tree().
[akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NFSv4.x: Fix handling of partially delegated locks
commit c5a2a15f8146fdfe45078df7873a6dc1006b3869 upstream.
If a NFS client receives a delegation for a file after it has taken
a lock on that file, we can currently end up in a situation where
we mistakenly skip unlocking that file.
The following patch swaps an erroneous check in nfs4_proc_unlck for
whether or not the file has a delegation to one which checks whether
or not we hold a lock stateid for that file.
Reported-by: Chuck Lever <Chuck.Lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chuck Lever <Chuck.Lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5a2a15f8146fdfe45078df7873a6dc1006b3869 upstream.
If a NFS client receives a delegation for a file after it has taken
a lock on that file, we can currently end up in a situation where
we mistakenly skip unlocking that file.
The following patch swaps an erroneous check in nfs4_proc_unlck for
whether or not the file has a delegation to one which checks whether
or not we hold a lock stateid for that file.
Reported-by: Chuck Lever <Chuck.Lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chuck Lever <Chuck.Lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EDAC: Don't give write permission to read-only files
commit c8c64d165ccfd2274058ac84e0c680f9b48c4ec1 upstream.
I get the following warning on boot:
------------[ cut here ]------------
WARNING: at drivers/base/core.c:575 device_create_file+0x9a/0xa0()
Hardware name: -[8737R2A]-
Write permission without 'store'
...
</snip>
Drilling down, this is related to dynamic channel ce_count attribute
files sporting a S_IWUSR mode without a ->store() function. Looking
around, it appears that they aren't supposed to have a ->store()
function. So remove the bogus write permission to get rid of the
warning.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
[ shorten commit message ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c8c64d165ccfd2274058ac84e0c680f9b48c4ec1 upstream.
I get the following warning on boot:
------------[ cut here ]------------
WARNING: at drivers/base/core.c:575 device_create_file+0x9a/0xa0()
Hardware name: -[8737R2A]-
Write permission without 'store'
...
</snip>
Drilling down, this is related to dynamic channel ce_count attribute
files sporting a S_IWUSR mode without a ->store() function. Looking
around, it appears that they aren't supposed to have a ->store()
function. So remove the bogus write permission to get rid of the
warning.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
[ shorten commit message ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Btrfs: fix extent logging with O_DIRECT into prealloc
commit eb384b55ae9c2055ea00c5cc87971e182d47aefa upstream.
This is the same as the fix from commit
Btrfs: fix bad extent logging
but for O_DIRECT. I missed this when I fixed the problem originally, we were
still using the em for the orig_start and orig_block_len, which would be the
merged extent. We need to use the actual extent from the on disk file extent
item, which we have to lookup to make sure it's ok to nocow anyway so just pass
in some pointers to hold this info. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eb384b55ae9c2055ea00c5cc87971e182d47aefa upstream.
This is the same as the fix from commit
Btrfs: fix bad extent logging
but for O_DIRECT. I missed this when I fixed the problem originally, we were
still using the em for the orig_start and orig_block_len, which would be the
merged extent. We need to use the actual extent from the on disk file extent
item, which we have to lookup to make sure it's ok to nocow anyway so just pass
in some pointers to hold this info. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Btrfs: compare relevant parts of delayed tree refs
commit 41b0fc42800569f63e029549b75c4c9cb63f2dfd upstream.
A user reported a panic while running a balance. What was happening was he was
relocating a block, which added the reference to the relocation tree. Then
relocation would walk through the relocation tree and drop that reference and
free that block, and then it would walk down a snapshot which referenced the
same block and add another ref to the block. The problem is this was all
happening in the same transaction, so the parent block was free'ed up when we
drop our reference which was immediately available for allocation, and then it
was used _again_ to add a reference for the same block from a different
snapshot. This resulted in something like this in the delayed ref tree
add ref to 90234880, parent=2067398656, ref_root 1766, level 1
del ref to 90234880, parent=2067398656, ref_root 18446744073709551608, level 1
add ref to 90234880, parent=2067398656, ref_root 1767, level 1
as you can see the ref_root's don't match, because when we inc the ref we use
the header owner, which is the original tree the block belonged to, instead of
the data reloc tree. Then when we remove the extent we use the reloc tree
objectid. But none of this matters, since it is a shared reference which means
only the parent matters. When the delayed ref stuff runs it adds all the
increments first, and then does all the drops, to make sure that we don't delete
the ref if we net a positive ref count. But tree blocks aren't allowed to have
multiple refs from the same block, so this panics when it tries to add the
second ref. We need the add and the drop to cancel each other out in memory so
we only do the final add.
So to fix this we need to adjust how the delayed refs are added to the tree.
Only the ref_root matters when it is a normal backref, and only the parent
matters when it is a shared backref. So make our decision based on what ref
type we have. This allows us to keep the ref_root in memory in case anybody
wants to use it for something else, and it allows the delayed refs to be merged
properly so we don't end up with this panic.
With this patch the users image no longer panics on mount, and it has a clean
fsck after a normal mount/umount cycle. Thanks,
Reported-by: Roman Mamedov <rm@romanrm.ru>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 41b0fc42800569f63e029549b75c4c9cb63f2dfd upstream.
A user reported a panic while running a balance. What was happening was he was
relocating a block, which added the reference to the relocation tree. Then
relocation would walk through the relocation tree and drop that reference and
free that block, and then it would walk down a snapshot which referenced the
same block and add another ref to the block. The problem is this was all
happening in the same transaction, so the parent block was free'ed up when we
drop our reference which was immediately available for allocation, and then it
was used _again_ to add a reference for the same block from a different
snapshot. This resulted in something like this in the delayed ref tree
add ref to 90234880, parent=2067398656, ref_root 1766, level 1
del ref to 90234880, parent=2067398656, ref_root 18446744073709551608, level 1
add ref to 90234880, parent=2067398656, ref_root 1767, level 1
as you can see the ref_root's don't match, because when we inc the ref we use
the header owner, which is the original tree the block belonged to, instead of
the data reloc tree. Then when we remove the extent we use the reloc tree
objectid. But none of this matters, since it is a shared reference which means
only the parent matters. When the delayed ref stuff runs it adds all the
increments first, and then does all the drops, to make sure that we don't delete
the ref if we net a positive ref count. But tree blocks aren't allowed to have
multiple refs from the same block, so this panics when it tries to add the
second ref. We need the add and the drop to cancel each other out in memory so
we only do the final add.
So to fix this we need to adjust how the delayed refs are added to the tree.
Only the ref_root matters when it is a normal backref, and only the parent
matters when it is a shared backref. So make our decision based on what ref
type we have. This allows us to keep the ref_root in memory in case anybody
wants to use it for something else, and it allows the delayed refs to be merged
properly so we don't end up with this panic.
With this patch the users image no longer panics on mount, and it has a clean
fsck after a normal mount/umount cycle. Thanks,
Reported-by: Roman Mamedov <rm@romanrm.ru>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tracing: Fix ftrace_dump()
commit 7fe70b579c9e3daba71635e31b6189394e7b79d3 upstream.
ftrace_dump() had a lot of issues. What ftrace_dump() does, is when
ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it
will dump out the ftrace buffers to the console when either a oops,
panic, or a sysrq-z occurs.
This was written a long time ago when ftrace was fragile to recursion.
But it wasn't written well even for that.
There's a possible deadlock that can occur if a ftrace_dump() is happening
and an NMI triggers another dump. This is because it grabs a lock
before checking if the dump ran.
It also totally disables ftrace, and tracing for no good reasons.
As the ring_buffer now checks if it is read via a oops or NMI, where
there's a chance that the buffer gets corrupted, it will disable
itself. No need to have ftrace_dump() do the same.
ftrace_dump() is now cleaned up where it uses an atomic counter to
make sure only one dump happens at a time. A simple atomic_inc_return()
is enough that is needed for both other CPUs and NMIs. No need for
a spinlock, as if one CPU is running the dump, no other CPU needs
to do it too.
The tracing_on variable is turned off and not turned on. The original
code did this, but it wasn't pretty. By just disabling this variable
we get the result of not seeing traces that happen between crashes.
For sysrq-z, it doesn't get turned on, but the user can always write
a '1' to the tracing_on file. If they are using sysrq-z, then they should
know about tracing_on.
The new code is much easier to read and less error prone. No more
deadlock possibility when an NMI triggers here.
Reported-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7fe70b579c9e3daba71635e31b6189394e7b79d3 upstream.
ftrace_dump() had a lot of issues. What ftrace_dump() does, is when
ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it
will dump out the ftrace buffers to the console when either a oops,
panic, or a sysrq-z occurs.
This was written a long time ago when ftrace was fragile to recursion.
But it wasn't written well even for that.
There's a possible deadlock that can occur if a ftrace_dump() is happening
and an NMI triggers another dump. This is because it grabs a lock
before checking if the dump ran.
It also totally disables ftrace, and tracing for no good reasons.
As the ring_buffer now checks if it is read via a oops or NMI, where
there's a chance that the buffer gets corrupted, it will disable
itself. No need to have ftrace_dump() do the same.
ftrace_dump() is now cleaned up where it uses an atomic counter to
make sure only one dump happens at a time. A simple atomic_inc_return()
is enough that is needed for both other CPUs and NMIs. No need for
a spinlock, as if one CPU is running the dump, no other CPU needs
to do it too.
The tracing_on variable is turned off and not turned on. The original
code did this, but it wasn't pretty. By just disabling this variable
we get the result of not seeing traces that happen between crashes.
For sysrq-z, it doesn't get turned on, but the user can always write
a '1' to the tracing_on file. If they are using sysrq-z, then they should
know about tracing_on.
The new code is much easier to read and less error prone. No more
deadlock possibility when an NMI triggers here.
Reported-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix handling of v6 power tables
commit 441e76ca83ac604eaf0f046def96d8e3a27eea28 upstream.
The code was mis-handling variable sized arrays.
Reported-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 441e76ca83ac604eaf0f046def96d8e3a27eea28 upstream.
The code was mis-handling variable sized arrays.
Reported-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: add new richland pci ids
commit 62d1f92e06aef9665d71ca7e986b3047ecf0b3c7 upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 62d1f92e06aef9665d71ca7e986b3047ecf0b3c7 upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix possible segfault when parsing pm tables
commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream.
If we have a empty power table, bail early and allocate
the default power state.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=63865
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream.
If we have a empty power table, bail early and allocate
the default power state.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=63865
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream.
Reviwed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream.
Reviwed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
commit e884fc640ccbdb6f94b9bdb57cfb8464b6688f4c upstream.
Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.
v2: blank displays first, then disable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e884fc640ccbdb6f94b9bdb57cfb8464b6688f4c upstream.
Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.
v2: blank displays first, then disable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: Always flush the VM
commit 466476dfdcafbb4286ffa232a3a792731b9dc852 upstream.
This is slightly cleaned up version of Jerome's patch.
There seems to be an issue tracking the last flush of
the VM which results in hangs in certain cases when
VM is used. For now just flush the VM for every IB.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=62959
https://bugs.freedesktop.org/show_bug.cgi?id=62997
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 466476dfdcafbb4286ffa232a3a792731b9dc852 upstream.
This is slightly cleaned up version of Jerome's patch.
There seems to be an issue tracking the last flush of
the VM which results in hangs in certain cases when
VM is used. For now just flush the VM for every IB.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=62959
https://bugs.freedesktop.org/show_bug.cgi?id=62997
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix typo in si_select_se_sh()
commit 79b52d6a7085a3e430c6de450a5847fdbe04159b upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 79b52d6a7085a3e430c6de450a5847fdbe04159b upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
commit dcb852905772416e322536ced5cb3c796d176af5 upstream.
These chips were previously skipped since they are
pre-R600.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcb852905772416e322536ced5cb3c796d176af5 upstream.
These chips were previously skipped since they are
pre-R600.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: cleanup properly if mmio mapping fails
commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream.
If we fail to map the mmio BAR, skip driver tear down
that requires mmio.
Should fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56541
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream.
If we fail to map the mmio BAR, skip driver tear down
that requires mmio.
Should fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56541
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS
commit 2e97be73e5f74a317232740ae82eb8f95326a660 upstream.
Avoids potential interrupt storms when the display is disabled.
May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56041
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e97be73e5f74a317232740ae82eb8f95326a660 upstream.
Avoids potential interrupt storms when the display is disabled.
May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56041
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: add some new SI PCI ids
commit 18932a28419596bc9403770f5d8a108c5433fe59 upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18932a28419596bc9403770f5d8a108c5433fe59 upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
commit abf1457bbbe4c62066bd03c6d31837dea28644dc upstream.
Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57567
https://bugs.freedesktop.org/show_bug.cgi?id=43655
https://bugzilla.kernel.org/show_bug.cgi?id=56441
v2: blank displays first, then disable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit abf1457bbbe4c62066bd03c6d31837dea28644dc upstream.
Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57567
https://bugs.freedesktop.org/show_bug.cgi?id=43655
https://bugzilla.kernel.org/show_bug.cgi?id=56441
v2: blank displays first, then disable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: update wait_for_vblank for r1xx-r4xx
commit 2b48b968c0d00aa5ab520b65a15a4f374cda7dda upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b48b968c0d00aa5ab520b65a15a4f374cda7dda upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx
commit 2f86e2ede39a98650c2d465857405ef1c51372b1 upstream.
Need to wait for the new addresses to take affect before
re-enabling the MC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f86e2ede39a98650c2d465857405ef1c51372b1 upstream.
Need to wait for the new addresses to take affect before
re-enabling the MC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: properly lock disp in mc_stop/resume for evergreen+
commit 968c01664ccbe0e46c19a1af662c4c266a904203 upstream.
Need to wait for the new addresses to take affect before
re-enabling the MC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 968c01664ccbe0e46c19a1af662c4c266a904203 upstream.
Need to wait for the new addresses to take affect before
re-enabling the MC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: update wait_for_vblank for evergreen+
commit 10257a6d8359c41407eb26b7ad7bf710a7e00155 upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 10257a6d8359c41407eb26b7ad7bf710a7e00155 upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: update wait_for_vblank for r5xx-r7xx
commit bea5497bfc1067620c8c8e9d37a42e0bb6d7d7fa upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bea5497bfc1067620c8c8e9d37a42e0bb6d7d7fa upstream.
Properly wait for the next vblank region. The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon/dce6: add missing display reg for tiling setup
commit 7c1c7c18fc752b2a1d07597286467ef186312463 upstream.
A new tiling config register for the display blocks was
added on DCE6.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=62889
https://bugs.freedesktop.org/show_bug.cgi?id=57919
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c1c7c18fc752b2a1d07597286467ef186312463 upstream.
A new tiling config register for the display blocks was
added on DCE6.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=62889
https://bugs.freedesktop.org/show_bug.cgi?id=57919
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix typo in rv515_mc_resume()
commit 367cbe2fec9b57b72605e2ac4cfd4f2fa823a256 upstream.
Doesn't affect anything as the same address gets written
in both cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 367cbe2fec9b57b72605e2ac4cfd4f2fa823a256 upstream.
Doesn't affect anything as the same address gets written
in both cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>