Re: [PATCH V2 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
On 10/26/15, Anju T wrote: > This short patch series add the ability to sample the interrupted > machine state for each hardware sample Hi, how can we check your patch series without testing details? > > Anju (3): > perf/powerpc:add ability to sample intr machine state in power > tools/perf:Map the ID values with register names > perf/powerpc:add support for sampling intr machine state > > > arch/powerpc/Kconfig| 1 + > arch/powerpc/include/uapi/asm/perf_regs.h | 55 + > arch/powerpc/perf/Makefile | 1 + > arch/powerpc/perf/perf_regs.c | 87 > tools/perf/arch/powerpc/include/perf_regs.h | 118 > > tools/perf/config/Makefile | 5 ++ > 6 files changed, 267 insertions(+) > create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h > create mode 100644 arch/powerpc/perf/perf_regs.c > create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h > > -- > 2.1.0 > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 06/17] scsi :ufs: verify hba controller hce reg value
> 2015-09-13 23:52 GMT+09:00 Yaniv Gardi : >> Sometimes due to hw issues it takes some time to the >> host controller register to update. In order to verify the register >> has updated, a polling is done until its value is set. >> >> In addition the functions ufshcd_hba_stop() and >> ufshcd_wait_for_register() was updated with an additional input >> parameter, indicating the timeout between reads will >> be done by sleeping or spinning the cpu. >> >> Signed-off-by: Raviv Shvili >> Signed-off-by: Yaniv Gardi >> >> --- >> drivers/scsi/ufs/ufshcd.c | 54 >> --- >> drivers/scsi/ufs/ufshcd.h | 12 +++ >> 2 files changed, 35 insertions(+), 31 deletions(-) >> >> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >> index 6171da8..e5a876c 100644 >> --- a/drivers/scsi/ufs/ufshcd.c >> +++ b/drivers/scsi/ufs/ufshcd.c >> @@ -267,11 +267,12 @@ static inline void ufshcd_disable_irq(struct >> ufs_hba *hba) >> * @val - wait condition >> * @interval_us - polling interval in microsecs >> * @timeout_ms - timeout in millisecs >> - * >> + * @can_sleep - perform sleep or just spin >> * Returns -ETIMEDOUT on error, zero on success >> */ > > We usually put a blank line between @argument description and > return value description. > will be fixed in v2. thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
RTC found in s2mps15 is almost same as one found in s2mps14.
This patch add required changes to enable s2mps15 rtc timer.
Signed-off-by: Alim Akhtar
---
drivers/rtc/rtc-s5m.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..ac3286a267ba 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
val &= S5M_ALARM0_STATUS;
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -253,6 +254,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
data &= ~S5M_RTC_TIME_EN_MASK;
break;
case S2MPS14X:
+ case S2MPS15X:
data |= S2MPS_RTC_RUDR_MASK;
break;
case S2MPS13X:
@@ -317,7 +319,8 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;
- if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+ if (info->device_type == S2MPS14X || info->device_type == S2MPS15X ||
+ info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +342,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +370,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +419,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
@@ -463,6 +469,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +515,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +556,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_tm_to_data(>time, data);
@@ -631,6 +640,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
@@ -679,6 +689,7 @@ static int s5m_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
regmap_cfg = _rtc_regmap_config;
@@ -805,6 +816,7 @@ static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc",S5M8767X },
{ "s2mps13-rtc",S2MPS13X },
{ "s2mps14-rtc",S2MPS14X },
+ { "s2mps15-rtc",S2MPS15X },
{ },
};
MODULE_DEVICE_TABLE(platform, s5m_rtc_id);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording
On 26/10/15 14:39, Wangnan (F) wrote: > > > On 2015/10/26 20:24, Adrian Hunter wrote: >> On 26/10/15 13:41, Wang Nan wrote: >>> evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837 >>> (perf evlist: Add 'system_wide' option), which is used for mixing evsels >>> that aren't system-wide with ones that are [1]. However, for global >>> system wide recording (perf record -a ...), evsel->system_wide is set >>> to false, which is confusion. >>> >>> This patch set evsel->system_wide to true if the target.system_wide is >>> set, which makes evsel->system_wide a reliable way to describe whether >>> itself is system_wide or not. >>> >>> [1] http://lkml.kernel.org/r/562df19b.2080...@intel.com >>> >>> Signed-off-by: Wang Nan >>> Cc: Adrian Hunter >>> Cc: Arnaldo Carvalho de Melo >>> Cc: Alexei Starovoitov >>> Cc: Peter Zijlstra >>> Cc: Li Zefan >>> Cc: pi3or...@163.com >>> Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org >>> --- >>> tools/perf/util/evsel.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c >>> index 3ac4ee9c..36ecf0e 100644 >>> --- a/tools/perf/util/evsel.c >>> +++ b/tools/perf/util/evsel.c >>> @@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel, >>> struct record_opts *opts) >>> int track = evsel->tracking; >>> bool per_cpu = opts->target.default_per_cpu && >>> !opts->target.per_thread; >>> +evsel->system_wide = opts->target.system_wide; >> Well that breaks the way evsel->system_wide is used i.e. it is a parameter >> to the evsel and here you just overwrote it. > > Currently the only user of evsel->system_wide is IPT: > > auxtrace_record__options -> intel_pt_recording_options > > and it only set it to true. > > So I think changing to this should make it safe: > > evsel->system_wide = (evsel->system_wide || opt->target.system_wide); > > Thought? That would work although it looks like a kludge. Have you looked at properly validating opts->no_inherit ? Also, aren't you neglecting target->cpu_list ? > > If we want to add further config terms we can put it to apply_config_terms(), > where we can implement something like: > > # perf record -e cycles/system-wide/ -e instruction/no-system-wide/ ... > > But currently I don't have such requirement. > > Thank you. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 02/17] scsi: ufs: add option to change default UFS power management level
> 2015-09-13 23:52 GMT+09:00 Yaniv Gardi :
>> UFS device and link can be put in multiple different low power modes
>> hence UFS driver supports multiple different low power modes.
>> By default UFS driver selects the default (optimal) low power mode
>> (which gives moderate power savings and have relatively less enter
>> and exit latencies) but we might have to tune this default power
>> mode for different chipset platforms to meet the low power
>> requirements/goals. Hence this patch adds option to change default
>> UFS low power mode (level).
>>
>> Signed-off-by: Subhash Jadavani
>> Signed-off-by: Yaniv Gardi
>
> ...
>
>> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
>> index 3196197..1d26e49 100644
>> --- a/drivers/scsi/ufs/ufs-qcom.c
>> +++ b/drivers/scsi/ufs/ufs-qcom.c
>> @@ -1195,11 +1195,12 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>> if (res) {
>> host->dev_ref_clk_ctrl_mmio =
>> devm_ioremap_resource(dev, res);
>> - if (IS_ERR(host->dev_ref_clk_ctrl_mmio)) {
>> - dev_warn(dev,
>> - "%s: could not map
>> dev_ref_clk_ctrl_mmio, err %ld\n",
>> + if (IS_ERR((__force void const *)
>> + host->dev_ref_clk_ctrl_mmio)) {
>> + dev_warn(dev, "%s: could not map
>> dev_ref_clk_ctrl_mmio, err %ld\n",
>> __func__,
>> -
>> PTR_ERR(host->dev_ref_clk_ctrl_mmio));
>> + PTR_ERR((__force void const *)
>> +
>> host->dev_ref_clk_ctrl_mmio));
>> host->dev_ref_clk_ctrl_mmio = NULL;
>> }
>> host->dev_ref_clk_en_mask = BIT(5);
>
> This change looks unrelated. Should this be belong to other patch?
>
correct, it's minor change,
but i will separate it to a different patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/7] drivers: soc: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of register from PMU IP of Exynos SoC which will be required to
configure before Suspend/Resume. Currently all these settings are done
in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
support, there is a need of this PMU driver in driver/* folder.
This driver uses existing DT binding information and there should
be no functionality change in the supported platforms.
Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/Makefile | 4 +---
drivers/soc/samsung/Kconfig| 4
drivers/soc/samsung/Makefile | 4
arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
{arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
10 files changed, 10 insertions(+), 3 deletions(-)
rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c (100%)
rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c (100%)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..874cb38 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
+ select EXYNOS_PMU
select EXYNOS_SROM if PM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2d58063..34d29df 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,9 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
- exynos3250-pmu.o exynos4-pmu.o \
- exynos5250-pmu.o exynos5420-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o exynos-smc.o firmware.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..f545d6c 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -10,4 +10,8 @@ config EXYNOS_SROM
bool
depends on ARM && ARCH_EXYNOS && PM
+config EXYNOS_PMU
+ bool
+ depends on ARCH_EXYNOS
+
endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 9c554d5..26fb489 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1 +1,5 @@
obj-$(CONFIG_EXYNOS_SROM) += exynos-srom.o
+ifdef CONFIG_ARM
+obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
+ exynos5250-pmu.o exynos5420-pmu.o
+endif
diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/soc/samsung/exynos-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/pmu.c
rename to drivers/soc/samsung/exynos-pmu.c
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/drivers/soc/samsung/exynos-pmu.h
similarity index 100%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to drivers/soc/samsung/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c
b/drivers/soc/samsung/exynos3250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos3250-pmu.c
rename to drivers/soc/samsung/exynos3250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c
b/drivers/soc/samsung/exynos4-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos4-pmu.c
rename to drivers/soc/samsung/exynos4-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c
b/drivers/soc/samsung/exynos5250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5250-pmu.c
rename to drivers/soc/samsung/exynos5250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c
b/drivers/soc/samsung/exynos5420-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5420-pmu.c
rename to drivers/soc/samsung/exynos5420-pmu.c
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+ case S2MPS15X:
+ s2mps11_reg = S2MPS15_REG_RTC_BUF;
+ clks_init = s2mps15_clks_init;
+ break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
clks_init = s2mps11_clks_init;
@@ -292,6 +315,7 @@ static const struct platform_device_id s2mps11_clk_id[] = {
{ "s2mps11-clk", S2MPS11X},
{ "s2mps13-clk", S2MPS13X},
{ "s2mps14-clk", S2MPS14X},
+ { "s2mps15-clk", S2MPS15X},
{ "s5m8767-clk", S5M8767X},
{ },
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/5] regulator: s2mps11: add support for S2MPS15 regulators
From: Thomas Abraham
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
Reviewed-by: Krzysztof Kozlowski
---
drivers/regulator/Kconfig |4 +-
drivers/regulator/s2mps11.c | 135 ++-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff557be..3e3ee5b88b3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -588,10 +588,10 @@ config REGULATOR_S2MPA01
via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
config REGULATOR_S2MPS11
- tristate "Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage regulator"
+ tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage
+This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
output regulator via I2C bus. The chip is comprised of high efficient
Buck converters including Dual-Phase Buck converter, Buck-Boost
converter, various LDOs.
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 72fc3c32db49..12c59158552c 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
/* The highest number of possible regulators for supported devices. */
@@ -661,6 +662,133 @@ static const struct regulator_desc s2mps14_regulators[] =
{
S2MPS14_BUCK1235_START_SEL),
};
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) { \
+ .name = "LDO"#num,\
+ .id = S2MPS15_LDO##num, \
+ .ops= _reg_ldo_ops, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .n_voltages = S2MPS15_LDO_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .vsel_mask = S2MPS15_LDO_VSEL_MASK,\
+ .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) { \
+ .name = "BUCK"#num, \
+ .id = S2MPS15_BUCK##num,\
+ .ops= _reg_buck_ops,\
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .ramp_delay = 12500,\
+ .n_voltages = S2MPS15_BUCK_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+ .vsel_mask = S2MPS15_BUCK_VSEL_MASK, \
+ .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(100, 0xc, 0x38, 25000),
+};
+
+/* voltage range for s2mps15 LDO 2, 6, 14,
[PATCH v3 6/7] ARCH: EXYNOS: split up exynos5420 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos5420,
PMU configuration data and functions handing data into exynos5420
SoC specific PMU file mach-exynos/exynos5420-pmu.c.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 1 +
arch/arm/mach-exynos/exynos5420-pmu.c | 280 ++
arch/arm/mach-exynos/pmu.c| 263 ---
4 files changed, 282 insertions(+), 264 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bfb23a5..2d58063 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -11,7 +11,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
exynos3250-pmu.o exynos4-pmu.o \
- exynos5250-pmu.o
+ exynos5250-pmu.o exynos5420-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 98c6bf3..4d53b68 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -48,4 +48,5 @@ extern const struct exynos_pmu_data exynos4210_pmu_data;
extern const struct exynos_pmu_data exynos4212_pmu_data;
extern const struct exynos_pmu_data exynos4412_pmu_data;
extern const struct exynos_pmu_data exynos5250_pmu_data;
+extern const struct exynos_pmu_data exynos5420_pmu_data;
#endif /* __EXYNOSPMU_H */
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c
b/arch/arm/mach-exynos/exynos5420-pmu.c
new file mode 100644
index 000..5810afe
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5420-pmu.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5420 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5420_KFC_L2_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1,
[PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 158 +++
4 files changed, 198 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+ case S2MPS15X:
+ regmap = _regmap_config;
+ break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = _irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = _irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = _irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..36d35287c3c0
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY
[PATCH v3 5/7] ARCH: EXYNOS: split up exynos5250 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos5250,
PMU configuration data and functions handing data into exynos5250
SoC specific PMU file mach-exynos/exynos5250-pmu.c.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Makefile | 4 +-
arch/arm/mach-exynos/exynos-pmu.h | 1 +
arch/arm/mach-exynos/exynos5250-pmu.c | 196 ++
arch/arm/mach-exynos/pmu.c| 180 ---
4 files changed, 200 insertions(+), 181 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos5250-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 8969683..bfb23a5 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,9 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o exynos4-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
+ exynos3250-pmu.o exynos4-pmu.o \
+ exynos5250-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 41c6a75..98c6bf3 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -47,4 +47,5 @@ extern const struct exynos_pmu_data exynos3250_pmu_data;
extern const struct exynos_pmu_data exynos4210_pmu_data;
extern const struct exynos_pmu_data exynos4212_pmu_data;
extern const struct exynos_pmu_data exynos4412_pmu_data;
+extern const struct exynos_pmu_data exynos5250_pmu_data;
#endif /* __EXYNOSPMU_H */
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c
b/arch/arm/mach-exynos/exynos5250-pmu.c
new file mode 100644
index 000..a6d4188
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5250-pmu.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5250 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_FSYS_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_FSYS_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS5_ARM_COMMON_SYS_PWR_REG, { 0x0, 0x0, 0x2} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x3, 0x3, 0x3} },
+ { EXYNOS5_ARM_L2_OPTION,{ 0x10, 0x10, 0x0 } },
+ { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+ { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+ { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+ { EXYNOS5_DDRPHY_DLLLOCK_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS5_APLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_MPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_VPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_EPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS5_BPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_CPLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_MPLLUSER_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_BPLLUSER_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS5_TOP_BUS_SYS_PWR_REG, { 0x3, 0x0, 0x0}
[PATCH v3 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Acked-by: Lee Jones --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] reporting stuck on s390 in dso__split_kallsyms_for_kcore
hi,
I'm getting stuck buildid-list command on s390
seems like the kcore code gets stuck with inseting
into rbtree while iterating it..
I was able to fix it with patch below, bu I'm not sure it's the
correct fix because the kcore maps magic is beyond me so far ;-)
please check attached backtrace and patch
(gdb) r buildid-list -i perf.data --with-hits
Starting program: /root/linux/tools/perf/./perf buildid-list -i perf.data
--with-hits
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 56723.
^C
Program received signal SIGINT, Interrupt.
rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
451 node=node->rb_left;
Missing separate debuginfos, use: debuginfo-install
audit-libs-2.4.1-5.el7.s390x bzip2-libs-1.0.6-13.el7.s390x
elfutils-libelf-0.163-3.el7.s390x elfutils-libs-0.163-3.el7.s390x
glibc-2.17-105.el7.s390x nss-softokn-freebl-3.16.2.3-13.el7_1.s390x
perl-libs-5.16.3-286.el7.s390x python-libs-2.7.5-34.el7.s390x
slang-2.2.4-11.el7.s390x xz-libs-5.1.2-12alpha.el7.s390x zlib-1.2.7-15.el7.s390x
(gdb) bt
#0 rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
#1 0x800a7da0 in dso__split_kallsyms_for_kcore
(dso=dso@entry=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
at util/symbol.c:668
#2 0x800a9ac6 in dso__load_kallsyms (dso=dso@entry=0x812e69c0,
filename=filename@entry=0x81353030 "/proc/kallsyms",
map=map@entry=0x812e6fb0, filter=filter@entry=0x0) at util/symbol.c:1289
#3 0x800aa0c4 in dso__load_kernel_sym (dso=dso@entry=0x812e69c0,
map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
at util/symbol.c:1783
#4 0x800aa208 in dso__load (dso=0x812e69c0, map=map@entry=0x812e6fb0,
filter=filter@entry=0x0) at util/symbol.c:1420
#5 0x800bb2aa in map__load (map=0x812e6fb0, filter=0x0) at
util/map.c:289
#6 0x80087c9e in thread__find_addr_map (thread=,
cpumode=cpumode@entry=1 '\001', type=type@entry=MAP__FUNCTION,
addr=, al=al@entry=0x3ffe118) at util/event.c:969
#7 0x80081908 in build_id__mark_dso_hit (tool=,
event=0x3fffd5aa568, sample=0x3ffe410, evsel=,
machine=) at util/build-id.c:41
#8 0x800bdfec in perf_evlist__deliver_sample
(evlist=evlist@entry=0x812e5d60,
tool=tool@entry=0x8024b240 ,
event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffe410,
evsel=evsel@entry=0x812e6770, machine=0x812e5ab8) at util/session.c:1039
#9 0x800be156 in machines__deliver_event
(machines=machines@entry=0x812e5ab8, evlist=0x812e5d60,
event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffe410,
tool=tool@entry=0x8024b240 ,
file_offset=136552) at util/session.c:1076
#10 0x800be3f2 in perf_session__deliver_event
(session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
sample=sample@entry=0x3ffe410, tool=tool@entry=0x8024b240
, file_offset=)
at util/session.c:1133
#11 0x800c0146 in perf_session__process_event
(session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
file_offset=file_offset@entry=136552) at util/session.c:1298
#12 0x800c0746 in __perf_session__process_events
(session=session@entry=0x812e59e0, data_offset=,
data_size=, file_size=1164232, file_size@entry=1166128) at
util/session.c:1633
#13 0x800c0c2c in perf_session__process_events
(session=session@entry=0x812e59e0) at util/session.c:1683
#14 0x8002ae5e in perf_session__list_build_ids (force=,
with_hits=true) at builtin-buildid-list.c:82
#15 0x8002b078 in cmd_buildid_list (argc=,
argv=, prefix=)
at builtin-buildid-list.c:115
#16 0x8007c71a in run_builtin (p=p@entry=0x8024aab8 ,
argc=argc@entry=4, argv=0x3fff090) at perf.c:385
#17 0x8007c95e in handle_internal_command (argc=,
argv=) at perf.c:445
#18 0x8007c9e4 in run_argv (argcp=argcp@entry=0x3ffedd4,
argv=argv@entry=0x3ffedc8) at perf.c:489
#19 0x8007cca2 in main (argc=4, argv=0x3fff090) at perf.c:606
thanks,
jirka
---
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7bf0c4..b0d2fb2 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso,
struct map *map,
pos->start -= curr_map->start - curr_map->pgoff;
if (pos->end)
pos->end -= curr_map->start - curr_map->pgoff;
- if (curr_map != map) {
+ if (curr_map->dso != map->dso) {
rb_erase_init(>rb_node, root);
symbols__insert(
_map->dso->symbols[curr_map->type],
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
[PATCH v3 4/7] ARCH: EXYNOS: split up exynos4 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos4210,
exynos4412 and exynos4212 PMU configuration data and functions handing
data into a common exynos4 SoC specific PMU file mach-exynos/exynos4-pmu.c.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 3 +
arch/arm/mach-exynos/exynos4-pmu.c | 223 +
arch/arm/mach-exynos/pmu.c | 207 --
4 files changed, 227 insertions(+), 208 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos4-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index e869f86..8969683 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o exynos4-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
index 2da4964..41c6a75 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -44,4 +44,7 @@ static inline u32 pmu_raw_readl(u32 offset)
/* list of all exported SoC specific data */
extern const struct exynos_pmu_data exynos3250_pmu_data;
+extern const struct exynos_pmu_data exynos4210_pmu_data;
+extern const struct exynos_pmu_data exynos4212_pmu_data;
+extern const struct exynos_pmu_data exynos4412_pmu_data;
#endif /* __EXYNOSPMU_H */
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c
b/arch/arm/mach-exynos/exynos4-pmu.c
new file mode 100644
index 000..4b0a79e
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos4-pmu.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4 - CPU PMU(Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+ { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE1,{ 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_COMMON_LOWPWR,{ 0x0, 0x0, 0x2 } },
+ { S5P_L2_0_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_L2_1_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_CMU_ACLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SCLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_APLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_MPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_VPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_EPLL_SYSCLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPSALIVE_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_TV_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD0_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD1_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MAUDIO_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_TV_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD0_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD1_LOWPWR,{ 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_TOP_BUS_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_TOP_RETENTION_LOWPWR, { 0x1, 0x0, 0x1 } },
+ {
[PATCH v3 0/5] mfd: sec: add S2MPS15 PMIC support
Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC. The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains 27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows programming these blocks via a I2C interface. This patch series adds initial support for LDO/Buck regulators of S2MPS15 PMIC. Changes since v2: * Addressed Lee Jones review comments. Changes since v1: * Added suggestion from Krzysztof [1]. * Added s2mps15's 32.768 clocks support. * Added s2mps15's rtc support. V1 of these patches (with a lesser features) were posted a year back, since then there is not much progress on this, this is my attempt to move things forward. [1]-> https://lkml.org/lkml/2014/10/14/67 This series is based on linux-next-20151022. This is tested on exynos7-espresso board. Alim Akhtar (2): clk: s2mps15: Add support for S2MPS15 clocks drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC Thomas Abraham (3): dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC mfd: sec: Add support for S2MPS15 PMIC regulator: s2mps11: add support for S2MPS15 regulators Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 +-- drivers/clk/Kconfig |5 +- drivers/clk/clk-s2mps11.c | 24 drivers/mfd/sec-core.c| 31 drivers/mfd/sec-irq.c |8 ++ drivers/regulator/Kconfig |4 +- drivers/regulator/s2mps11.c | 135 +- drivers/rtc/rtc-s5m.c | 14 +- include/linux/mfd/samsung/core.h |1 + include/linux/mfd/samsung/s2mps15.h | 158 + 10 files changed, 389 insertions(+), 14 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mps15.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/7] ARCH: EXYNOS: split up exynos3250 SoC specific PMU data
This patch splits up mach-exynos/pmu.c file, and moves exynos3250 PMU
configuration data and functions handing those data into exynos3250
SoC specific PMU file mach-exynos/exynos3250-pmu.c.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/Makefile | 2 +-
arch/arm/mach-exynos/exynos-pmu.h | 47 +
arch/arm/mach-exynos/exynos3250-pmu.c | 175 +++
arch/arm/mach-exynos/pmu.c| 189 +-
4 files changed, 224 insertions(+), 189 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
create mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2f30676..e869f86 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
-I$(srctree)/$(src)/include -I$(srctree)
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o
exynos3250-pmu.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..2da4964
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOSPMU_H
+#define __EXYNOSPMU_H
+
+#include
+
+#define PMU_TABLE_END (-1U)
+
+extern void __iomem *pmu_base_addr;
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ u8 val[NUM_SYS_POWERDOWN];
+};
+
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+ void (*powerdown_conf_extra)(enum sys_powerdown);
+};
+
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ writel_relaxed(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return readl_relaxed(pmu_base_addr + offset);
+}
+
+/* list of all exported SoC specific data */
+extern const struct exynos_pmu_data exynos3250_pmu_data;
+#endif /* __EXYNOSPMU_H */
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c
b/arch/arm/mach-exynos/exynos3250-pmu.c
new file mode 100644
index 000..20b3ab8
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos3250-pmu.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS3250 - CPU PMU (Power Management Unit) support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos3250_pmu_config[] = {
+ /* { .offset = offset, .val = { AFTR, W-AFTR, SLEEP } */
+ { EXYNOS3_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+ { EXYNOS3_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+ { EXYNOS3_ARM_COMMON_SYS_PWR_REG, { 0x0, 0x0, 0x2} },
+ { EXYNOS3_ARM_L2_SYS_PWR_REG, { 0x0, 0x0, 0x3} },
+ { EXYNOS3_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS3_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+ { EXYNOS3_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+ { EXYNOS3_DRAM_FREQ_DOWN_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS3_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+ { EXYNOS3_LPDDR_PHY_DLL_LOCK_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+ { EXYNOS3_CMU_ACLKSTOP_COREBLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS3_CMU_SCLKSTOP_COREBLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ { EXYNOS3_CMU_RESET_COREBLK_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+ { EXYNOS3_APLL_SYSCLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+ {
[PATCH v3 2/7] ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
Moving Exynos PMU specific header file into "include/linux/soc/samsung"
thus updated affected files under "mach-exynos" to use new location of
these header files.
Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/exynos.c | 2 +-
arch/arm/mach-exynos/mcpm-exynos.c| 2 +-
arch/arm/mach-exynos/platsmp.c| 2 +-
arch/arm/mach-exynos/pm.c | 4 ++--
arch/arm/mach-exynos/pmu.c| 6 +++---
arch/arm/mach-exynos/suspend.c| 4 ++--
{arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h | 2 +-
.../regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h | 8
8 files changed, 15 insertions(+), 15 deletions(-)
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (90%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (99%)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4ffb90e..5d68ce8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,7 +32,6 @@
#include "common.h"
#include "mfc.h"
-#include "regs-pmu.h"
void __iomem *pmu_base_addr;
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 5697819..f086bf6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -16,13 +16,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include "regs-pmu.h"
#include "common.h"
#define EXYNOS5420_CPUS_PER_CLUSTER4
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 98a2c0c..d5caf30 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,7 +31,6 @@
#include
#include "common.h"
-#include "regs-pmu.h"
extern void exynos4_secondary_startup(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 9c1506b..b9b9186 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -29,8 +31,6 @@
#include
#include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
static inline void __iomem *exynos_boot_vector_addr(void)
{
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index d936ffa..acbb012 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -17,10 +17,10 @@
#include
#include
-#include
+#include
+#include
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
+#include
#define PMU_TABLE_END (-1U)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 21abd9b..d02f7c3 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -36,8 +38,6 @@
#include
#include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
#define REG_TABLE_END (-1U)
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/include/linux/soc/samsung/exynos-pmu.h
similarity index 90%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to include/linux/soc/samsung/exynos-pmu.h
index a2ab0d5..50dd0aa 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* Header for EXYNOS PMU Driver support
diff --git a/arch/arm/mach-exynos/regs-pmu.h
b/include/linux/soc/samsung/exynos-regs-pmu.h
similarity index 99%
rename from arch/arm/mach-exynos/regs-pmu.h
rename to include/linux/soc/samsung/exynos-regs-pmu.h
index 5e4f4c2..3a5b7ff 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
* http://www.samsung.com
*
* EXYNOS - Power management unit definition
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __ASM_ARCH_REGS_PMU_H
-#define __ASM_ARCH_REGS_PMU_H __FILE__
+#ifndef __EXYNOS_REGS_PMU_H
+#define __EXYNOS_REGS_PMU_H __FILE__
#define S5P_CENTRAL_SEQ_CONFIGURATION 0x0200
@@ -690,4 +690,4 @@
| EXYNOS5420_KFC_USE_STANDBY_WFI2 \
| EXYNOS5420_KFC_USE_STANDBY_WFI3)
-#endif /* __ASM_ARCH_REGS_PMU_H */
+#endif /* __EXYNOS_REGS_PMU_H */
--
Re: [PATCH v3 1/4] wait.[ch]: Introduce the simple waitqueue (swait) implementation
Hi Boqun,
On 10/26/2015 01:04 PM, Boqun Feng wrote:
> On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
>> +
>> +/*
>> + * The thing about the wake_up_state() return value; I think we can ignore
>> it.
>> + *
>> + * If for some reason it would return 0, that means the previously waiting
>> + * task is already running, so it will observe condition true (or has
>> already).
>> + */
>> +void swake_up_locked(struct swait_queue_head *q)
>> +{
>> +struct swait_queue *curr;
>> +
>> +list_for_each_entry(curr, >task_list, task_list) {
>> +wake_up_process(curr->task);
>> +list_del_init(>task_list);
>> +break;
>
> Just be curious, what's this break for? Or what's this loop(?) for?
I have to guess here, since Peter wrote it. It looks like the function
is based on __wake_up_common(). Though I agree the loop is not necessary
and something like below should the trick. Unless I do not see something
important.
void swake_up_locked(struct swait_queue_head *q)
{
struct swait_queue *curr;
if (list_emtpy())
return;
curr = list_first_entry(, typeof(*curr), task_list);
wake_up_process(curr->task);
list_del_init(>task_list);
}
If Peter is not complaining I change swake_up_locked() for the next version.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/15] scsi: ufs: increase fDeviceInit query response timeout
2015-10-25 22:38 GMT+09:00 :
>> 2015-09-02 19:13 GMT+09:00 Yaniv Gardi :
>>> fDeviceInit query response time for some devices is too long that
>>> default
>>> query request timeout of 100ms may not be enough. Experiments show that
>>> fDeviceInit response sometimes takes 500ms so to be on safer side this
>>> change sets the timeout to 600ms. Without this change, we might
>>> unnecessarily have to retry fDeviceInit query requests multiple times
>>> and
>>> each query request timeout prints one error message.
>>>
>>> Signed-off-by: Subhash Jadavani
>>> Signed-off-by: Yaniv Gardi
>>>
>>> ---
>>> drivers/scsi/ufs/ufshcd.c | 12 +++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index e0b8755..573a8cb 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -58,6 +58,12 @@
>>> #define QUERY_REQ_RETRIES 10
>>> /* Query request timeout */
>>> #define QUERY_REQ_TIMEOUT 30 /* msec */
>>> +/*
>>> + * Query request timeout for fDeviceInit flag
>>> + * fDeviceInit query response time for some devices is too large that
>>> default
>>> + * QUERY_REQ_TIMEOUT may not be enough for such devices.
>>> + */
>>> +#define QUERY_FDEVICEINIT_REQ_TIMEOUT 600 /* msec */
>>
>> How about just increasing QUERY_REQ_TIMEOUT from 30ms to 600ms
>> instead of conditionally setting timeout depending on ufs flag?
>
> Your suggestion obviously could work (increasing the QUERY_REQ_TIMEOUT to
> 600ms), but in that case we bring extra delay of 570ms to error handling
> of query timeout, and in such a case, instead of handling the error after
> 30ms we handle it after 600ms, which make the SW hang.
> does it make sense ?
Compared to default scsi disk timeout (30s), 600ms does not look very
long. I was just worried that the code gets complicated if we need to
add yet another QUERY_XYZ_REQ_TIMEOUT macros when it turns out that
30ms timeout is not enough for other query requests under specific
conditions. But I don't too much care about it for now.
>>
>>>
>>> /* Task management command timeout */
>>> #define TM_CMD_TIMEOUT 100 /* msecs */
>>> @@ -1651,6 +1657,7 @@ static int ufshcd_query_flag(struct ufs_hba *hba,
>>> enum query_opcode opcode,
>>> struct ufs_query_req *request = NULL;
>>> struct ufs_query_res *response = NULL;
>>> int err, index = 0, selector = 0;
>>> + int timeout = QUERY_REQ_TIMEOUT;
>>>
>>> BUG_ON(!hba);
>>>
>>> @@ -1683,7 +1690,10 @@ static int ufshcd_query_flag(struct ufs_hba *hba,
>>> enum query_opcode opcode,
>>> goto out_unlock;
>>> }
>>>
>>> - err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY,
>>> QUERY_REQ_TIMEOUT);
>>> + if (idn == QUERY_FLAG_IDN_FDEVICEINIT)
>>> + timeout = QUERY_FDEVICEINIT_REQ_TIMEOUT;
>>> +
>>> + err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, timeout);
>>>
>>> if (err) {
>>> dev_err(hba->dev,
>>> --
>>> 1.8.5.2
>>>
>>> --
>>> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
>>> member of Code Aurora Forum, hosted by The Linux Foundation
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/7] ARM: EXYNOS: removing redundant code from regs-pmu.h
commit 6ec4f8d0d91f ("ARM: EXYNOS: add generic function to calculate
cpu number") introduced exynos_pmu_cpunr to be used by multi-cluster SoC's
e.g Exynos5420, but it's no more used in the codebase and hence removing
this part of code.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/pmu.c | 1 +
arch/arm/mach-exynos/regs-pmu.h | 9 -
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index de68938..d936ffa 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include "exynos-pmu.h"
#include "regs-pmu.h"
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index fba9068..5e4f4c2 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -484,15 +484,6 @@
#define EXYNOS5420_SWRESET_KFC_SEL 0x3
-#include
-#define MAX_CPUS_IN_CLUSTER4
-
-static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
-{
- return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
-+ MPIDR_AFFINITY_LEVEL(mpidr, 0));
-}
-
/* Only for EXYNOS5420 */
#define EXYNOS5420_ISP_ARM_OPTION 0x2488
#define EXYNOS5420_L2RSTDISABLE_VALUE BIT(3)
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/7] samsung: pmu: split up SoC specific PMU data
This patch series is a part of continuation work from following series
[1] and [2].
1: exynos: Move pmu driver to driver/soc folder and add exynos7 support
http://www.spinics.net/lists/linux-samsung-soc/msg39797.html from Amit
Daniel Kacchap
2: soc: samsung: pmu: split up SoC specific PMU data
https://lkml.org/lkml/2015/1/7/12 from me
Here is another attempt for the same, in this series I am splitting up SoC
specific PMU configuration data into mach-exynos folder itself, before moving
all of them under drivers/soc/samsung/. Also instead of making all changes in
single patch it has been broken into SoC specific patches to avoid large size
of patch. With this approach there will not be unwanted big churns just after
adding exynos-pmu under drivers/soc/samsung.
All these patches are just refactoring to keep minimal changes while moving
exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can be
added
on top of it, in such a manner that for ARM64 build, ARM related SoC's PMU will
not
get compiled and thus unnecessary increasing kernel image size.
I have tested on Peach-Pi (Exynos5880) based chromebook for boot
and S2R functionality.
These patches have been prepared on top of Kukjin Kim's for-next
Changes since v2:
- Removed Amit's Samsung id as it's no more valid.
- Rebased on latest kgene tree.
- Removed redundant code from regs-pmu.h
Pankaj Dubey (7):
ARM: EXYNOS: removing redundant code from regs-pmu.h
ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
ARCH: EXYNOS: split up exynos3250 SoC specific PMU data
ARCH: EXYNOS: split up exynos4 SoC specific PMU data
ARCH: EXYNOS: split up exynos5250 SoC specific PMU data
ARCH: EXYNOS: split up exynos5420 SoC specific PMU data
drivers: soc: Add support for Exynos PMU driver
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/Makefile |2 +-
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/mcpm-exynos.c |2 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c |4 +-
arch/arm/mach-exynos/pmu.c | 1004
arch/arm/mach-exynos/suspend.c |4 +-
drivers/soc/samsung/Kconfig|4 +
drivers/soc/samsung/Makefile |4 +
drivers/soc/samsung/exynos-pmu.c | 168
drivers/soc/samsung/exynos-pmu.h | 52 +
drivers/soc/samsung/exynos3250-pmu.c | 175
drivers/soc/samsung/exynos4-pmu.c | 223 +
drivers/soc/samsung/exynos5250-pmu.c | 196
drivers/soc/samsung/exynos5420-pmu.c | 280 ++
.../linux/soc/samsung}/exynos-pmu.h|2 +-
.../linux/soc/samsung/exynos-regs-pmu.h| 17 +-
18 files changed, 1116 insertions(+), 1026 deletions(-)
delete mode 100644 arch/arm/mach-exynos/pmu.c
create mode 100644 drivers/soc/samsung/exynos-pmu.c
create mode 100644 drivers/soc/samsung/exynos-pmu.h
create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
create mode 100644 drivers/soc/samsung/exynos4-pmu.c
create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (90%)
rename arch/arm/mach-exynos/regs-pmu.h =>
include/linux/soc/samsung/exynos-regs-pmu.h (98%)
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 3/4] PM / sleep: Go direct_complete if driver has no callbacks
Hi Tomeu, On Wed, Oct 21, 2015 at 11:34 PM, Tomeu Vizoso wrote: > If a suitable prepare callback cannot be found for a given device and > its driver has no PM callbacks at all, assume that it can go direct to > complete when the system goes to sleep. > > The reason for this is that there's lots of devices in a system that do > no PM at all and there's no reason for them to prevent their ancestors > to do direct_complete if they can support it. > > Signed-off-by: Tomeu Vizoso > Reviewed-by: Ulf Hansson > --- [snip...] > diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c > index a70f8a5cdfd7..763eee24cb95 100644 > --- a/drivers/base/power/common.c > +++ b/drivers/base/power/common.c > @@ -14,6 +14,8 @@ > #include > #include > > +#include "power.h" > + > /** > * dev_pm_get_subsys_data - Create or refcount power.subsys_data for device. > * @dev: Device to handle. > @@ -147,5 +149,6 @@ void dev_pm_domain_set(struct device *dev, struct > dev_pm_domain *pd) > WARN(device_is_bound(dev), > "PM domains can only be changed for unbound devices\n"); > dev->pm_domain = pd; > + device_pm_check_callbacks(dev); device_pm_check_callbacks(dev) grabs spin_lock_irq(>power.lock); But, one of the callers of dev_pm_domain_set() that you just added in the previous patch "PM / Domains: add setter for dev.pm_domain" also grabs this same spinlock: diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 16550c63d611..b75d02aa8d93 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1240,7 +1240,7 @@ static struct generic_pm_domain_data *genpd_alloc_dev_data(struct device *dev, } dev->power.subsys_data->domain_data = _data->base; - dev->pm_domain = >domain; + dev_pm_domain_set(dev, >domain); spin_unlock_irq(>power.lock); At least on the board I am testing, this causes a deadlock on boot. -Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper
On 2015/10/26 20:32, Peter Zijlstra wrote: On Sun, Oct 25, 2015 at 09:23:36AM -0700, Alexei Starovoitov wrote: bpf_perf_event_read() muxes of -EINVAL into return value, but it's non ambiguous to the program whether it got an error or real counter value. How can that be, the (u64)-EINVAL value is a valid counter value.. unlikely maybe, but still quite possible. In our real usecase we simply treat return value larger than 0x7fff as error result. We can make it even larger, for example, to 0x. Resuling values can be pre-processed by a script to filter potential error result out so it is not a very big problem for our real usecases. For a better interface, I suggest u64 bpf_perf_event_read(bool *perror); which still returns counter value through its return value but put error code to stack. Then BPF program can pass NULL to the function if BPF problem doesn't want to deal with error code. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 26 October 2015 at 11:51, Michael Turquette wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. > > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. Alexander Holler has been looking at that for some time already. Regards, Tomeu > Regards, > Mike > >> >> If the dependency could only be discovered at the probe time, the >> order of things might be changed in response to letting the driver >> core know about it rather than "just in case", which should be more >> efficient. >> >> Thanks, >> Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
On 10/26/2015 04:39 PM, Lee Jones wrote: On Mon, 26 Oct 2015, Alim Akhtar wrote: From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) Nothing to controversial here. For my own reference: Acked-by: Lee Jones Thanks, will send v3 of this series. diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
Hi Lee,
Thanks for looking into this.
On 10/26/2015 04:36 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
Why don't these have compatibles?
s2mps15-pmic does have compatible below in sec_dt_match[].
s2mps15-rtc does not need one as rtc driver does not support OF yet.
So no DT node for this as of now.
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+ case S2MPS15X:
+ regmap = _regmap_config;
+ break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = _irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = _irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = _irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..7443af6a4bba
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,161 @@
+/*
+ * s2mps15.h
Remove this please.
Ok will do.
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ *
Re: [PATCH v4] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On 10/26/2015 11:26 AM, Bharat Kumar Gogada wrote: >>> + device_type = "pci"; >>> + interrupt-parent = <>; >>> + interrupts = < 0 118 4 >>> + 0 116 4 >>> + 0 115 4 // MSI_1 [63...32] >>> + 0 114 4 >; // MSI_0 [31...0] >> >> Better write these as tuples: >> >> interrupts = <0 118 4>, <0 116 4>, <0 115 4>, <0 114 4>; >> >> And maybe reverse the order? It looks that might be what the soc >> integration person had in mind. >> >> Also, what is interrupt <0 117 4>? Is that connected here as well? >> Better list it as well then, even if you don't use it. >> > We have it but not using it, we will list it. > >>> + interrupt-map-mask = <0x0 0x0 0x0 0x7>; >>> + interrupt-map = <0x0 0x0 0x0 0x1 _intc 0x1 >>> +0x0 0x0 0x0 0x2 _intc 0x2 >>> +0x0 0x0 0x0 0x3 _intc 0x3 >>> +0x0 0x0 0x0 0x4 _intc 0x4>; >> >>> + msi-parent = <_pcie>; >>> + reg = <0x0 0xfd0e 0x1000 >>> + 0x0 0xfd48 0x1000 >>> + 0x0 0xE000 0x100>; >> >> Same grouping for reg and interrupt-map as above for interrupts. > > Grouping reg and interrupt-map as tuples will make lengthy line and reduces > readability, is it compulsory ? FYI: Just this. reg = <0x0 0xfd0e 0x1000>, <0x0 0xfd48 0x1000>, <0x0 0xe000 0x100>; Also please make sure that you are using the same case for addresses. That 0xE000 case above. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] EDAC: Add ARM64 EDAC
On Wed, Oct 21, 2015 at 03:41:37PM -0500, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.
>
> Signed-off-by: Brijesh Singh
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
>
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register
> read hotplug-safe
> * add error check in probe routine
>
> .../devicetree/bindings/edac/armv8-edac.txt| 15 +
> drivers/edac/Kconfig | 6 +
> drivers/edac/Makefile | 1 +
> drivers/edac/cortex_arm64_edac.c | 457
> +
> 4 files changed, 479 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
> create mode 100644 drivers/edac/cortex_arm64_edac.c
>
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +
To counter my original point, I now believe that the MIDR alone is
woefully insufficient to detect if we can use this feature. That needs
to be described explicitly to us (e.g. via DT), or the feature needs to
be abstracted entirely (e.g. using APEI).
More on that below.
> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };
As I mentioned previously, this is _not_ an ARMv8 feature. It's not a
Cortex-A series feature (nor a Cortex series feature).
This is an IMPLEMENTATION DEFINED feature. If we need compatible
strings, we need one for each particular implementation, as we have for
the IMPLEMENTATION DEFINED PMU bindings (e.g. "arm,cortex-a57-pmu"). For
ACPI I expect vendors to implement APEI.
We also need to consider:
* big.LITTLE and/or multi-cluster
- Describe _which_ CPUs have the feature
- Describe the affinity of any interrupts
- Do we need to describe cluster topology (i.e. which CPUs are in the
same cluster)?
* Virtualization
- HCR_EL2.TIDCP will trap access to this feature, and hypervisors will
have to set this to prevent guests from corrupting the HW state. As
far as I am aware, KVM and/or Xen will likely kill the guest in this
case (e.g. by injecting an undefined instruction abort).
* Interaction with firmware
- When/do we handle interrupts?
- When is it valid to write back and clear an error? We should not do
this behind the back of any firmware that owns the interface.
* Future CPU revisions.
- The feature is IMPLEMENTATION DEFINED, and has no discoverability
mechanism. We have no guarantee that future revisions of the CPUs
currently supporting the feature will continue to support the
feature and/or have a compatible interface. Handling this is
painful.
We shy from using IMPLEMENTATION DEFINED features because of issues like
these. Ideally, this would all be left to firmware, and handled with a
generic interface like APEI.
Thanks,
Mark.
> +
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + help
> + Support for error detection and correction on the
> + ARM Cortex A57 and A53.
> endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) +=
> octeon_edac-pci.o
> obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
> obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
> obj-$(CONFIG_EDAC_XGENE) +=
[PATCH V2 1/3] perf/powerpc:add ability to sample intr machine state in power
The enum definition assigns an 'id' to each register in "struct pt_regs"
of arch/powerpc.The order of these values in the enum definition are
based on the corresponding macros in
arch/powerpc/include/uapi/asm/ptrace.h .
Signed-off-by: Anju T
---
arch/powerpc/include/uapi/asm/perf_regs.h | 55 +++
1 file changed, 55 insertions(+)
create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h
b/arch/powerpc/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..b97727c
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -0,0 +1,55 @@
+#ifndef _ASM_POWERPC_PERF_REGS_H
+#define _ASM_POWERPC_PERF_REGS_H
+
+enum perf_event_powerpc_regs {
+ PERF_REG_POWERPC_GPR0,
+ PERF_REG_POWERPC_GPR1,
+ PERF_REG_POWERPC_GPR2,
+ PERF_REG_POWERPC_GPR3,
+ PERF_REG_POWERPC_GPR4,
+ PERF_REG_POWERPC_GPR5,
+ PERF_REG_POWERPC_GPR6,
+ PERF_REG_POWERPC_GPR7,
+ PERF_REG_POWERPC_GPR8,
+ PERF_REG_POWERPC_GPR9,
+ PERF_REG_POWERPC_GPR10,
+ PERF_REG_POWERPC_GPR11,
+ PERF_REG_POWERPC_GPR12,
+ PERF_REG_POWERPC_GPR13,
+ PERF_REG_POWERPC_GPR14,
+ PERF_REG_POWERPC_GPR15,
+ PERF_REG_POWERPC_GPR16,
+ PERF_REG_POWERPC_GPR17,
+ PERF_REG_POWERPC_GPR18,
+ PERF_REG_POWERPC_GPR19,
+ PERF_REG_POWERPC_GPR20,
+ PERF_REG_POWERPC_GPR21,
+ PERF_REG_POWERPC_GPR22,
+ PERF_REG_POWERPC_GPR23,
+ PERF_REG_POWERPC_GPR24,
+ PERF_REG_POWERPC_GPR25,
+ PERF_REG_POWERPC_GPR26,
+ PERF_REG_POWERPC_GPR27,
+ PERF_REG_POWERPC_GPR28,
+ PERF_REG_POWERPC_GPR29,
+ PERF_REG_POWERPC_GPR30,
+ PERF_REG_POWERPC_GPR31,
+ PERF_REG_POWERPC_NIP,
+ PERF_REG_POWERPC_MSR,
+ PERF_REG_POWERPC_ORIG_R3,
+ PERF_REG_POWERPC_CTR,
+ PERF_REG_POWERPC_LNK,
+ PERF_REG_POWERPC_XER,
+ PERF_REG_POWERPC_CCR,
+#ifdef __powerpc64__
+ PERF_REG_POWERPC_SOFTE,
+#else
+ PERF_REG_POWERPC_MQ,
+#endif
+ PERF_REG_POWERPC_TRAP,
+ PERF_REG_POWERPC_DAR,
+ PERF_REG_POWERPC_DSISR,
+ PERF_REG_POWERPC_RESULT,
+ PERF_REG_POWERPC_MAX,
+};
+#endif /* _ASM_POWERPC_PERF_REGS_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
This short patch series add the ability to sample the interrupted machine state for each hardware sample Anju (3): perf/powerpc:add ability to sample intr machine state in power tools/perf:Map the ID values with register names perf/powerpc:add support for sampling intr machine state arch/powerpc/Kconfig| 1 + arch/powerpc/include/uapi/asm/perf_regs.h | 55 + arch/powerpc/perf/Makefile | 1 + arch/powerpc/perf/perf_regs.c | 87 tools/perf/arch/powerpc/include/perf_regs.h | 118 tools/perf/config/Makefile | 5 ++ 6 files changed, 267 insertions(+) create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h create mode 100644 arch/powerpc/perf/perf_regs.c create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/3] tools/perf:Map the ID values with register names
The id values are mapped with the corresponding register names.
This names are displayed while using a perf report/perf script command.
Signed-off-by: Anju T
---
tools/perf/arch/powerpc/include/perf_regs.h | 118
1 file changed, 118 insertions(+)
create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h
b/tools/perf/arch/powerpc/include/perf_regs.h
new file mode 100644
index 000..621aa94
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -0,0 +1,118 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+#include
+#include
+
+void perf_regs_load(u64 *regs);
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+#define PERF_REGS_MAX PERF_REG_POWERPC_MAX
+#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_64
+
+#define PERF_REG_IP PERF_REG_POWERPC_NIP
+#define PERF_REG_SP PERF_REG_POWERPC_R1
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_POWERPC_GPR0:
+ return "gpr0";
+ case PERF_REG_POWERPC_GPR1:
+ return "gpr1";
+ case PERF_REG_POWERPC_GPR2:
+ return "gpr2";
+ case PERF_REG_POWERPC_GPR3:
+ return "gpr3";
+ case PERF_REG_POWERPC_GPR4:
+ return "gpr4";
+ case PERF_REG_POWERPC_GPR5:
+ return "gpr5";
+ case PERF_REG_POWERPC_GPR6:
+ return "gpr6";
+ case PERF_REG_POWERPC_GPR7:
+ return "gpr7";
+ case PERF_REG_POWERPC_GPR8:
+ return "gpr8";
+ case PERF_REG_POWERPC_GPR9:
+ return "gpr9";
+ case PERF_REG_POWERPC_GPR10:
+ return "gpr10";
+ case PERF_REG_POWERPC_GPR11:
+ return "gpr11";
+ case PERF_REG_POWERPC_GPR12:
+ return "gpr12";
+ case PERF_REG_POWERPC_GPR13:
+ return "gpr13";
+ case PERF_REG_POWERPC_GPR14:
+ return "gpr14";
+ case PERF_REG_POWERPC_GPR15:
+ return "gpr15";
+ case PERF_REG_POWERPC_GPR16:
+ return "gpr16";
+ case PERF_REG_POWERPC_GPR17:
+ return "gpr17";
+ case PERF_REG_POWERPC_GPR18:
+ return "gpr18";
+ case PERF_REG_POWERPC_GPR19:
+ return "gpr19";
+ case PERF_REG_POWERPC_GPR20:
+ return "gpr20";
+ case PERF_REG_POWERPC_GPR21:
+ return "gpr21";
+ case PERF_REG_POWERPC_GPR22:
+ return "gpr22";
+ case PERF_REG_POWERPC_GPR23:
+ return "gpr23";
+ case PERF_REG_POWERPC_GPR24:
+ return "gpr24";
+ case PERF_REG_POWERPC_GPR25:
+ return "gpr25";
+ case PERF_REG_POWERPC_GPR26:
+ return "gpr26";
+ case PERF_REG_POWERPC_GPR27:
+ return "gpr27";
+ case PERF_REG_POWERPC_GPR28:
+ return "gpr28";
+ case PERF_REG_POWERPC_GPR29:
+ return "gpr29";
+ case PERF_REG_POWERPC_GPR30:
+ return "gpr30";
+ case PERF_REG_POWERPC_GPR31:
+ return "gpr31";
+ case PERF_REG_POWERPC_NIP:
+ return "nip";
+ case PERF_REG_POWERPC_MSR:
+ return "msr";
+ case PERF_REG_POWERPC_ORIG_R3:
+ return "orig_r3";
+ case PERF_REG_POWERPC_CTR:
+ return "ctr";
+ case PERF_REG_POWERPC_LNK:
+ return "link";
+ case PERF_REG_POWERPC_XER:
+ return "xer";
+ case PERF_REG_POWERPC_CCR:
+ return "ccr";
+#ifdef __powerpc64__
+ case PERF_REG_POWERPC_SOFTE:
+ return "softe";
+#else
+ case PERF_REG_POWERPC_MQ:
+ return "mq";
+#endif
+ case PERF_REG_POWERPC_TRAP:
+ return "trap";
+ case PERF_REG_POWERPC_DAR:
+ return "dar";
+ case PERF_REG_POWERPC_DSISR:
+ return "dsisr";
+ case PERF_REG_POWERPC_RESULT:
+ return "result";
+ default:
+ return NULL;
+ }
+ return NULL;
+}
+#endif /*ARCH_PERF_REGS_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] perf/powerpc :add support for sampling intr machine state
The registers to sample are passed through the sample_regs_intr bitmask.
The name and bit position for each register is defined in asm/perf_regs.h.
This feature can be enabled by using -I option with perf record command.
To display the sampled register values use perf script -D.
The kernel uses the "PERF" register ids to find offset of the register in
'struct pt_regs'.
CONFIG_HAVE_PERF_REGS will enable sampling of the interrupted machine state.
Signed-off-by: Anju T
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/perf/Makefile| 1 +
arch/powerpc/perf/perf_regs.c | 87 +++
tools/perf/config/Makefile| 5 +++
4 files changed, 94 insertions(+)
create mode 100644 arch/powerpc/perf/perf_regs.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5ef2711..768d700 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -116,6 +116,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select ARCH_WANT_IPC_PARSE_VERSION
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f9c083a..0d53815 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
+obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
obj-$(CONFIG_PPC64)+= $(obj64-y)
obj-$(CONFIG_PPC32)+= $(obj32-y)
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
new file mode 100644
index 000..2474dc4
--- /dev/null
+++ b/arch/powerpc/perf/perf_regs.c
@@ -0,0 +1,87 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
+
+#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
+
+static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR3, gpr[3]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR4, gpr[4]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR5, gpr[5]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR6, gpr[6]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR7, gpr[7]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR8, gpr[8]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR9, gpr[9]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR10, gpr[10]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR11, gpr[11]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR12, gpr[12]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR13, gpr[13]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR14, gpr[14]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR15, gpr[15]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR16, gpr[16]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR17, gpr[17]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR18, gpr[18]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR19, gpr[19]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR20, gpr[20]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR21, gpr[21]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR22, gpr[22]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR23, gpr[23]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR24, gpr[24]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR25, gpr[25]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR26, gpr[26]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR27, gpr[27]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR28, gpr[28]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR29, gpr[29]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR30, gpr[30]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR31, gpr[31]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_NIP, nip),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_MSR, msr),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_ORIG_R3, orig_gpr3),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_CTR, ctr),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_LNK, link),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_XER, xer),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_CCR, ccr),
+#ifdef __powerpc64__
+ PT_REGS_OFFSET(PERF_REG_POWERPC_SOFTE, softe),
+#else
+ PT_REGS_OFFSET(PERF_REG_POWERPC_MQ, mq),
+#endif
+ PT_REGS_OFFSET(PERF_REG_POWERPC_TRAP, trap),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_DAR, dar),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_DSISR, dsisr),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_RESULT, result),
+};
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE(idx >= PERF_REG_POWERPC_MAX))
+ return 0;
+ return regs_get_register(regs, pt_regs_offset[idx]);
+}
+int perf_reg_validate(u64 mask)
+{
+
Re: [PATCH v2] cpufreq: arm_big_little: fix frequency check when bL switcher is active
Quoting Jon Medhurst (Tixy) (2015-10-21 02:55:33)
> The check for correct frequency being set in bL_cpufreq_set_rate is
> broken when the big.LITTLE switcher is active, for two reasons.
>
> 1. The 'new_rate' variable gets overwritten before the test by the
> code calculating the frequency of the old cluster.
>
> 2. The frequency returned by bL_cpufreq_get_rate will be the virtual
> frequency, not the actual one the intended version of new_rate contains.
>
> This means the function always returns an error causing an endless
> stream of: "cpufreq: __target_index: Failed to change cpu frequency: -5"
>
> As the intent is to check for errors that clk_set_rate doesn't report
> lets move the check to immediately after that and directly use
> clk_get_rate, rather than the arm_big_little helpers which only confuse
> matters. Also, update the comment to be hopefully clearer about the
> purpose of the code.
>
> Fixes: 0a95e630b49a ("cpufreq: arm_big_little: check if the frequency is set
> correctly")
>
> Signed-off-by: Jon Medhurst
> Acked-by: Sudeep Holla
Reviewed-by: Michael Turquette
Fixing exception paths for clk_change_rate is on the TODO list.
Regards,
Mike
> ---
>
> Changes since V1:
> - Check rate using clk_get_rate rather than disabling check when bL
> switcher active
>
> Sudeep, I added your Ack from the last comment on the previous patch.
> This final patch differs from what was discussed only in the commit
> message and in source comment which is hopefully more clear and is
> also satisfactory.
>
> I've also added Michael Turquette's correct email to the CC this time,
> rather than his old Linaro address which was bouncing.
>
> drivers/cpufreq/arm_big_little.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8..c5d256c 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -149,6 +149,19 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> new_cluster, u32 rate)
> __func__, cpu, old_cluster, new_cluster, new_rate);
>
> ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
> + if (!ret) {
> + /*
> +* FIXME: clk_set_rate hasn't returned an error here however
> it
> +* may be that clk_change_rate failed due to hardware or
> +* firmware issues and wasn't able to report that due to the
> +* current design of the clk core layer. To work around this
> +* problem we will read back the clock rate and check it is
> +* correct. This needs to be removed once clk core is fixed.
> +*/
> + if (clk_get_rate(clk[new_cluster]) != new_rate * 1000)
> + ret = -EIO;
> + }
> +
> if (WARN_ON(ret)) {
> pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret,
> new_cluster);
> @@ -189,15 +202,6 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> new_cluster, u32 rate)
> mutex_unlock(_lock[old_cluster]);
> }
>
> - /*
> -* FIXME: clk_set_rate has to handle the case where clk_change_rate
> -* can fail due to hardware or firmware issues. Until the clk core
> -* layer is fixed, we can check here. In most of the cases we will
> -* be reading only the cached value anyway. This needs to be removed
> -* once clk core is fixed.
> -*/
> - if (bL_cpufreq_get_rate(cpu) != new_rate)
> - return -EIO;
> return 0;
> }
>
> --
> 2.1.4
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording
On 2015/10/26 20:24, Adrian Hunter wrote: On 26/10/15 13:41, Wang Nan wrote: evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837 (perf evlist: Add 'system_wide' option), which is used for mixing evsels that aren't system-wide with ones that are [1]. However, for global system wide recording (perf record -a ...), evsel->system_wide is set to false, which is confusion. This patch set evsel->system_wide to true if the target.system_wide is set, which makes evsel->system_wide a reliable way to describe whether itself is system_wide or not. [1] http://lkml.kernel.org/r/562df19b.2080...@intel.com Signed-off-by: Wang Nan Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Li Zefan Cc: pi3or...@163.com Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org --- tools/perf/util/evsel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 3ac4ee9c..36ecf0e 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) int track = evsel->tracking; bool per_cpu = opts->target.default_per_cpu && !opts->target.per_thread; + evsel->system_wide = opts->target.system_wide; Well that breaks the way evsel->system_wide is used i.e. it is a parameter to the evsel and here you just overwrote it. Currently the only user of evsel->system_wide is IPT: auxtrace_record__options -> intel_pt_recording_options and it only set it to true. So I think changing to this should make it safe: evsel->system_wide = (evsel->system_wide || opt->target.system_wide); Thought? If we want to add further config terms we can put it to apply_config_terms(), where we can implement something like: # perf record -e cycles/system-wide/ -e instruction/no-system-wide/ ... But currently I don't have such requirement. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: bcm6328: Handle default-state of LEDs correctly
On Mon, October 26, 2015 08:45, Jacek Anaszewski wrote: > Hi Simon, > > Thanks for the patch. There are conflicts when applying > it to the LED tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > > Please use it as a code base for your LED development. This has already been fixed in the devel branch by d19e6b6a0062c86a75365f0715fd079245f6aab9, although I think bcm6328_led() should adjust its use of the spinlock to only cover reading the register and call bcm6328_led_set() instead of copying the code from it. -- Simon Arlott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/15] scsi: ufs: add missing memory barriers
> 2015-10-25 23:40 GMT+09:00 :
>>> 2015-09-02 19:13 GMT+09:00 Yaniv Gardi :
Performing several writes to UFS host controller registers has
no gurrantee of ordering, so we must make sure register writes
to setup request list base address etc. are performed before the
run/stop register is enabled.
In addition, when setting up a task request, we must make sure
the updating of descriptors takes places before ringing the
doorbell, similarly to setting up a transfer request.
Signed-off-by: Gilad Broner
Signed-off-by: Yaniv Gardi
---
drivers/scsi/ufs/ufshcd.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index fc2a52d..298511a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -401,11 +401,9 @@ static inline int ufshcd_get_lists_status(u32
reg)
* 1 UTRLRDY
* 2 UTMRLRDY
* 3 UCRDY
-* 4 HEI
-* 5 DEI
-* 6-7 reserved
+* 4-7 reserved
*/
- return (((reg) & (0xFF)) >> 1) ^ (0x07);
+ return ((reg & 0xFF) >> 1) ^ 0x07;
}
/**
@@ -2726,7 +2724,7 @@ out:
* To bring UFS host controller to operational state,
* 1. Enable required interrupts
* 2. Configure interrupt aggregation
- * 3. Program UTRL and UTMRL base addres
+ * 3. Program UTRL and UTMRL base address
* 4. Configure run-stop-registers
*
* Returns 0 on success, non-zero value on failure
@@ -2756,8 +2754,13 @@ static int ufshcd_make_hba_operational(struct
ufs_hba *hba)
REG_UTP_TASK_REQ_LIST_BASE_H);
/*
+* Make sure base address and interrupt setup are updated
before
+* enabling the run/stop registers below.
+*/
+ wmb();
+
+ /*
* UCRDY, UTMRLDY and UTRLRDY bits must be 1
-* DEI, HEI bits must be 0
*/
reg = ufshcd_readl(hba, REG_CONTROLLER_STATUS);
if (!(ufshcd_get_lists_status(reg))) {
@@ -3920,7 +3923,13 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba
*hba, int lun_id, int task_id,
/* send command to the controller */
__set_bit(free_slot, >outstanding_tasks);
+
+ /* Make sure descriptors are ready before ringing the task
doorbell */
+ wmb();
+
ufshcd_writel(hba, 1 << free_slot,
REG_UTP_TASK_REQ_DOOR_BELL);
+ /* Make sure that doorbell is committed immediately */
+ wmb();
>>>
>>> Is this wmb() after ringing tm doorbell is needed?
>>
>> Well, Mita, in the case of DB register (Request DB and TASK DB), every
>> write operation to the DB should be barrier, as if not, out of order
>> writing to this register might cause inconsistency in its value, and
>> thus,
>> un-handled requests/tasks.
>
> I couldn't fully understand why out of order writing to TASK DB
> register causes inconsistency.
> In the TASK request completion (ufshcd_tmc_handler), TASK DB register
> is read before handling finished requests, so it ensures that all
> write operations for TASK DB have been performed.
>
thanks, Mita
your explanation makes sense.
It will be fixed in v4.
>>>
spin_unlock_irqrestore(host->host_lock, flags);
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper
On Sun, Oct 25, 2015 at 09:23:36AM -0700, Alexei Starovoitov wrote: > bpf_perf_event_read() muxes of -EINVAL into return value, but it's non > ambiguous to the program whether it got an error or real counter value. How can that be, the (u64)-EINVAL value is a valid counter value.. unlikely maybe, but still quite possible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] wait.[ch]: Introduce the simple waitqueue (swait) implementation
On Mon, Oct 26, 2015 at 08:04:26PM +0800, Boqun Feng wrote:
> Hi Daniel,
>
> On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
> > +
> > +/*
> > + * The thing about the wake_up_state() return value; I think we can ignore
> > it.
> > + *
> > + * If for some reason it would return 0, that means the previously waiting
> > + * task is already running, so it will observe condition true (or has
> > already).
> > + */
> > +void swake_up_locked(struct swait_queue_head *q)
> > +{
> > + struct swait_queue *curr;
> > +
> > + list_for_each_entry(curr, >task_list, task_list) {
> > + wake_up_process(curr->task);
> > + list_del_init(>task_list);
> > + break;
>
> Just be curious, what's this break for? Or what's this loop(?) for?
Lazy way of writing: if (!empty) { curr = first-entry;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording
On 26/10/15 13:41, Wang Nan wrote: > evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837 > (perf evlist: Add 'system_wide' option), which is used for mixing evsels > that aren't system-wide with ones that are [1]. However, for global > system wide recording (perf record -a ...), evsel->system_wide is set > to false, which is confusion. > > This patch set evsel->system_wide to true if the target.system_wide is > set, which makes evsel->system_wide a reliable way to describe whether > itself is system_wide or not. > > [1] http://lkml.kernel.org/r/562df19b.2080...@intel.com > > Signed-off-by: Wang Nan > Cc: Adrian Hunter > Cc: Arnaldo Carvalho de Melo > Cc: Alexei Starovoitov > Cc: Peter Zijlstra > Cc: Li Zefan > Cc: pi3or...@163.com > Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org > --- > tools/perf/util/evsel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c > index 3ac4ee9c..36ecf0e 100644 > --- a/tools/perf/util/evsel.c > +++ b/tools/perf/util/evsel.c > @@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct > record_opts *opts) > int track = evsel->tracking; > bool per_cpu = opts->target.default_per_cpu && !opts->target.per_thread; > > + evsel->system_wide = opts->target.system_wide; Well that breaks the way evsel->system_wide is used i.e. it is a parameter to the evsel and here you just overwrote it. > attr->sample_id_all = perf_missing_features.sample_id_all ? 0 : 1; > attr->inherit = !opts->no_inherit; > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/15] scsi: ufs: add missing memory barriers
2015-10-25 23:40 GMT+09:00 :
>> 2015-09-02 19:13 GMT+09:00 Yaniv Gardi :
>>> Performing several writes to UFS host controller registers has
>>> no gurrantee of ordering, so we must make sure register writes
>>> to setup request list base address etc. are performed before the
>>> run/stop register is enabled.
>>> In addition, when setting up a task request, we must make sure
>>> the updating of descriptors takes places before ringing the
>>> doorbell, similarly to setting up a transfer request.
>>>
>>> Signed-off-by: Gilad Broner
>>> Signed-off-by: Yaniv Gardi
>>>
>>> ---
>>> drivers/scsi/ufs/ufshcd.c | 21 +++--
>>> 1 file changed, 15 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index fc2a52d..298511a 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -401,11 +401,9 @@ static inline int ufshcd_get_lists_status(u32 reg)
>>> * 1 UTRLRDY
>>> * 2 UTMRLRDY
>>> * 3 UCRDY
>>> -* 4 HEI
>>> -* 5 DEI
>>> -* 6-7 reserved
>>> +* 4-7 reserved
>>> */
>>> - return (((reg) & (0xFF)) >> 1) ^ (0x07);
>>> + return ((reg & 0xFF) >> 1) ^ 0x07;
>>> }
>>>
>>> /**
>>> @@ -2726,7 +2724,7 @@ out:
>>> * To bring UFS host controller to operational state,
>>> * 1. Enable required interrupts
>>> * 2. Configure interrupt aggregation
>>> - * 3. Program UTRL and UTMRL base addres
>>> + * 3. Program UTRL and UTMRL base address
>>> * 4. Configure run-stop-registers
>>> *
>>> * Returns 0 on success, non-zero value on failure
>>> @@ -2756,8 +2754,13 @@ static int ufshcd_make_hba_operational(struct
>>> ufs_hba *hba)
>>> REG_UTP_TASK_REQ_LIST_BASE_H);
>>>
>>> /*
>>> +* Make sure base address and interrupt setup are updated before
>>> +* enabling the run/stop registers below.
>>> +*/
>>> + wmb();
>>> +
>>> + /*
>>> * UCRDY, UTMRLDY and UTRLRDY bits must be 1
>>> -* DEI, HEI bits must be 0
>>> */
>>> reg = ufshcd_readl(hba, REG_CONTROLLER_STATUS);
>>> if (!(ufshcd_get_lists_status(reg))) {
>>> @@ -3920,7 +3923,13 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba
>>> *hba, int lun_id, int task_id,
>>>
>>> /* send command to the controller */
>>> __set_bit(free_slot, >outstanding_tasks);
>>> +
>>> + /* Make sure descriptors are ready before ringing the task
>>> doorbell */
>>> + wmb();
>>> +
>>> ufshcd_writel(hba, 1 << free_slot, REG_UTP_TASK_REQ_DOOR_BELL);
>>> + /* Make sure that doorbell is committed immediately */
>>> + wmb();
>>
>> Is this wmb() after ringing tm doorbell is needed?
>
> Well, Mita, in the case of DB register (Request DB and TASK DB), every
> write operation to the DB should be barrier, as if not, out of order
> writing to this register might cause inconsistency in its value, and thus,
> un-handled requests/tasks.
I couldn't fully understand why out of order writing to TASK DB
register causes inconsistency.
In the TASK request completion (ufshcd_tmc_handler), TASK DB register
is read before handling finished requests, so it ensures that all
write operations for TASK DB have been performed.
>>
>>>
>>> spin_unlock_irqrestore(host->host_lock, flags);
>>>
>>> --
>>> 1.8.5.2
>>>
>>> --
>>> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
>>> member of Code Aurora Forum, hosted by The Linux Foundation
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced
On 10/25/2015 03:54 PM, Oleg Nesterov wrote: > On 10/22, Denys Vlasenko wrote: >> >> On Wed, Oct 21, 2015 at 11:47 PM, Oleg Nesterov wrote: >>> On 10/21, Denys Vlasenko wrote: On 10/21/2015 09:59 PM, Denys Vlasenko wrote: > On 10/21/2015 12:31 AM, Andrew Morton wrote: >> Well, to fix this a distro needs to roll out a new kernel. Or a new >> init(8). Is there any reason to believe that distributing/deploying a >> new kernel is significantly easier for everyone? Because fixing init >> sounds like a much preferable solution to this problem. > > People will continue to write new init(8) implementations, > and they will miss this obscure case. > > Before this bug was found, it was considered possible to use > a shell script as init process. What now, every shell needs to add > __WALL to its waitpids? >>> >>> Why not? I think it can safely use __WALL too. >> >> Because having any userspace program which can happen to be init, >> which includes all shells out there in the wild >> (bash, dash, ash, ksh, zsh, msh, hush,...) >> learn about __WALL is wrong: apart from this wart, they do not have >> to use any Linux-specific code. It can all be perfectly legitimate POSIX. > > Yes, this is true. I meant that they could safely use __WALL to, but I > understand that this change can be painful. > >>> Sure. But people do the things which were never intended to be >>> used all the time. We simply can not know if this "feature" >>> already has a creative user or not. >> >> It won't be unfixable: they will just have to switch from PTRACE_TRACEME >> to PTRACE_ATTACH. >> >> As of now we do not know any people craz^W creative enough >> to create a cross between init and strace. If such specimens would >> materialize, don't they deserve to have to make that change? > > This also applies to people who use bash/whatever as /sbin/init and allow > the untrusted users to run the exploits ;) I do not know who is more crazy. > > In any case, the real question is whether we should change the kernel to > fix the problem, or ask the distros to fix their init's. In the former > case 1/2 looks simpler/safer to me than the change in ptrace_traceme(), > and you seem to agree that 1/2 is not that bad. A risk here seems to be that waitpid will start returning unexpected (thread) PIDs to parent processes, and it's not unreasonable to assume that e.g., a program asserts that waitpid either returns error or a known (process) PID. That's not an init-only issue, but something that might affect any process that runs a child that happens to decide to call PTRACE_TRACEME. The ptrace man page says: "A process can initiate a trace by calling fork(2) and having the resulting child do a PTRACE_TRACEME, followed (typically) by an execve(2)." Given that, can we instead make the kernel error out on PTRACE_TRACEME issued from a non-leader thread? Then between PTRACE_TRACEME and the parent's waitpid, __WALL or !__WALL should make no difference. (Also, in the original test case, if the child gets/raises a signal or execs before exiting, the bash/init/whatever process won't be issuing PTRACE_CONT, and the child will thus end up stuck (though should be SIGKILLable, I believe). All this because PTRACE_TRACEME is broken by design by making it be the child's choice whether to be traced...) Thanks, Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade
Hi Olivier, On Mon, Oct 26, 2015 at 12:00:50PM +0100, Olivier Scherler wrote: > > On 24 oct. 2015, at 22:11, Jiri Kosina wrote: > > On Sat, 24 Oct 2015, Michele Baldessari wrote: > > > >> The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order > >> to have the two distinct joysticks working. > >> > >> Before the change: > >> $ jstest /dev/input/js0 > >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) > >> ... > >> $ jstest /dev/input/js1 > >> jstest: No such file or directory > >> > >> After the change: > >> $ jstest /dev/input/js0 > >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) > >> ... > >> $ jstest /dev/input/js1 > >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) > >> ... > >> > >> Signed-off-by: Michele Baldessari > > > > Adding Oliver to CC. > > > > Oliver, how come that you didn't need this while working on the inigial > > Xin-Mo Dual Arcade support? > > Because I didn’t mind whether the controller announced itself as two > joysticks with two axes each, or one joystick with four axes. In the > software I use it for (a MAME for the Raspberry Pi), I can map a > single device’s buttons and axes to several players. > > I’m a bit surprised with this, though: > > > $ jstest /dev/input/js0 > > Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) > > because in my case I had four axes, at least using evtest (I don’t > remember if I tried jstest as well). Ah that is the crux of the matter. It never showed up with four axes in my tests (raspbian, kernel 4.1.7), hence I submitted the patch given that the two joysticks were indistinguishable without it on my setup. Which kernel version did you run your tests on? (Maybe some other change skewed things around?) > What bothered me at the time, though, is that even though the custom > driver was made as a kernel module, an entry had to be added in the > hid_have_special_driver table in hid-core.c for the kernel to use it, > which means, if I understand properly, that the kernel still needs > recompiling. Is that normal? I had that line in my kernel prior to my patch: https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/hid/hid-core.c#L2008 Kind regards, Michele -- Michele Baldessari C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] wait.[ch]: Introduce the simple waitqueue (swait) implementation
Hi Daniel,
On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
> +
> +/*
> + * The thing about the wake_up_state() return value; I think we can ignore
> it.
> + *
> + * If for some reason it would return 0, that means the previously waiting
> + * task is already running, so it will observe condition true (or has
> already).
> + */
> +void swake_up_locked(struct swait_queue_head *q)
> +{
> + struct swait_queue *curr;
> +
> + list_for_each_entry(curr, >task_list, task_list) {
> + wake_up_process(curr->task);
> + list_del_init(>task_list);
> + break;
Just be curious, what's this break for? Or what's this loop(?) for?
> + }
> +}
> +EXPORT_SYMBOL(swake_up_locked);
> +
Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller
Marc Gonzalez writes:
> On 23/10/2015 15:41, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> On 22/10/2015 16:02, Mans Rullgard wrote:
>>>
This adds a binding for the Aurora VLSI NB8800 Ethernet controller
using the "aurora,nb8800" compatible string. When used in Sigma
Designs chips a few additional control registers are available.
This variant is indicated by the "sigma,smp8640-ethernet" compatible
string.
>>>
>>> I've been meaning to ask a noob question to the devicetree group
>>> about how names for compatible strings are chosen.
>>>
>>> Sigma Designs has two active SoC families, Tango3 (which consists of
>>> about a dozen MIPS-based SoCs, typically named SMP86xx) and Tango4
>>> (a few ARM-based SoCs, typically named SMP87xx). I should note that
>>> there is no SMP8640 SoC AFAIK, rather SMP864x is a Tango3 sub-family
>>> (I could locate 42,43,44,45,46).
>
> Just to make things a bit more confusing, I learned that Sigma made
> one MIPS-based Tango4 SoC...
That explains the presence of tango4 mentions in a Sigma MIPS kernel
tree I found. Do you know what it was called?
>>> AFAIK, all our SoCs are using the same Aurora NB8800 Ethernet MAC,
>>> along with the extra features. I find it odd to use a specific SoC
>>> model to refer to this device, instead of a more generic name.
>>> (It's weird having to mention smp8640 in the tango4 DT.)
>>
>> I picked 8640 since all 8640 or higher chips are compatible (863x chips
>> (tango2) are not). Some of the later versions have additional extra
>> features, but they all work with the basic driver.
>
> According to my branch's FAEs, the first Tango3 was SMP8644.
I don't know which was first out the door, but judging by marketing
materials, 8642, 8644, and 8646 were available around the same time.
All of these also have an odd-numbered variant (8643 etc) without
Macrovision features.
> I showed the DT to a colleague, and his reaction was: "Don't use
> smp8640, it will confuse other engineers, Sigma didn't make a 8640
> SoC."
>
> http://www.qobuz.com/info/IMG/pdf/SMP8643.pdf
>
> Would you be willing to change the compatible string to
> "sigma,smp8644-foo" or "sigma,smp864x-foo" ?
>
> If it's not possible, I suppose I can add comments in the DT, to clear
> the potential confusion for Sigma engineers.
My intent was certainly not to confuse. Sigma product brochures talk
about the "SMP8640 series," so I figured that would be a good way of
referring to them as a group. See e.g. this PDF, now gone from the
main sigmadesigns.com site:
http://wayback.archive.org/web/20150101024010/http://www.sigmadesigns.com/uploads/documents/selection_guide.pdf
>> There also appear to be some differences (bug fixes?) between 8643 and
>> 8759 (the ones I have) not documented anywhere.
>
> Suppose you identify these differences, and you make the appropriate
> changes to the driver. What compatible string would you use to refer
> to the new features? I used "sigma,tango4-ethernet" but IIUC it must
> be more specific, such as the first Tango4 chip to implement these
> changes (I guess that would be the SMP8734).
There are differences even within the tango3 family. The SMP867x chips
have features not present on the earlier ones. The tango3 and tango4
codenames are too unspecific to be of use here. It's better to use
exact chip designations.
> So I should write something like this in my DT?
>
> eth0: ethernet@26000 {
> compatible = "sigma,smp8734-ethernet", "sigma,smp8640-ethernet",
> "aurora,nb8800";
>
> Hmmm, you mention this below, but you used "sigma,smp8759-ethernet".
> What about earlier chips?
OK, how about this scheme then:
- Device trees list the exact chip, the chip family, the oldest
compatible family, and finally the basic "aurora,nb8800". For the
SMP8759 that would look like this:
"sigma,smp8759-ethernet", "sigma,smp87xx-ethernet", "sigma,smp864x-ethernet",
"aurora,nb8800"
- Drivers match against whatever they need to in order to safely
identify features. If the driver finds a match for e.g.
"sigma,smp864x-ethernet" it is allowed to make use of any features
present in all chips of that family (even if the actual chip is a
later one, the DT says it's compatible). If a specific chip is found
to need a bug workaround or whatever, the driver can enable that by
matching on the exact string.
This approach means that if the driver is updated to support newer
features, no change is needed to the devicetree, and if a new chip shows
up, say a hypothetical smp8764, a driver with support for the smp87xx
family will automatically recognise it without changes. Unfortunately
the 863x (tango2) chips are not compatible with 864x and later, so it's
not safe to use a catch-all smp86xx.
Speaking more generally about device trees, for chip families like this,
it can be a good solution to have all the common parts in, say,
smp87xx.dtsi which is included by chip-specific files, i.e. smp8734.dtsi
and smp8759.dtsi, with
[PATCH] nfc: nci: non-static functions can not be inline
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 8
net/nfc/nci/core.c | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 530df66..1e3db2b 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -351,13 +351,13 @@ static inline int nci_set_vendor_cmds(struct nci_dev
*ndev,
void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb);
void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb);
-inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
-inline int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
-inline int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
-inline int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index ecf420d..0767cc1 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -1314,29 +1314,29 @@ static int nci_op_ntf_packet(struct nci_dev *ndev,
__u16 ntf_opcode,
return op->ntf(ndev, skb);
}
-inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
- struct sk_buff *skb)
+int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+ struct sk_buff *skb)
{
return nci_op_rsp_packet(ndev, opcode, skb, ndev->ops->prop_ops,
ndev->ops->n_prop_ops);
}
-inline int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
- struct sk_buff *skb)
+int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+ struct sk_buff *skb)
{
return nci_op_ntf_packet(ndev, opcode, skb, ndev->ops->prop_ops,
ndev->ops->n_prop_ops);
}
-inline int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
- struct sk_buff *skb)
+int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
+ struct sk_buff *skb)
{
return nci_op_rsp_packet(ndev, opcode, skb, ndev->ops->core_ops,
ndev->ops->n_core_ops);
}
-inline int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
- struct sk_buff *skb)
+int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
+ struct sk_buff *skb)
{
return nci_op_ntf_packet(ndev, opcode, skb, ndev->ops->core_ops,
ndev->ops->n_core_ops);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording
evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837 (perf evlist: Add 'system_wide' option), which is used for mixing evsels that aren't system-wide with ones that are [1]. However, for global system wide recording (perf record -a ...), evsel->system_wide is set to false, which is confusion. This patch set evsel->system_wide to true if the target.system_wide is set, which makes evsel->system_wide a reliable way to describe whether itself is system_wide or not. [1] http://lkml.kernel.org/r/562df19b.2080...@intel.com Signed-off-by: Wang Nan Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Li Zefan Cc: pi3or...@163.com Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org --- tools/perf/util/evsel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 3ac4ee9c..36ecf0e 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) int track = evsel->tracking; bool per_cpu = opts->target.default_per_cpu && !opts->target.per_thread; + evsel->system_wide = opts->target.system_wide; attr->sample_id_all = perf_missing_features.sample_id_all ? 0 : 1; attr->inherit = !opts->no_inherit; -- 1.8.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] perf tools: Don't set inherit bit for system wide evsel
On 2015/10/26 17:25, Adrian Hunter wrote: On 26/10/15 11:08, Wangnan (F) wrote: evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837a48397144887 (perf evlist: Add 'system_wide' option), but Adrian only introduced a new field into perf, doesn't really make it active. Until now the only user of it is arch/x86/util/intel-pt.c, but I'm not very sure the reason for IPT to use that field. If I understand correctly, it should be okay for a normal system wide evsel to have this var set. I'll try another RFC for it. evsel->system_wide is for mixing evsels that aren't system-wide with ones that are. It might work to set it for all system-wide evsels but you will have to check the code and test it, because that would be using it in a new way that has never been tested. I have check all occurance of system_wide I can found and found only one behavior change which I believe should be okay. Please have a look at [1]. Thank you. [1] http://lkml.kernel.org/g/1445859720-146146-1-git-send-email-wangn...@huawei.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] component: demote bind messages to debug level
The component bind messages are mostly redundant as most drivers print
a more specific message themselves when binding has succeeded. As they
don't add much value, but can get noisy with a lot of components in the
system demote them to debug level.
Signed-off-by: Lucas Stach
---
drivers/base/component.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index f748430bb654..867ace2404f1 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -417,8 +417,8 @@ static int component_bind(struct component *component,
struct master *master,
devres_close_group(component->dev, NULL);
devres_remove_group(master->dev, NULL);
- dev_info(master->dev, "bound %s (ops %ps)\n",
-dev_name(component->dev), component->ops);
+ dev_dbg(master->dev, "bound %s (ops %ps)\n",
+ dev_name(component->dev), component->ops);
} else {
devres_release_group(component->dev, NULL);
devres_release_group(master->dev, NULL);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu
From: Joseph Myers Date: Thu, 2 Jul 2015 15:54:34 + > From: Joseph Myers > > This patch moves sparc from math-emu-old to math-emu, updating it for > the API changes. > > The following cleanup (that goes beyond mechanical conversion to new > APIs) is included in this patch because of its close connection to the > API changes: > > * On SPARC, comparisons now use raw unpacking (this should not in fact > change how the emulation behaves, just make it more efficient). > > Signed-off-by: Joseph Myers Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] x86: sigcontext fixes, again
26.10.2015 04:25, Andy Lutomirski пишет: > This is take 2 at fixing x86 64-bit signals wrt SS. After a lot of > thought, this is not controlled by any flags -- I would much prefer > to avoid opt-in behavior. Instead, it just tries hard to avoid > triggering the cases that break DOSEMU. > > Stas, this now seems to pass the test you sent me. It works with > stock dosemu2 (I haven't tested classic dosemu because I can't get it > to work regardless). I'll test it myself then. But this will have to wait till a week-end I am afraid. In a mean time you can test vm86() - last time I tried, I got oops and hard lockup. > It also works with a patched dosemu2 that bypasses > the userspace trampoline: > > https://github.com/amluto/dosemu2/commit/571b4d08dc885b7a133e444a2ad23e0d21366206 > > With this applied, all of the x86 selftests pass on x86_64. That > wasn't the case before -- ldt_gdt_64 was broken. > > This is a bit risky, and another option would be to do nothing at > all. Then we'd disable the problematic self-tests (sigh), and No, another option is a new SA_ flag. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] regulator: arizona: Add regulator specific device tree binding document
On Thu, Oct 22, 2015 at 01:44:49PM +0100, Mark Brown wrote: > On Thu, Oct 15, 2015 at 02:47:07PM +0100, Charles Keepax wrote: > > > +This document lists regulator specific bindings, see the primary binding > > +document: > > + ../mfd/arizona.txt > > + > > +Required properties: > > + > > + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the > > device, > > +as covered in regulator.txt > > + > > + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies > > (wm5102, > > +wm5110, wm8280, wm8998, wm1814) > > + > > + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, > > +wm5110, wm8280, wm8998, wm1814) > > + > > + - SPKVDD-supply : Speaker driver power supply (wm8997) > > + > > I'd expect these to be on the MFD since they're (with the exception of > AVDD which supplies the regulators IIRC) not part of the regulator > component of the device and are core for bringing it online. Yeah, fair enough I will move those back into the MFD part. > > > +Optional properties: > > + - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA > > + > > +Optional subnodes: > > + - ldo1 : Initial data for the LDO1 regulator, as covered in > > +Documentation/devicetree/bindings/regulator/regulator.txt > > + - micvdd : Initial data for the MICVDD regulator, as covered in > > +Documentation/devicetree/bindings/regulator/regulator.txt > > These are the properties for the regulator itself. > > > +++ b/MAINTAINERS > > @@ -11381,6 +11381,7 @@ W: > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices > > S: Supported > > F: Documentation/hwmon/wm83?? > > F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt > > +F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt > > F: arch/arm/mach-s3c64xx/mach-crag6410* > > F: drivers/clk/clk-wm83*.c > > F: drivers/extcon/extcon-arizona.c > > I'd suggest moving this to a separate patch which adds all the new files > together to make it easier to merge things. Yeah no problem with making that a seperate patch. Thanks, Charles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Newbie's question: memory allocation when reclaiming memory
May I ask a newbie question? Say, there is some amount of memory pages which can be reclaimed if they are flushed to storage. And lower layer might issue memory allocation request in a way which won't cause reclaim deadlock (e.g. using GFP_NOFS or GFP_NOIO) when flushing to storage, isn't it? What I'm worrying is a dependency that __GFP_FS allocation requests think that there are reclaimable pages and therefore there is no need to call out_of_memory(); and GFP_NOFS allocation requests which the __GFP_FS allocation requests depend on (in order to flush to storage) is waiting for GFP_NOIO allocation requests; and the GFP_NOIO allocation requests which the GFP_NOFS allocation requests depend on (in order to flush to storage) are waiting for memory pages to be reclaimed without calling out_of_memory(); because gfp_to_alloc_flags() does not favor GFP_NOIO over GFP_NOFS nor GFP_NOFS over __GFP_FS which will throttle all allocations at the same watermark level. How do we guarantee that GFP_NOFS/GFP_NOIO allocations make forward progress? What mechanism guarantees that memory pages which __GFP_FS allocation requests are waiting for are reclaimed? I assume that there is some mechanism; otherwise we can hit silent livelock, can't we? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 2/2] perf tools: Don't set inherit bit for system wide evsel
Inherit bit is useless for a system wide evsel [1]. Further kernel improvements are giving more constrain [2] on inherit events. This patch set inherit bit to 0 for system wide evsels to avoid potential constrains. [1] http://lkml.kernel.org/r/20151022124142.gq17...@twins.programming.kicks-ass.net [2] http://lkml.kernel.org/r/1445559014-4667-1-git-send-email-...@kernel.org Signed-off-by: Wang Nan Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Li Zefan Cc: pi3or...@163.com Link: http://lkml.kernel.org/n/ebpf-0xsuv8wc1uwgj7qfylfol...@git.kernel.org --- tools/perf/util/evsel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 36ecf0e..2a5f0f8 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -736,7 +736,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) evsel->system_wide = opts->target.system_wide; attr->sample_id_all = perf_missing_features.sample_id_all ? 0 : 1; - attr->inherit = !opts->no_inherit; + attr->inherit = !opts->no_inherit && !evsel->system_wide; perf_evsel__set_sample_bit(evsel, IP); perf_evsel__set_sample_bit(evsel, TID); -- 1.8.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 0/2] perf tools: Don't set inherit bit for system wide evsel
Previous version can be found from [1].
To make bpf_perf_event_output() and bpf_perf_event_read() easier to be
used, these two patches set inherit to 0 for system wide evsels.
After applying them, users are possible to pass system wide events to
BPF programs in following command, and don't need to consider the
setting of inherit:
# perf record -a -e evt=cycles -e ./test__map.c/maps.pmu_map.event=evt/ ...
Patch 1/2 set evsel->system_wide for system wide target. I have checked
in current evlist.c and evsel.c. The only behavior change I found is in
evlist.c:
/*
* The system_wide flag causes a selected event to be opened
* always without a pid. Consequently it will never get a
* POLLHUP, but it is used for tracking in combination with
* other events, so it should not need to be polled anyway.
* Therefore don't add it for polling.
*/
if (!evsel->system_wide &&
__perf_evlist__add_pollfd(evlist, fd, idx) < 0) {
perf_evlist__mmap_put(evlist, idx);
return -1;
}
With patch 1/2, __perf_evlist__add_pollfd() won't be called. From the
comment I pasted this modification looks harmless.
[1]
http://lkml.kernel.org/r/1445597029-12-1-git-send-email-wangn...@huawei.com
Wang Nan (2):
perf tools: Set evsel->system_wide field for global system wide
recording
perf tools: Don't set inherit bit for system wide evsel
tools/perf/util/evsel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen > wrote: > > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> Hello, > >> > >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> wrote: > >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> > properties to workaround this. > >> > > >> > This also set cpu enable-method to enable SMP. > >> > > >> > Signed-off-by: Yingjoe Chen > >> > >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> the arm-soc tree[1], and the boot failures were bisected down to this > >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> dts: mt8135: enable basic SMP bringup for mt8135) > >> > >> Maybe this new SMP support requires updating the firmware on the board > >> as well? If so, the changelog should've been a bit more explicit > >> about firmware dependencies. > > > > Kevin, > > > > Thanks for testing. > > > > No, it doesn't need new firmware. Will test to see what's going wrong. > > Thanks for following up. I'll be glad to test any patches if you have > anything you'd like me to test. You need "clockevents/drivers/mtk: Fix spurious interrupt leading to crash" (https://lkml.org/lkml/2015/8/24/803) Daniel Lezcano already applied this patch in his tree for 4.4. (https://git.linaro.org/people/daniel.lezcano/linux.git) Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH_V3 1/4] dt-bindings: MIPS: Document xilfpga bindings and boot style
Xilfpga boots only with device-tree. Document the required properties
and the unique boot style
Signed-off-by: Zubair Lutfullah Kakakhel
---
V2->V3
minor nitpicks. mips->MIPS. typo. reorder compatible strings in priority
V1->V2
Reformatted to 80 char column
Correct clock phandle description
Added digilent,nexys4ddr to get more specific about platform
Added compatible string in example.
---
.../devicetree/bindings/mips/img/xilfpga.txt | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/img/xilfpga.txt
diff --git a/Documentation/devicetree/bindings/mips/img/xilfpga.txt
b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
new file mode 100644
index 000..57e7ee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
@@ -0,0 +1,83 @@
+Imagination University Program MIPSfpga
+===
+
+Under the Imagination University Program, a microAptiv UP core has been
+released for academic usage.
+
+As we are dealing with a MIPS core instantiated on an FPGA, specifications
+are fluid and can be varied in RTL.
+
+This binding document is provided as baseline guidance for the example
+project provided by IMG.
+
+The example project runs on the Nexys4DDR board by Digilent powered by
+the ARTIX-7 FPGA by Xilinx.
+
+Relevant details about the example project and the Nexys4DDR board:
+
+- microAptiv UP core m14Kc
+- 50MHz clock speed
+- 128Mbyte DDR RAM at 0x_
+- 8Kbyte RAM at 0x1000_
+- axi_intc at 0x1020_
+- axi_uart16550at 0x1040_
+- axi_gpio at 0x1060_
+- axi_i2c at 0x10A0_
+- custom_gpio at 0x10C0_
+- axi_ethernetlite at 0x10E0_
+- 8Kbyte BootRAM at 0x1FC0_
+
+Required properties:
+
+ - compatible: Must include "digilent,nexys4ddr","img,xilfpga".
+
+CPU nodes:
+--
+A "cpus" node is required. Required properties:
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+A CPU sub-node is also required for at least CPU 0. Required properties:
+ - device_type: Must be "cpu".
+ - compatible: Must be "mips,m14Kc".
+ - reg: Must be <0>.
+ - clocks: phandle to ext clock for fixed-clock received by MIPS core.
+
+Example:
+
+ compatible = "img,xilfpga","digilent,nexys4ddr";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "mips,m14Kc";
+ reg = <0>;
+ clocks = <>;
+ };
+ };
+
+ ext: ext {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+Boot protocol:
+--
+
+The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_.
+This is for easy reprogrammibility via JTAG.
+
+The BootRAM initializes the cache and the axi_uart peripheral.
+
+DDR initialization is already handled by a HW IP block.
+
+When the example project bitstream is loaded, the cpu_reset button
+needs to be pressed.
+
+The bootram initializes the cache and axi_uart.
+Then outputs MIPSFPGA\n\r on the serial port on the Nexys4DDR board.
+
+At this point, the board is ready to load the Linux kernel
+vmlinux file via JTAG.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH_V3 2/4] MIPS: dt: xilfpga: Add xilfpga device tree files.
Add device tree files for the MIPSfpga platform.
See Documentation/devicetree/bindings/mips/img/xilfpga.txt
for details about MIPSfpga
Signed-off-by: Zubair Lutfullah Kakakhel
---
V2 -> V3
no change
V1 -> V2
Reformatted git log for 80 column
Added nexys4ddr compatible
Fixed some whitespace
Removed a redundant status okay
---
arch/mips/boot/dts/Makefile| 1 +
arch/mips/boot/dts/xilfpga/Makefile| 9 ++
arch/mips/boot/dts/xilfpga/microAptiv.dtsi | 21 ++
arch/mips/boot/dts/xilfpga/nexys4ddr.dts | 46 ++
4 files changed, 77 insertions(+)
create mode 100644 arch/mips/boot/dts/xilfpga/Makefile
create mode 100644 arch/mips/boot/dts/xilfpga/microAptiv.dtsi
create mode 100644 arch/mips/boot/dts/xilfpga/nexys4ddr.dts
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 778a340..0571ef7 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -6,6 +6,7 @@ dts-dirs+= mti
dts-dirs += netlogic
dts-dirs += qca
dts-dirs += ralink
+dts-dirs += xilfpga
obj-y := $(addsuffix /, $(dts-dirs))
diff --git a/arch/mips/boot/dts/xilfpga/Makefile
b/arch/mips/boot/dts/xilfpga/Makefile
new file mode 100644
index 000..913a752
--- /dev/null
+++ b/arch/mips/boot/dts/xilfpga/Makefile
@@ -0,0 +1,9 @@
+dtb-$(CONFIG_XILFPGA_NEXYS4DDR)+= nexys4ddr.dtb
+
+obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
+
+# Force kbuild to make empty built-in.o if necessary
+obj- += dummy.o
+
+always := $(dtb-y)
+clean-files:= *.dtb *.dtb.S
diff --git a/arch/mips/boot/dts/xilfpga/microAptiv.dtsi
b/arch/mips/boot/dts/xilfpga/microAptiv.dtsi
new file mode 100644
index 000..81d518e
--- /dev/null
+++ b/arch/mips/boot/dts/xilfpga/microAptiv.dtsi
@@ -0,0 +1,21 @@
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "img,xilfpga";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "mips,m14Kc";
+ clocks = <>;
+ reg = <0>;
+ };
+ };
+
+ ext: ext {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ };
+};
diff --git a/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
new file mode 100644
index 000..686ebd1
--- /dev/null
+++ b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
@@ -0,0 +1,46 @@
+/dts-v1/;
+
+#include "microAptiv.dtsi"
+
+/ {
+ compatible = "digilent,nexys4ddr";
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0800>;
+ };
+
+ cpuintc: interrupt-controller@0 {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ axi_gpio: gpio@1060 {
+ #gpio-cells = <1>;
+ compatible = "xlnx,xps-gpio-1.00.a";
+ gpio-controller;
+ reg = <0x1060 0x1>;
+ xlnx,all-inputs = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,gpio-width = <0x16>;
+ xlnx,interrupt-present = <0x0>;
+ xlnx,is-dual = <0x0>;
+ xlnx,tri-default = <0x>;
+ } ;
+
+ axi_uart16550: serial@1040 {
+ compatible = "ns16550a";
+ reg = <0x1040 0x1>;
+
+ reg-shift = <2>;
+ reg-offset = <0x1000>;
+
+ clocks = <>;
+ };
+};
+
+ {
+ clock-frequency = <5000>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH_V3 4/4] MIPS: Add xilfpga defconfig
Add defconfig for MIPSfpga Signed-off-by: Zubair Lutfullah Kakakhel --- V2 -> V3 no change V1 -> V2 Reduced redundant options that had crept in --- arch/mips/configs/xilfpga_defconfig | 40 + 1 file changed, 40 insertions(+) create mode 100644 arch/mips/configs/xilfpga_defconfig diff --git a/arch/mips/configs/xilfpga_defconfig b/arch/mips/configs/xilfpga_defconfig new file mode 100644 index 000..ed1dce3 --- /dev/null +++ b/arch/mips/configs/xilfpga_defconfig @@ -0,0 +1,40 @@ +CONFIG_MACH_XILFPGA=y +# CONFIG_COMPACTION is not set +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_EMBEDDED=y +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_COMPAT_BRK is not set +CONFIG_SLAB=y +# CONFIG_BLOCK is not set +# CONFIG_SUSPEND is not set +# CONFIG_UEVENT_HELPER is not set +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_STANDALONE is not set +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +# CONFIG_ALLOW_DEV_COREDUMP is not set +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +CONFIG_VT_HW_CONSOLE_BINDING=y +# CONFIG_UNIX98_PTYS is not set +# CONFIG_LEGACY_PTYS is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_XILINX=y +# CONFIG_HWMON is not set +# CONFIG_USB_SUPPORT is not set +# CONFIG_MIPS_PLATFORM_DEVICES is not set +# CONFIG_IOMMU_SUPPORT is not set +# CONFIG_PROC_PAGE_MONITOR is not set +# CONFIG_MISC_FILESYSTEMS is not set +CONFIG_PANIC_ON_OOPS=y +# CONFIG_SCHED_DEBUG is not set +# CONFIG_FTRACE is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE="console=ttyS0,115200" -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH_V3 0/4] MIPS: Add Xilfpga platform
Hi, This series is based on v4.3-rc7. Adds support for the Imagination University Program MIPSfpga platform. See the first dt-bindings patch for details about the platform. These patches allow the kernel to boot with UART and gpio support. Acks from DT (patch 1/4) welcome. Regards, ZubairLK V2 -> V3 Minor typos/nitpicks. Removed redundant header. Individual patches have changelogs. V1 -> V2 Nothing major functional. Mostly cleanup. Individual patches have changelogs. Removed the gpio patch from this series as Linus Walleij applied it. Zubair Lutfullah Kakakhel (4): dt-bindings: MIPS: Document xilfpga bindings and boot style MIPS: dt: xilfpga: Add xilfpga device tree files. MIPS: xilfpga: Add mipsfpga platform code MIPS: Add xilfpga defconfig .../devicetree/bindings/mips/img/xilfpga.txt | 83 ++ arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 23 ++ arch/mips/boot/dts/Makefile| 1 + arch/mips/boot/dts/xilfpga/Makefile| 9 +++ arch/mips/boot/dts/xilfpga/microAptiv.dtsi | 21 ++ arch/mips/boot/dts/xilfpga/nexys4ddr.dts | 46 arch/mips/configs/xilfpga_defconfig| 40 +++ arch/mips/include/asm/mach-xilfpga/irq.h | 18 + arch/mips/xilfpga/Kconfig | 9 +++ arch/mips/xilfpga/Makefile | 7 ++ arch/mips/xilfpga/Platform | 3 + arch/mips/xilfpga/init.c | 57 +++ arch/mips/xilfpga/intc.c | 25 +++ arch/mips/xilfpga/time.c | 41 +++ 15 files changed, 384 insertions(+) create mode 100644 Documentation/devicetree/bindings/mips/img/xilfpga.txt create mode 100644 arch/mips/boot/dts/xilfpga/Makefile create mode 100644 arch/mips/boot/dts/xilfpga/microAptiv.dtsi create mode 100644 arch/mips/boot/dts/xilfpga/nexys4ddr.dts create mode 100644 arch/mips/configs/xilfpga_defconfig create mode 100644 arch/mips/include/asm/mach-xilfpga/irq.h create mode 100644 arch/mips/xilfpga/Kconfig create mode 100644 arch/mips/xilfpga/Makefile create mode 100644 arch/mips/xilfpga/Platform create mode 100644 arch/mips/xilfpga/init.c create mode 100644 arch/mips/xilfpga/intc.c create mode 100644 arch/mips/xilfpga/time.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH_V3 3/4] MIPS: xilfpga: Add mipsfpga platform code
The xilfpga platform will be DT only. Add required platform code. DT files have already been added separately. Signed-off-by: Zubair Lutfullah Kakakhel --- V2 -> V3 removed redundant gpio.h minor typos V1 -> V2 Minor nitpicks. Nothing functional. Removed some redundant select 8250 serial. Removed a newline Added description of platform in Kconfig Reformated makefile --- arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig| 23 + arch/mips/include/asm/mach-xilfpga/irq.h | 18 ++ arch/mips/xilfpga/Kconfig| 9 + arch/mips/xilfpga/Makefile | 7 arch/mips/xilfpga/Platform | 3 ++ arch/mips/xilfpga/init.c | 57 arch/mips/xilfpga/intc.c | 25 ++ arch/mips/xilfpga/time.c | 41 +++ 9 files changed, 184 insertions(+) create mode 100644 arch/mips/include/asm/mach-xilfpga/irq.h create mode 100644 arch/mips/xilfpga/Kconfig create mode 100644 arch/mips/xilfpga/Makefile create mode 100644 arch/mips/xilfpga/Platform create mode 100644 arch/mips/xilfpga/init.c create mode 100644 arch/mips/xilfpga/intc.c create mode 100644 arch/mips/xilfpga/time.c diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms index a424e46..a96c81d 100644 --- a/arch/mips/Kbuild.platforms +++ b/arch/mips/Kbuild.platforms @@ -33,6 +33,7 @@ platforms += sibyte platforms += sni platforms += txx9 platforms += vr41xx +platforms += xilfpga # include the platform specific files include $(patsubst %, $(srctree)/arch/mips/%/Platform, $(platforms)) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index e3aa5b0..a9f632f 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -401,6 +401,28 @@ config MACH_PISTACHIO help This enables support for the IMG Pistachio SoC platform. +config MACH_XILFPGA + bool "MIPSfpga Xilinx based boards" + select ARCH_REQUIRE_GPIOLIB + select BOOT_ELF32 + select BOOT_RAW + select BUILTIN_DTB + select CEVT_R4K + select COMMON_CLK + select CSRC_R4K + select IRQ_MIPS_CPU + select LIBFDT + select MIPS_CPU_SCACHE + select SYS_HAS_EARLY_PRINTK + select SYS_HAS_CPU_MIPS32_R2 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_LITTLE_ENDIAN + select SYS_SUPPORTS_ZBOOT_UART16550 + select USE_OF + select USE_GENERIC_EARLY_PRINTK_8250 + help + This enables support for the IMG University Program MIPSfpga platform. + config MIPS_MALTA bool "MIPS Malta board" select ARCH_MAY_HAVE_PC_FDC @@ -964,6 +986,7 @@ source "arch/mips/loongson32/Kconfig" source "arch/mips/loongson64/Kconfig" source "arch/mips/netlogic/Kconfig" source "arch/mips/paravirt/Kconfig" +source "arch/mips/xilfpga/Kconfig" endmenu diff --git a/arch/mips/include/asm/mach-xilfpga/irq.h b/arch/mips/include/asm/mach-xilfpga/irq.h new file mode 100644 index 000..0132a5b9 --- /dev/null +++ b/arch/mips/include/asm/mach-xilfpga/irq.h @@ -0,0 +1,18 @@ +/* + * Copyright (C) 2015 Imagination Technologies + * Author: Zubair Lutfullah Kakakhel + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#ifndef __MIPS_ASM_MACH_XILFPGA_IRQ_H__ +#define __MIPS_ASM_MACH_XILFPGA_IRQ_H__ + +#define NR_IRQS 32 + +#include_next + +#endif /* __MIPS_ASM_MACH_XILFPGA_IRQ_H__ */ diff --git a/arch/mips/xilfpga/Kconfig b/arch/mips/xilfpga/Kconfig new file mode 100644 index 000..42a030a --- /dev/null +++ b/arch/mips/xilfpga/Kconfig @@ -0,0 +1,9 @@ +choice + prompt "Machine type" + depends on MACH_XILFPGA + default XILFPGA_NEXYS4DDR + +config XILFPGA_NEXYS4DDR + bool "Nexys4DDR by Digilent" + +endchoice diff --git a/arch/mips/xilfpga/Makefile b/arch/mips/xilfpga/Makefile new file mode 100644 index 000..a4deec6 --- /dev/null +++ b/arch/mips/xilfpga/Makefile @@ -0,0 +1,7 @@ +# +# Makefile for the Xilfpga +# + +obj-y += init.o +obj-y += intc.o +obj-y += time.o diff --git a/arch/mips/xilfpga/Platform b/arch/mips/xilfpga/Platform new file mode 100644 index 000..ed375af --- /dev/null +++ b/arch/mips/xilfpga/Platform @@ -0,0 +1,3 @@ +platform-$(CONFIG_MACH_XILFPGA) += xilfpga/ +cflags-$(CONFIG_MACH_XILFPGA) += -I$(srctree)/arch/mips/include/asm/mach-xilfpga +load-$(CONFIG_MACH_XILFPGA) += 0x8010 diff --git a/arch/mips/xilfpga/init.c b/arch/mips/xilfpga/init.c new file mode 100644 index 000..ce2aee2 --- /dev/null +++ b/arch/mips/xilfpga/init.c @@ -0,0 +1,57 @@ +/* + * Xilfpga platform setup + * + * Copyright (C) 2015 Imagination Technologies + * Author: Zubair Lutfullah Kakakhel + * + * This program is
[PATCH] arm64/mm: use PAGE_ALIGNED instead of IS_ALIGNED
The already provides the PAGE_ALIGNED macro. Let's
use this macro instead of IS_ALIGNED and passing PAGE_SIZE directly.
Signed-off-by: Alexander Kuleshov
---
arch/arm64/mm/pageattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index e47ed1c..3571c73 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -45,7 +45,7 @@ static int change_memory_common(unsigned long addr, int
numpages,
int ret;
struct page_change_data data;
- if (!IS_ALIGNED(addr, PAGE_SIZE)) {
+ if (!PAGE_ALIGNED(addr)) {
start &= PAGE_MASK;
end = start + size;
WARN_ON_ONCE(1);
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v2] ASoC: wm9713: convert to regmap
On 10/24/2015 11:37 PM, Robert Jarzmik wrote: [...] > -static unsigned int ac97_read(struct snd_soc_codec *codec, > - unsigned int reg); > -static int ac97_write(struct snd_soc_codec *codec, > - unsigned int reg, unsigned int val); For review purposes it would be helpful to split this into two patches. One performing the regmap conversion the other replacing ac97_read()/ac97_write() with the matching snd_soc_ calls (or snd_soc_update_bits). > + snd_soc_codec_init_regmap(codec, regmap); You need to call snd_soc_odec_exit_regmap() when the CODEC is unbound. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] regulator, dt: add dt support for tps6502x regulator
add DT support for the tps6502x regulators.
Signed-off-by: Heiko Schocher
---
Changes in v3:
- fold kbuild patch:
regulator, dt: fix platform_no_drv_owner.cocci warnings
into this patch
No need to set .owner here. The core will do it.
Changes in v2:
- add comment from kbuild test robot
- tps6502x_parse_dt_data() can be static
- add comment from Mark Brown:
- remove arch/arm/boot/dts/tps65023.dtsi
- do not use "regulator-compatible"
.../devicetree/bindings/regulator/tps6502x.txt | 58
drivers/regulator/tps65023-regulator.c | 325 +++--
2 files changed, 286 insertions(+), 97 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/tps6502x.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps6502x.txt
b/Documentation/devicetree/bindings/regulator/tps6502x.txt
new file mode 100644
index 000..39f47e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps6502x.txt
@@ -0,0 +1,58 @@
+TPS6502x family of regulators
+
+Required properties:
+- compatible: "ti,tps65020", "ti,tps65021" or "ti,tps65023"
+- reg: I2C slave address
+- regulators: list of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-3] and ldo[1-2]
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Not all regulators for the given
+ device need to be present. The definition for each of these nodes is defined
+ using the standard binding for regulators found at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps: tps@48 {
+ compatible = "ti,tps65023";
+
+ regulators {
+ vdcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ };
+ vdcdc2_reg: regulator@1 {
+ reg = <1>;
+ regulator-name = "vddshv";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+ vdcdc3_reg: regulator@2 {
+ reg = <2>;
+ regulator-name = "vdds";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+ vldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-name = "vdda1p8v_usbphy";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+ vldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-name = "vdda3p3v_usbphy";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/drivers/regulator/tps65023-regulator.c
b/drivers/regulator/tps65023-regulator.c
index 5cc19b4..7662e43 100644
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -25,6 +25,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
/* Register definitions */
#defineTPS65023_REG_VERSION0
@@ -140,8 +144,15 @@ struct tps_pmic {
u8 core_regulator;
};
+enum tps6502x_id {
+ TPS65020,
+ TPS65021,
+ TPS65023,
+};
+
/* Struct passed as driver data */
struct tps_driver_data {
+ enum tps6502x_id id;
const struct tps_info *info;
u8 core_regulator;
};
@@ -199,103 +210,6 @@ static const struct regmap_config tps65023_regmap_config
= {
.val_bits = 8,
};
-static int tps_65023_probe(struct i2c_client *client,
-const struct i2c_device_id *id)
-{
- const struct tps_driver_data *drv_data = (void *)id->driver_data;
- const struct tps_info *info = drv_data->info;
- struct regulator_config config = { };
- struct regulator_init_data *init_data;
- struct regulator_dev *rdev;
- struct tps_pmic *tps;
- int i;
- int error;
-
- /**
-*
[PATCH v12 5/8] PCI: designware: Remove *_mod_base
This patch reverts commit f4c55c5a3f7f ("PCI: designware: Program ATU with
untranslated address") based on 1/8 in this series. we delete *_mod_base in
pcie-designware. This was discussed in [1]
[1] http://www.spinics.net/lists/arm-kernel/msg436779.html
Signed-off-by: Zhou Wang
Signed-off-by: Gabriele Paoloni
Signed-off-by: Arnd Bergmann
Tested-by: James Morse
Tested-by: Gabriel Fernandez
Tested-by: Minghuan Lian
Acked-by: Pratyush Anand
---
drivers/pci/host/pci-dra7xx.c | 8
drivers/pci/host/pcie-designware.c | 38 +-
drivers/pci/host/pcie-designware.h | 4
3 files changed, 13 insertions(+), 37 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 0b4847a..8c36880 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -153,10 +153,10 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
- pp->io_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
- pp->mem_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
- pp->cfg0_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
- pp->cfg1_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->cfg0_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->cfg1_base &= DRA7XX_CPU_TO_BUS_ADDR;
dra7xx_pcie_establish_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 0af1432..1615deb 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -355,26 +355,17 @@ int dw_pcie_host_init(struct pcie_port *pp)
struct platform_device *pdev = to_platform_device(pp->dev);
struct pci_bus *bus, *child;
struct resource *cfg_res;
- u32 val, ns;
- const __be32 *addrp;
- int i, index, ret;
+ u32 val;
+ int i, ret;
LIST_HEAD(res);
struct resource_entry *win;
- ns = of_n_size_cells(np);
-
cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
if (cfg_res) {
pp->cfg0_size = resource_size(cfg_res)/2;
pp->cfg1_size = resource_size(cfg_res)/2;
pp->cfg0_base = cfg_res->start;
pp->cfg1_base = cfg_res->start + pp->cfg0_size;
-
- /* Find the untranslated configuration space address */
- index = of_property_match_string(np, "reg-names", "config");
- addrp = of_get_address(np, index, NULL, NULL);
- pp->cfg0_mod_base = of_read_number(addrp, ns);
- pp->cfg1_mod_base = pp->cfg0_mod_base + pp->cfg0_size;
} else if (!pp->va_cfg0_base) {
dev_err(pp->dev, "missing *config* reg space\n");
}
@@ -397,19 +388,12 @@ int dw_pcie_host_init(struct pcie_port *pp)
ret, pp->io);
continue;
}
- pp->io_base = pp->io->start;
-
- /* Find the untranslated IO space address */
- pp->io_mod_base = pp->io->start;;
break;
case IORESOURCE_MEM:
pp->mem = win->res;
pp->mem->name = "MEM";
pp->mem_size = resource_size(pp->mem);
pp->mem_bus_addr = pp->mem->start - win->offset;
-
- /* Find the untranslated MEM space address */
- pp->mem_mod_base = pp->mem->start;
break;
case 0:
pp->cfg = win->res;
@@ -417,10 +401,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_size = resource_size(pp->cfg)/2;
pp->cfg0_base = pp->cfg->start;
pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
-
- /* Find the untranslated configuration space address */
- pp->cfg0_mod_base = pp->cfg->start;
- pp->cfg1_mod_base = pp->cfg0_mod_base + pp->cfg0_size;
break;
case IORESOURCE_BUS:
pp->busn = win->res;
@@ -488,7 +468,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!pp->ops->rd_other_conf)
dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_TYPE_MEM, pp->mem_mod_base,
+ PCIE_ATU_TYPE_MEM, pp->mem_base,
pp->mem_bus_addr, pp->mem_size);
dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
@@ -546,12 +526,12 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp,
struct pci_bus *bus,
if (bus->parent->number == pp->root_bus_nr) {
type =
Re: [PATCH v4 2/4] mm, proc: account for shmem swap in /proc/pid/smaps
On 10/21/2015 04:39 PM, Vlastimil Babka wrote: > On 10/05/2015 05:01 AM, Hugh Dickins wrote: >> On Fri, 2 Oct 2015, Vlastimil Babka wrote: >> As you acknowledge in the commit message, if a file of 100 pages >> were copied to tmpfs, and 100 tasks map its full extent, but they >> all mess around with the first 50 pages and take no interest in >> the last 50, then it's quite likely that that last 50 will get >> swapped out; then with your patch, 100 tasks are each shown as >> using 50 pages of swap, when none of them are actually using any. > > Yeah, but isn't it the same with private memory which was swapped out at > some point and we don't know if it will be touched or not? The > difference is in private case we know the process touched it at least > once, but that can also mean nothing for the future (or maybe it just > mmapped with MAP_POPULATE and didn't care about half of it). > > That's basically what I was trying to say in the changelog. I interpret > the Swap: value as the amount of swap-in potential, if the process was > going to access it, which is what the particular customer also expects > (see below). In that case showing zero is IMHO wrong and inconsistent > with the anonymous private mappings. I didn't understand the changelog that way an IMHO it's a pretty specific interpretation. I've always understood memory accounting as being primarily the answer to the question: how much resources a process uses? I guess its meaning as been overloaded with corollaries that are only true in the most simple non-shared cases, such as yours or "how much memory would be freed if this process goes away?", but I don't think it should ever be used as a definition. I suppose the reason I didn't understand the changelog the way you intended is because I think that sometimes it's correct to blame a process for pages it never accessed (and I also believe that over-accounting is better that under accounting, but I must admit that it is a quite arbitrary point of view). For instance, what if a process has a shared anonymous mapping that includes pages that it never accessed, but have been populated by an other process that has already exited or munmaped the range? That process is not to blame for the appearance of these pages, but it's the only reason why they stay. I'll offer a lollipop to anyone who comes up with a simple consistent model on how to account shmem pages for all the possible cases, a "Grand Unified Theory of Memory Accounting" so to speak. > Other non-perfect solutions that come to mind: > > 1) For private mappings, count only the swapents. "Swap:" is no longer > showing full swap-in potential though. > 2) For private mappings, do not count swapents. Ditto. > 3) Provide two separate counters. The user won't know how much they > overlap, though. > > From these I would be inclined towards 3) as being more universal, > although then it's no longer a simple "we're fixing a Swap: 0 value > which is wrong", but closer to original Jerome's versions, which IIRC > introduced several shmem-specific counters. You remember correctly. Given all the controversy around shmem accounting, maybe it would indeed be better to leave existing counters, that are relatively well defined and understood, untouched and add specific counters to mess around instead. Thanks, Jerome signature.asc Description: OpenPGP digital signature
[PATCH v12 2/8] ARM/PCI: remove align_resource in pci_sys_data
From: gabriele paoloni
This patch is needed in order to unify the PCIe designware framework for ARM and
ARM64 architectures. In the PCIe designware unification process we are calling
pci_create_root_bus() passing a "sysdata" parameter that is the same for both
ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this will
cause a problem with the function pcibios_align_resource(); in fact this will
cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had passed a
"struct pcie_port*" pointer.
This patch solves the issue by removing "align_resource" from "pci_sys_data"
struct and defining a static global function pointer in "bios32.c"
Signed-off-by: Gabriele Paoloni
Signed-off-by: Zhou Wang
Acked-by: Pratyush Anand
---
arch/arm/include/asm/mach/pci.h | 6 --
arch/arm/kernel/bios32.c| 12
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 8857d28..0070e85 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -52,12 +52,6 @@ struct pci_sys_data {
u8 (*swizzle)(struct pci_dev *, u8 *);
/* IRQ mapping
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
- /* Resource alignement requirements
*/
- resource_size_t (*align_resource)(struct pci_dev *dev,
- const struct resource *res,
- resource_size_t start,
- resource_size_t size,
- resource_size_t align);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 874e182..6551d28 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -17,6 +17,11 @@
#include
static int debug_pci;
+static resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align) = NULL;
/*
* We can't use pci_get_device() here since we are
@@ -456,7 +461,7 @@ static void pcibios_init_hw(struct device *parent, struct
hw_pci *hw,
sys->busnr = busnr;
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
- sys->align_resource = hw->align_resource;
+ align_resource = hw->align_resource;
INIT_LIST_HEAD(>resources);
if (hw->private_data)
@@ -572,7 +577,6 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
resource_size_t size, resource_size_t align)
{
struct pci_dev *dev = data;
- struct pci_sys_data *sys = dev->sysdata;
resource_size_t start = res->start;
if (res->flags & IORESOURCE_IO && start & 0x300)
@@ -580,8 +584,8 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
start = (start + align - 1) & ~(align - 1);
- if (sys->align_resource)
- return sys->align_resource(dev, res, start, size, align);
+ if (align_resource)
+ return align_resource(dev, res, start, size, align);
return start;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 3/8] PCI: designware: Replace DT PCI ranges parse with of_pci_get_host_bridge_resources
This patch uses the new of_pci_get_host_bridge_resources
API in place of the PCI OF DT parser
For reference see previous suggestions from Gabriele[1]
[1] http://www.spinics.net/lists/linux-pci/msg42194.html
Signed-off-by: Zhou Wang
Signed-off-by: Gabriele Paoloni
Tested-by: James Morse
Tested-by: Gabriel Fernandez
Tested-by: Minghuan Lian
Acked-by: Pratyush Anand
---
drivers/pci/host/pci-keystone-dw.c | 2 +-
drivers/pci/host/pcie-designware.c | 106 +
drivers/pci/host/pcie-designware.h | 10 ++--
3 files changed, 55 insertions(+), 63 deletions(-)
diff --git a/drivers/pci/host/pci-keystone-dw.c
b/drivers/pci/host/pci-keystone-dw.c
index e71da99..8062ddb 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -322,7 +322,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
*reg_virt)
void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
{
struct pcie_port *pp = _pcie->pp;
- u32 start = pp->mem.start, end = pp->mem.end;
+ u32 start = pp->mem->start, end = pp->mem->end;
int i, tr_size;
/* Disable BARs for inbound access */
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 75338a6..b914424 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -362,12 +362,12 @@ int dw_pcie_host_init(struct pcie_port *pp)
{
struct device_node *np = pp->dev->of_node;
struct platform_device *pdev = to_platform_device(pp->dev);
- struct of_pci_range range;
- struct of_pci_range_parser parser;
struct resource *cfg_res;
u32 val, ns;
const __be32 *addrp;
int i, index, ret;
+ LIST_HEAD(res);
+ struct resource_entry *win;
ns = of_n_size_cells(np);
@@ -387,75 +387,67 @@ int dw_pcie_host_init(struct pcie_port *pp)
dev_err(pp->dev, "missing *config* reg space\n");
}
- if (of_pci_range_parser_init(, np)) {
- dev_err(pp->dev, "missing ranges property\n");
- return -EINVAL;
- }
+ ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , >io_base);
+ if (ret)
+ return ret;
/* Get the I/O and memory ranges from DT */
- for_each_of_pci_range(, ) {
- unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-
- if (restype == IORESOURCE_IO) {
- of_pci_range_to_resource(, np, >io);
- pp->io.name = "I/O";
- pp->io.start = max_t(resource_size_t,
-PCIBIOS_MIN_IO,
-range.pci_addr + global_io_offset);
- pp->io.end = min_t(resource_size_t,
- IO_SPACE_LIMIT,
- range.pci_addr + range.size
- + global_io_offset - 1);
- pp->io_size = resource_size(>io);
- pp->io_bus_addr = range.pci_addr;
- pp->io_base = range.cpu_addr;
+ resource_list_for_each_entry(win, ) {
+ switch (resource_type(win->res)) {
+ case IORESOURCE_IO:
+ pp->io = win->res;
+ pp->io->name = "I/O";
+ pp->io_size = resource_size(pp->io);
+ pp->io_bus_addr = pp->io->start - win->offset;
+ pp->io->start = max_t(resource_size_t, PCIBIOS_MIN_IO,
+ pp->io_bus_addr +
+ global_io_offset);
+ pp->io->end = min_t(resource_size_t, IO_SPACE_LIMIT,
+ pp->io_bus_addr + pp->io_size +
+ global_io_offset - 1);
+ pp->io_base = pp->io->start;
/* Find the untranslated IO space address */
- pp->io_mod_base = range.cpu_addr;
- }
- if (restype == IORESOURCE_MEM) {
- of_pci_range_to_resource(, np, >mem);
- pp->mem.name = "MEM";
- pp->mem_size = resource_size(>mem);
- pp->mem_bus_addr = range.pci_addr;
+ pp->io_mod_base = pp->io->start;;
+ break;
+ case IORESOURCE_MEM:
+ pp->mem = win->res;
+ pp->mem->name = "MEM";
+ pp->mem_size = resource_size(pp->mem);
+ pp->mem_bus_addr = pp->mem->start - win->offset;
/* Find the untranslated MEM space address */
- pp->mem_mod_base = range.cpu_addr;
- }
- if
[PATCH v12 4/8] PCI: designware: Add ARM64 support
This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.
Signed-off-by: Zhou Wang
Signed-off-by: Gabriele Paoloni
Signed-off-by: Arnd Bergmann
Tested-by: James Morse
Tested-by: Gabriel Fernandez
Tested-by: Minghuan Lian
Acked-by: Pratyush Anand
---
drivers/pci/host/pcie-designware.c | 127 +++--
1 file changed, 38 insertions(+), 89 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index b914424..0af1432 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -69,16 +69,7 @@
#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
- BUG_ON(!sys->private_data);
-
- return sys->private_data;
-}
+static struct pci_ops dw_pcie_ops;
int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
{
@@ -255,7 +246,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int
irq)
static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
{
int irq, pos0, i;
- struct pcie_port *pp = sys_to_pcie(msi_desc_to_pci_sysdata(desc));
+ struct pcie_port *pp = (struct pcie_port *)
msi_desc_to_pci_sysdata(desc);
pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
order_base_2(no_irqs));
@@ -298,7 +289,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip,
struct pci_dev *pdev,
{
int irq, pos;
struct msi_msg msg;
- struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
+ struct pcie_port *pp = pdev->bus->sysdata;
if (desc->msi_attrib.is_msix)
return -EINVAL;
@@ -327,7 +318,7 @@ static void dw_msi_teardown_irq(struct msi_controller
*chip, unsigned int irq)
{
struct irq_data *data = irq_get_irq_data(irq);
struct msi_desc *msi = irq_data_get_msi_desc(data);
- struct pcie_port *pp = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+ struct pcie_port *pp = (struct pcie_port *)
msi_desc_to_pci_sysdata(msi);
clear_irq_range(pp, irq, 1, data->hwirq);
}
@@ -362,6 +353,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
{
struct device_node *np = pp->dev->of_node;
struct platform_device *pdev = to_platform_device(pp->dev);
+ struct pci_bus *bus, *child;
struct resource *cfg_res;
u32 val, ns;
const __be32 *addrp;
@@ -399,12 +391,12 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->io->name = "I/O";
pp->io_size = resource_size(pp->io);
pp->io_bus_addr = pp->io->start - win->offset;
- pp->io->start = max_t(resource_size_t, PCIBIOS_MIN_IO,
- pp->io_bus_addr +
- global_io_offset);
- pp->io->end = min_t(resource_size_t, IO_SPACE_LIMIT,
- pp->io_bus_addr + pp->io_size +
- global_io_offset - 1);
+ ret = pci_remap_iospace(pp->io, pp->io_base);
+ if (ret) {
+ dev_warn(pp->dev, "error %d: failed to map
resource %pR\n",
+ret, pp->io);
+ continue;
+ }
pp->io_base = pp->io->start;
/* Find the untranslated IO space address */
@@ -508,15 +500,35 @@ int dw_pcie_host_init(struct pcie_port *pp)
val |= PORT_LOGIC_SPEED_CHANGE;
dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
-#ifdef CONFIG_PCI_MSI
- dw_pcie_msi_chip.dev = pp->dev;
+ pp->root_bus_nr = pp->busn->start;
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ bus = pci_scan_root_bus_msi(pp->dev, pp->root_bus_nr,
+ _pcie_ops, pp, ,
+ _pcie_msi_chip);
+ dw_pcie_msi_chip.dev = pp->dev;
+ } else
+ bus = pci_scan_root_bus(pp->dev, pp->root_bus_nr, _pcie_ops,
+ pp, );
+ if (!bus)
+ return -ENOMEM;
+
+ if (pp->ops->scan_bus)
+ pp->ops->scan_bus(pp);
+
+#ifdef CONFIG_ARM
+ /* support old dtbs that incorrectly describe IRQs */
+ pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
#endif
- dw_pci.nr_controllers = 1;
- dw_pci.private_data = (void **)
+ if (!pci_has_flag(PCI_PROBE_ONLY)) {
+
[PATCH v12 6/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
This patch adds PCIe host support for HiSilicon SoC Hip05.
Signed-off-by: Zhou Wang
Signed-off-by: Gabriele Paoloni
Signed-off-by: liudongdong
---
drivers/pci/host/Kconfig | 8 ++
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pcie-hisi.c | 198 +++
3 files changed, 207 insertions(+)
create mode 100644 drivers/pci/host/pcie-hisi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..ae873be 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
Say Y here if you want to use the Broadcom iProc PCIe controller
through the BCMA bus interface
+config PCI_HISI
+ depends on OF && ARM64
+ bool "HiSilicon SoC HIP05 PCIe controller"
+ select PCIEPORTBUS
+ select PCIE_DW
+ help
+ Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..ea1dbf2 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
new file mode 100644
index 000..545d4e7
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.c
@@ -0,0 +1,198 @@
+/*
+ * PCIe host controller driver for HiSilicon Hip05 SoC
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang
+ * Dacai Zhu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-designware.h"
+
+#define PCIE_SUBCTRL_SYS_STATE4_REG 0x6818
+#define PCIE_LTSSM_LINKUP_STATE 0x11
+#define PCIE_LTSSM_STATE_MASK 0x3F
+
+#define to_hisi_pcie(x)container_of(x, struct hisi_pcie, pp)
+
+struct hisi_pcie {
+ struct regmap *subctrl;
+ void __iomem *reg_base;
+ u32 port_id;
+ struct pcie_port pp;
+};
+
+static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
+ u32 val, u32 reg)
+{
+ writel(val, pcie->reg_base + reg);
+}
+
+static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
+{
+ return readl(pcie->reg_base + reg);
+}
+
+/* Hip05 PCIe host only supports 32-bit config access */
+static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
+ u32 *val)
+{
+ u32 reg;
+ u32 reg_val;
+ struct hisi_pcie *pcie = to_hisi_pcie(pp);
+ void *walker = _val;
+
+ walker += (where & 0x3);
+ reg = where & ~0x3;
+ reg_val = hisi_pcie_apb_readl(pcie, reg);
+
+ if (size == 1)
+ *val = *(u8 __force *) walker;
+ else if (size == 2)
+ *val = *(u16 __force *) walker;
+ else if (size != 4)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+/* Hip05 PCIe host only supports 32-bit config access */
+static int hisi_pcie_cfg_write(struct pcie_port *pp, int where, int size,
+ u32 val)
+{
+ u32 reg_val;
+ u32 reg;
+ struct hisi_pcie *pcie = to_hisi_pcie(pp);
+ void *walker = _val;
+
+ walker += (where & 0x3);
+ reg = where & ~0x3;
+ if (size == 4)
+ hisi_pcie_apb_writel(pcie, val, reg);
+ else if (size == 2) {
+ reg_val = hisi_pcie_apb_readl(pcie, reg);
+ *(u16 __force *) walker = val;
+ hisi_pcie_apb_writel(pcie, reg_val, reg);
+ } else if (size == 1) {
+ reg_val = hisi_pcie_apb_readl(pcie, reg);
+ *(u8 __force *) walker = val;
+ hisi_pcie_apb_writel(pcie, reg_val, reg);
+ } else
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int hisi_pcie_link_up(struct pcie_port *pp)
+{
+ u32 val;
+ struct hisi_pcie *hisi_pcie = to_hisi_pcie(pp);
+
+ regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
+ 0x100 * hisi_pcie->port_id, );
+
+ return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
+static struct pcie_host_ops hisi_pcie_host_ops = {
+ .rd_own_conf = hisi_pcie_cfg_read,
+ .wr_own_conf = hisi_pcie_cfg_write,
+ .link_up = hisi_pcie_link_up,
+};
+
+static int __init hisi_add_pcie_port(struct pcie_port *pp,
+struct
[PATCH v12 0/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts use PCIe IP core from Synopsys, So this driver is based on designware PCIe driver. Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API in designware PCIe driver. So this patch also adds ARM64 support for designware pcie. This patchset is based on v4.3-rc1. Change from v11: - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12. - Add print in pcie-hisi.c to indicate read/write hardware defect. - Modify macro in 1/8 pointed by Bjorn. Change from v10: - Remove MSI related setting and VMID/ASID table setting, they will be implemented in BIOS. - Use module_platform_driver to init pcie-hisi.c - Add necessary comments. Change from v9: - Use syscon to get subctrl base address. - 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02 board from Ding Tianhong - Add hisi_pcie_cfg_read in pcie-hisi.c to match [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and dw_pcie_cfg_read() from Gabriele. Change from v8: - Rebase on v4.3-rc1. - Add Tested-by from Gabriel and Minghuan. - Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need this as PCI core does related job. Add ITS base address parsing in msi_host_init. - Change vmid/asid table configuration, previous configuration was wrong. - Add wr_own_conf callback in pcie-hisi.c. - Use subsys_initcall to init hisi PCIe. Change from v7: - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape, spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number. - Remove bus-range parsing in pcie-hisi.c. Change from v6: - Add Pratyush's Acked-by for 1/6 and 2/6. - Add James' Tested-by for 3/6. Change from v5: - Merge 1/6 in this series, discussion about this can be found in [1] Change from v4: - Change the author of 1/5 to Gabriele. - Modify problems in 3/5 pointed by Bjorn. - Modify spelling problems in 4/5. Change from v3: - Change 1/5 to what Gabriele suggested. - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series. Change from v2: - Move struct pci_dev *dev and struct pci_sys_data *sys in pcibios_align_resource in 1/5. - Add Gabriele's codes in 2/5 which delete unnecessary information parse and use of_pci_get_host_bridge_resources for both ARM32 and ARM64. - Add maintainer patch 5/5. Change from RFC v1: - Add 1/4 patch by Arnd which removes align_resource callback in ARM pcibios_align_resource. - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h. - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape, spear13xx. - Remove unnecessary parentheses of some macros in pcie-hisi. - Use macro to replace some magic values. - Merge two loops together and add some comments about it in context_config function in pcie-hisi. - Modify some value of items in pcie node example in binding document. Change from RFC: - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci, merge related operations into dw_pcie_host_init. Link of v11: - https://lkml.org/lkml/2015/10/16/228 Link of v10: - http://www.spinics.net/lists/linux-pci/msg45490.html Link of v9: - http://www.spinics.net/lists/linux-pci/msg44545.html Link of v8: - http://www.spinics.net/lists/linux-pci/msg44192.html Link of v7: - http://www.spinics.net/lists/devicetree/msg90690.html Link of v6: - http://www.spinics.net/lists/linux-pci/msg43669.html Link of v5: - http://www.spinics.net/lists/devicetree/msg87959.html Link of v4: - http://www.spinics.net/lists/arm-kernel/msg433050.html Link of v3: - http://www.spinics.net/lists/linux-pci/msg42539.html Link of v2: - http://www.spinics.net/lists/linux-pci/msg41844.html Link of RFC v1: - http://www.spinics.net/lists/linux-pci/msg41305.html Link of RFC: - http://www.spinics.net/lists/linux-pci/msg40434.html [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359741.html Zhou Wang (6): PCI: designware: Replace DT PCI ranges parse with of_pci_get_host_bridge_resources PCI: designware: Add ARM64 support PCI: designware: Remove *_mod_base PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05 Documentation: DT: Add HiSilicon PCIe host binding MAINTAINERS: Add pcie-hisi maintainer gabriele paoloni (2): PCI: designware: move calculation of bus addresses to DRA7xx ARM/PCI: remove align_resource in pci_sys_data .../bindings/arm/hisilicon/hisilicon.txt | 17 ++ .../devicetree/bindings/pci/hisilicon-pcie.txt | 44 MAINTAINERS| 7 + arch/arm/include/asm/mach/pci.h| 6 - arch/arm/kernel/bios32.c | 12 +- drivers/pci/host/Kconfig | 8 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pci-dra7xx.c | 7 + drivers/pci/host/pci-keystone-dw.c | 2 +- drivers/pci/host/pcie-designware.c
[PATCH v12 1/8] PCI: designware: move calculation of bus addresses to DRA7xx
From: gabriele paoloni
Commit f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
address") added the calculation of PCI BUS addresses in designware,
storing them in new fields added in "struct pcie_port". This
calculation is done for every designware user even if is only
applicable to DRA7xx.
This patch moves the calculation of the bus addresses to the DRA7xx
driver and is needed to allow the rework of designware to use
the new DT parsing API.
Signed-off-by: Gabriele Paoloni
Signed-off-by: Zhou Wang
Acked-by: Pratyush Anand
---
drivers/pci/host/pci-dra7xx.c | 7 +++
drivers/pci/host/pcie-designware.c | 15 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 199e29a..0b4847a 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -62,6 +62,7 @@
#definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
#defineLINK_UP BIT(16)
+#defineDRA7XX_CPU_TO_BUS_ADDR 0x0FFF
struct dra7xx_pcie {
void __iomem*base;
@@ -151,6 +152,12 @@ static void dra7xx_pcie_enable_interrupts(struct pcie_port
*pp)
static void dra7xx_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
+
+ pp->io_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->mem_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->cfg0_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
+ pp->cfg1_mod_base &= DRA7XX_CPU_TO_BUS_ADDR;
+
dra7xx_pcie_establish_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 52aa6e3..75338a6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -365,14 +365,10 @@ int dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range range;
struct of_pci_range_parser parser;
struct resource *cfg_res;
- u32 val, na, ns;
+ u32 val, ns;
const __be32 *addrp;
int i, index, ret;
- /* Find the address cell size and the number of cells in order to get
-* the untranslated address.
-*/
- of_property_read_u32(np, "#address-cells", );
ns = of_n_size_cells(np);
cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
@@ -415,8 +411,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->io_base = range.cpu_addr;
/* Find the untranslated IO space address */
- pp->io_mod_base = of_read_number(parser.range -
-parser.np + na, ns);
+ pp->io_mod_base = range.cpu_addr;
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(, np, >mem);
@@ -425,8 +420,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->mem_bus_addr = range.pci_addr;
/* Find the untranslated MEM space address */
- pp->mem_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+ pp->mem_mod_base = range.cpu_addr;
}
if (restype == 0) {
of_pci_range_to_resource(, np, >cfg);
@@ -436,8 +430,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
/* Find the untranslated configuration space address */
- pp->cfg0_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+ pp->cfg0_mod_base = range.cpu_addr;
pp->cfg1_mod_base = pp->cfg0_mod_base +
pp->cfg0_size;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 8/8] MAINTAINERS: Add pcie-hisi maintainer
Signed-off-by: Zhou Wang --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7ba7ab7..944a229 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8047,6 +8047,13 @@ S: Maintained F: Documentation/devicetree/bindings/pci/xgene-pci-msi.txt F: drivers/pci/host/pci-xgene-msi.c +PCIE DRIVER FOR HISILICON +M: Zhou Wang +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt +F: drivers/pci/host/pcie-hisi.c + PCMCIA SUBSYSTEM P: Linux PCMCIA Team L: linux-pcm...@lists.infradead.org -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 7/8] Documentation: DT: Add HiSilicon PCIe host binding
This patch adds related DTS binding document for HiSilicon PCIe host driver.
Signed-off-by: Zhou Wang
---
.../bindings/arm/hisilicon/hisilicon.txt | 17 +
.../devicetree/bindings/pci/hisilicon-pcie.txt | 44 ++
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 3504dca..6ac7c00 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -171,6 +171,23 @@ Example:
};
---
+Hisilicon HiP05 PCIe-SAS system controller
+
+Required properties:
+- compatible : "hisilicon,pcie-sas-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers in
+HiP05 Soc to implement some basic configurations.
+
+Example:
+ /* for HiP05 PCIe-SAS system */
+ pcie_sas: system_controller@0xb000 {
+ compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+ reg = <0xb000 0x1>;
+ };
+
+---
Hisilicon CPU controller
Required properties:
diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
new file mode 100644
index 000..17c6ed9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -0,0 +1,44 @@
+HiSilicon PCIe host bridge DT description
+
+HiSilicon PCIe host controller is based on Designware PCI core.
+It shares common functions with PCIe Designware core driver and inherits
+common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties:
+- compatible: Should contain "hisilicon,hip05-pcie".
+- reg: Should contain rc_dbi, config registers location and length.
+- reg-names: Must include the following entries:
+ "rc_dbi": controller configuration registers;
+ "config": PCIe configuration space registers.
+- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
+- port-id: Should be 0, 1, 2 or 3.
+
+Optional properties:
+- status: Either "ok" or "disabled".
+- dma-coherent: Present if DMA operations are coherent.
+
+Example:
+ pcie@0xb008 {
+ compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
+ reg = <0 0xb008 0 0x1>, <0x220 0x 0 0x2000>;
+ reg-names = "rc_dbi", "config";
+ bus-range = <0 15>;
+ msi-parent = <_pcie>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ ranges = <0x8200 0 0x 0x220 0x 0
0x1000>;
+ num-lanes = <8>;
+ port-id = <1>;
+ #interrupts-cells = <1>;
+ interrupts-map-mask = <0xf800 0 0 7>;
+ interrupts-map = <0x0 0 0 1 _pcie 1 10
+ 0x0 0 0 2 _pcie 2 11
+ 0x0 0 0 3 _pcie 3 12
+ 0x0 0 0 4 _pcie 4 13>;
+ status = "ok";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ASoC: wm9713: convert to regmap
On Sat, Oct 24, 2015 at 11:37:07PM +0200, Robert Jarzmik wrote:
> Convert the Wolfson WM9713 to regmap API. This will leverage all the
> regmap functions (debug, registers update, etc ...).
>
> As a bonus, this will pave the path to gpio chip introduction, and
> devicetree support.
>
> Signed-off-by: Robert Jarzmik
> ---
> Since v1: fix suspend/resume (that specific part is not tested yet)
> ---
> sound/soc/codecs/Kconfig | 1 +
> sound/soc/codecs/wm9713.c | 296
> +++---
> 2 files changed, 152 insertions(+), 145 deletions(-)
> @@ -1156,16 +1165,17 @@ static int wm9713_set_bias_level(struct snd_soc_codec
> *codec,
>
> static int wm9713_soc_suspend(struct snd_soc_codec *codec)
> {
> - u16 reg;
> + regcache_cache_only(codec->component.regmap, true);
> + snd_soc_cache_sync(codec);
I am assuming we don't want to be doing a cache_sync just after we
have marked the regmap as cache only.
>
> /* Disable everything except touchpanel - that will be handled
>* by the touch driver and left disabled if touch is not in
>* use. */
> - reg = ac97_read(codec, AC97_EXTENDED_MID);
> - ac97_write(codec, AC97_EXTENDED_MID, reg | 0x7fff);
> - ac97_write(codec, AC97_EXTENDED_MSTATUS, 0x);
> - ac97_write(codec, AC97_POWERDOWN, 0x6f00);
> - ac97_write(codec, AC97_POWERDOWN, 0x);
> + snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x7fff,
> + 0x7fff);
> + snd_soc_write(codec, AC97_EXTENDED_MSTATUS, 0x);
> + snd_soc_write(codec, AC97_POWERDOWN, 0x6f00);
> + snd_soc_write(codec, AC97_POWERDOWN, 0x);
Also as you have already marked the regmap as cache only these
writes won't go to the hardware.
Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: qcom_smbb: Add otg regulator for control of vbus
On Thu, Oct 22, 2015 at 02:12:17PM -0700, Tim Bird wrote:
> Add a regulator to control the OTG chargepath switch. The OTG
> switch gets its power from pm8941_5vs1, and that should be expressed
> as an usb_otg_in-supply property in the DT node for the charger driver.
> The regulator name is "otg". This is used by USB code to control VBUS
> direction.
>
> Signed-off-by: Tim Bird
> ---
> .../devicetree/bindings/power_supply/qcom_smbb.txt | 20 ++
> drivers/power/qcom_smbb.c | 74
> ++
> 2 files changed, 94 insertions(+)
What tree is this based on? I couldn't spot this in origin/master.
> diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> index 65b88fa..dc0f91d 100644
> --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
> @@ -105,6 +105,23 @@ PROPERTIES
> regulation must be done externally to fully comply with
> the JEITA safety guidelines if this flag is set.
>
> +- usb_otg_in-supply:
> + Usage: optional
> + Value type:
> + Description: Reference to the regulator supplying power to the USB_OTG_IN
> + pin.
s/_/-/ in property names, please.
> +
> +child nodes:
> +- otg:
> + Usage: optional
> + Description: This node is used to define a regulator which is used by
> + other parts of the system to control the direction of VBUS
> + voltage - specifically: whether to supply voltage to VBUS for
> + host mode operation of the OTG port. The driver registers a
> + regulator with this name, which can be looked up by string.
> + Alternatively, you can add a DT label, which can then be
> + referenced by phandle.
> +
We shouldn't specify the behaviours of the driver/linux here, just the
hardware.
I'm a little confused by how this is used, but I suspect that'll be
cleared up when I see the rest of the binding that this is based on.
Thanks,
Mark.
> EXAMPLE
> charger@1000 {
> compatible = "qcom,pm8941-charger";
> @@ -128,4 +145,7 @@ charger@1000 {
>
> qcom,fast-charge-current-limit = <100>;
> qcom,dc-charge-current-limit = <100>;
> + usb_otg_in-supply = <_5vs1>;
> +
> + otg {};
> };
> diff --git a/drivers/power/qcom_smbb.c b/drivers/power/qcom_smbb.c
> index 0dabfe8..fa2983a 100644
> --- a/drivers/power/qcom_smbb.c
> +++ b/drivers/power/qcom_smbb.c
> @@ -34,6 +34,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #define SMBB_CHG_VMAX0x040
> #define SMBB_CHG_VSAFE 0x041
> @@ -71,6 +74,8 @@
> #define BTC_CTRL_HOT_EXT_N BIT(0)
>
> #define SMBB_USB_IMAX0x344
> +#define SMBB_USB_OTG_CTL 0x348
> +#define OTG_CTL_EN BIT(0)
> #define SMBB_USB_ENUM_TIMER_STOP 0x34e
> #define ENUM_TIMER_STOP BIT(0)
> #define SMBB_USB_SEC_ACCESS 0x3d0
> @@ -123,6 +128,9 @@ struct smbb_charger {
> struct power_supply *dc_psy;
> struct power_supply *bat_psy;
> struct regmap *regmap;
> +
> + struct regulator_desc otg_rdesc;
> + struct regulator_dev *otg_reg;
> };
>
> static int smbb_vbat_weak_fn(unsigned int index)
> @@ -778,12 +786,56 @@ static const struct power_supply_desc dc_psy_desc = {
> .property_is_writeable = smbb_charger_writable_property,
> };
>
> +static int smbb_chg_otg_enable(struct regulator_dev *rdev)
> +{
> + struct smbb_charger *chg = rdev_get_drvdata(rdev);
> + int rc;
> +
> + rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
> + OTG_CTL_EN, OTG_CTL_EN);
> + if (rc)
> + dev_err(chg->dev, "failed to update OTG_CTL\n");
> + return rc;
> +}
> +
> +static int smbb_chg_otg_disable(struct regulator_dev *rdev)
> +{
> + struct smbb_charger *chg = rdev_get_drvdata(rdev);
> + int rc;
> +
> + rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
> + OTG_CTL_EN, 0);
> + if (rc)
> + dev_err(chg->dev, "failed to update OTG_CTL\n");
> + return rc;
> +}
> +
> +static int smbb_chg_otg_is_enabled(struct regulator_dev *rdev)
> +{
> + struct smbb_charger *chg = rdev_get_drvdata(rdev);
> + unsigned int value = 0;
> + int rc;
> +
> + rc = regmap_read(chg->regmap, chg->addr + SMBB_USB_OTG_CTL, );
> + if (rc)
> + dev_err(chg->dev, "failed to read OTG_CTL\n");
> +
> + return !!(value & OTG_CTL_EN);
> +}
> +
> +static struct regulator_ops smbb_chg_otg_ops = {
> + .enable = smbb_chg_otg_enable,
> + .disable = smbb_chg_otg_disable,
> + .is_enabled = smbb_chg_otg_is_enabled,
> +};
> +
> static int smbb_charger_probe(struct platform_device *pdev)
> {
> struct power_supply_config bat_cfg
Re: [PATCH v2 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
On Mon, 26 Oct 2015, Alim Akhtar wrote: > From: Thomas Abraham > > Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device > is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Thomas Abraham > Signed-off-by: Alim Akhtar > Reviewed-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 > ++--- > 1 file changed, 15 insertions(+), 8 deletions(-) Nothing to controversial here. For my own reference: Acked-by: Lee Jones > diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt > b/Documentation/devicetree/bindings/mfd/s2mps11.txt > index 890f0b0e1643..c0427c9d0886 100644 > --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt > +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt > @@ -1,5 +1,5 @@ > > -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator > +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator > > The Samsung S2MPS11 is a multi-function device which includes voltage and > current regulators, RTC, charger controller and other sub-blocks. It is > @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. > Each sub-block is > addressed by the host system using different I2C slave addresses. > > Required properties: > -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" > - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". > +- compatible: Should be one of the following > + - "samsung,s2mps11-pmic" > + - "samsung,s2mps13-pmic" > + - "samsung,s2mps14-pmic" > + - "samsung,s2mps15-pmic" > + - "samsung,s2mpu02-pmic". > - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. > > Optional properties: > @@ -24,7 +28,7 @@ Optional properties: >unwanted buck warm reset (setting buck voltages to default values). > > Optional nodes: > -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered > 32.768 > +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) > buffered 32.768 >KHz outputs, so to register these as clocks with common clock framework >instantiate a sub-node named "clocks". It uses the common clock binding >documented in : > @@ -37,12 +41,13 @@ Optional nodes: > the clock which they consume. > Clock ID Devices > -- > -32KhzAP 0S2MPS11, S2MPS13, S2MPS14, S5M8767 > -32KhzCP 1S2MPS11, S2MPS13, S5M8767 > -32KhzBT 2S2MPS11, S2MPS13, S2MPS14, S5M8767 > +32KhzAP 0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 > +32KhzCP 1S2MPS11, S2MPS13, S2MPS15, S5M8767 > +32KhzBT 2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 > >- compatible: Should be one of: "samsung,s2mps11-clk", > "samsung,s2mps13-clk", > - "samsung,s2mps14-clk", "samsung,s5m8767-clk" > + "samsung,s2mps14-clk", "samsung,s2mps15-clk", > + "samsung,s5m8767-clk" > > - regulators: The regulators of s2mps11 that have to be instantiated should > be > included in a sub-node named 'regulators'. Regulator nodes included in this > @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. > - S2MPS11: 1 to 38 > - S2MPS13: 1 to 40 > - S2MPS14: 1 to 25 > + - S2MPS15: 1 to 27 > - S2MPU02: 1 to 28 > - Example: LDO1, LDO2, LDO28 > - BUCKn > @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. > - S2MPS11: 1 to 10 > - S2MPS13: 1 to 10 > - S2MPS14: 1 to 5 > + - S2MPS15: 1 to 10 > - S2MPU02: 1 to 7 > - Example: BUCK1, BUCK2, BUCK9 > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/3] PCI: generate proper configuration access cycles
Inspired by Russell King's patch[1], I found some pci hosts also have the same issue of "reading 32-bits from the command register, modifying the command register, and then writing it back has the effect of clearing any status bits that were indicating at that time" as pointed out by Russell. Fix them by using the pci_generic_config_write. Another problem is do we need to use proper readb/readw for config read? Jisheng Zhang (3): PCI: iproc: generate proper configuration access cycles PCI: tegra: generate proper configuration access cycles PCI: xgene: generate proper configuration access cycles drivers/pci/host/pci-tegra.c | 2 +- drivers/pci/host/pci-xgene.c | 2 +- drivers/pci/host/pcie-iproc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/3] PCI: iproc: generate proper configuration access cycles
Inspired by Russell King's patch[1], I found current iproc also has the
same issue of "reading 32-bits from the command register, modifying the
command register, and then writing it back has the effect of clearing
any status bits that were indicating at that time" as pointed out by
Russell. This patch fix this issue by using the pci_generic_config_write.
[1]http://www.spinics.net/lists/linux-pci/msg44869.html
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pcie-iproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index fe2efb1..0c423f2 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -111,7 +111,7 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct pci_bus
*bus,
static struct pci_ops iproc_pcie_ops = {
.map_bus = iproc_pcie_map_cfg_bus,
.read = pci_generic_config_read32,
- .write = pci_generic_config_write32,
+ .write = pci_generic_config_write,
};
static void iproc_pcie_reset(struct iproc_pcie *pcie)
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/3] PCI: xgene: generate proper configuration access cycles
Inspired by Russell King's patch[1], I found current tegra also has the
same issue of "reading 32-bits from the command register, modifying the
command register, and then writing it back has the effect of clearing
any status bits that were indicating at that time" as pointed out by
Russell. This patch fix this issue by using the pci_generic_config_write.
[1]http://www.spinics.net/lists/linux-pci/msg44869.html
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pci-xgene.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0236ab9..8946a6c 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -176,7 +176,7 @@ static int xgene_pcie_config_read32(struct pci_bus *bus,
unsigned int devfn,
static struct pci_ops xgene_pcie_ops = {
.map_bus = xgene_pcie_map_bus,
.read = xgene_pcie_config_read32,
- .write = pci_generic_config_write32,
+ .write = pci_generic_config_write,
};
static u64 xgene_pcie_set_ib_mask(void __iomem *csr_base, u32 addr,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/3] PCI: tegra: generate proper configuration access cycles
Inspired by Russell King's patch[1], I found current tegra also has the
same issue of "reading 32-bits from the command register, modifying the
command register, and then writing it back has the effect of clearing
any status bits that were indicating at that time" as pointed out by
Russell. This patch fix this issue by using the pci_generic_config_write.
[1]http://www.spinics.net/lists/linux-pci/msg44869.html
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pci-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 81df0c1..d926e3e 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -483,7 +483,7 @@ static void __iomem *tegra_pcie_conf_address(struct pci_bus
*bus,
static struct pci_ops tegra_pcie_ops = {
.map_bus = tegra_pcie_conf_address,
.read = pci_generic_config_read32,
- .write = pci_generic_config_write32,
+ .write = pci_generic_config_write,
};
static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
On Mon, 26 Oct 2015, Alim Akhtar wrote:
> From: Thomas Abraham
>
> Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
> PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
> clock outputs and battery charger. This patch adds initial support for
> LDO and buck regulators of S2MPS15 device.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Alim Akhtar
> [Alim: Added s2mps15_devs like rtc and clk and related changes]
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/mfd/sec-core.c | 31 +++
> drivers/mfd/sec-irq.c |8 ++
> include/linux/mfd/samsung/core.h|1 +
> include/linux/mfd/samsung/s2mps15.h | 161
> +++
> 4 files changed, 201 insertions(+)
> create mode 100644 include/linux/mfd/samsung/s2mps15.h
>
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 2626fc0b5b8c..db3d4d4ff805 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
> }
> };
>
> +static const struct mfd_cell s2mps15_devs[] = {
> + {
> + .name = "s2mps15-pmic",
> + }, {
> + .name = "s2mps15-rtc",
> + }, {
Why don't these have compatibles?
> + .name = "s2mps15-clk",
> + .of_compatible = "samsung,s2mps15-clk",
> + },
> +};
> +
> static const struct mfd_cell s2mpa01_devs[] = {
> {
> .name = "s2mpa01-pmic",
> @@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
> .compatible = "samsung,s2mps14-pmic",
> .data = (void *)S2MPS14X,
> }, {
> + .compatible = "samsung,s2mps15-pmic",
> + .data = (void *)S2MPS15X,
> + }, {
> .compatible = "samsung,s2mpa01-pmic",
> .data = (void *)S2MPA01,
> }, {
> @@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config
> = {
> .cache_type = REGCACHE_FLAT,
> };
>
> +static const struct regmap_config s2mps15_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = S2MPS15_REG_LDODSCH4,
> + .volatile_reg = s2mps11_volatile,
> + .cache_type = REGCACHE_FLAT,
> +};
> +
> static const struct regmap_config s2mpu02_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> case S2MPS14X:
> regmap = _regmap_config;
> break;
> + case S2MPS15X:
> + regmap = _regmap_config;
> + break;
> case S5M8763X:
> regmap = _regmap_config;
> break;
> @@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> sec_devs = s2mps14_devs;
> num_sec_devs = ARRAY_SIZE(s2mps14_devs);
> break;
> + case S2MPS15X:
> + sec_devs = s2mps15_devs;
> + num_sec_devs = ARRAY_SIZE(s2mps15_devs);
> + break;
> case S2MPU02:
> sec_devs = s2mpu02_devs;
> num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
> diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
> index 806fa8dbb22d..d77de431cc50 100644
> --- a/drivers/mfd/sec-irq.c
> +++ b/drivers/mfd/sec-irq.c
> @@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
> S2MPS1X_IRQ_CHIP_COMMON_DATA,
> };
>
> +static const struct regmap_irq_chip s2mps15_irq_chip = {
> + .name = "s2mps15",
> + S2MPS1X_IRQ_CHIP_COMMON_DATA,
> +};
> +
> static const struct regmap_irq_chip s2mpu02_irq_chip = {
> .name = "s2mpu02",
> .irqs = s2mpu02_irqs,
> @@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
> case S2MPS14X:
> sec_irq_chip = _irq_chip;
> break;
> + case S2MPS15X:
> + sec_irq_chip = _irq_chip;
> + break;
> case S2MPU02:
> sec_irq_chip = _irq_chip;
> break;
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index a06098639399..6bc4bcd488ac 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -44,6 +44,7 @@ enum sec_device_type {
> S2MPS11X,
> S2MPS13X,
> S2MPS14X,
> + S2MPS15X,
> S2MPU02,
> };
>
> diff --git a/include/linux/mfd/samsung/s2mps15.h
> b/include/linux/mfd/samsung/s2mps15.h
> new file mode 100644
> index ..7443af6a4bba
> --- /dev/null
> +++ b/include/linux/mfd/samsung/s2mps15.h
> @@ -0,0 +1,161 @@
> +/*
> + * s2mps15.h
Remove this please.
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify it
Crypto Fixes for 4.3
Hi Linus: This push fixes a problem in the Crypto API that may cause spurious errors when signals are received by the process that made the orignal system call into the kernel. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: api - Only abort operations on fatal signal crypto/ablkcipher.c |2 +- crypto/algapi.c |2 +- crypto/api.c |6 +++--- crypto/crypto_user.c |2 +- 4 files changed, 6 insertions(+), 6 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade
Hi, > On 24 oct. 2015, at 22:11, Jiri Kosina wrote: > > On Sat, 24 Oct 2015, Michele Baldessari wrote: > >> The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order >> to have the two distinct joysticks working. >> >> Before the change: >> $ jstest /dev/input/js0 >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) >> ... >> $ jstest /dev/input/js1 >> jstest: No such file or directory >> >> After the change: >> $ jstest /dev/input/js0 >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) >> ... >> $ jstest /dev/input/js1 >> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) >> ... >> >> Signed-off-by: Michele Baldessari > > Adding Oliver to CC. > > Oliver, how come that you didn't need this while working on the inigial > Xin-Mo Dual Arcade support? Because I didn’t mind whether the controller announced itself as two joysticks with two axes each, or one joystick with four axes. In the software I use it for (a MAME for the Raspberry Pi), I can map a single device’s buttons and axes to several players. I’m a bit surprised with this, though: > $ jstest /dev/input/js0 > Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y) because in my case I had four axes, at least using evtest (I don’t remember if I tried jstest as well). What bothered me at the time, though, is that even though the custom driver was made as a kernel module, an entry had to be added in the hid_have_special_driver table in hid-core.c for the kernel to use it, which means, if I understand properly, that the kernel still needs recompiling. Is that normal? Best regards, Olivier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pwm: lpss: Add support for runtime PM
From: Qipeng Zha
To be able to save some power when PWM is not in use, add support for
runtime PM for this driver. This also allows the platform to transition to
low power S0ix states when the system is idle.
Signed-off-by: Huiquan Zhong
Signed-off-by: Qipeng Zha
Signed-off-by: Mika Westerberg
---
The original patch from Qipeng is here:
http://thread.gmane.org/gmane.linux.pwm/2803
I modified it a bit so that it does runtime_pm_get_sync() on enable and
runtime_pm_put() on disable. That allows us to get rid of the autosuspend
thing in v2.
This applies on top of my previous series here:
http://thread.gmane.org/gmane.linux.pwm/2920
drivers/pwm/pwm-lpss-pci.c | 32
drivers/pwm/pwm-lpss-platform.c | 6 ++
drivers/pwm/pwm-lpss.c | 7 +++
3 files changed, 45 insertions(+)
diff --git a/drivers/pwm/pwm-lpss-pci.c b/drivers/pwm/pwm-lpss-pci.c
index c15bc6d00f1a..7160e8ab38a4 100644
--- a/drivers/pwm/pwm-lpss-pci.c
+++ b/drivers/pwm/pwm-lpss-pci.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "pwm-lpss.h"
@@ -33,6 +34,10 @@ static int pwm_lpss_probe_pci(struct pci_dev *pdev,
return PTR_ERR(lpwm);
pci_set_drvdata(pdev, lpwm);
+
+ pm_runtime_put(>dev);
+ pm_runtime_allow(>dev);
+
return 0;
}
@@ -40,9 +45,33 @@ static void pwm_lpss_remove_pci(struct pci_dev *pdev)
{
struct pwm_lpss_chip *lpwm = pci_get_drvdata(pdev);
+ pm_runtime_forbid(>dev);
+ pm_runtime_get_sync(>dev);
+
pwm_lpss_remove(lpwm);
}
+#ifdef CONFIG_PM
+static int pwm_lpss_runtime_suspend_pci(struct device *dev)
+{
+ /*
+* The PCI core will handle transition to D3 automatically. We only
+* need to provide runtime PM hooks for that to happen.
+*/
+ return 0;
+}
+
+static int pwm_lpss_runtime_resume_pci(struct device *dev)
+{
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops pwm_lpss_pci_pm = {
+ SET_RUNTIME_PM_OPS(pwm_lpss_runtime_suspend_pci,
+ pwm_lpss_runtime_resume_pci, NULL)
+};
+
static const struct pci_device_id pwm_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x0ac8), (unsigned long)_lpss_bxt_info},
{ PCI_VDEVICE(INTEL, 0x0f08), (unsigned long)_lpss_byt_info},
@@ -60,6 +89,9 @@ static struct pci_driver pwm_lpss_driver_pci = {
.id_table = pwm_lpss_pci_ids,
.probe = pwm_lpss_probe_pci,
.remove = pwm_lpss_remove_pci,
+ .driver = {
+ .pm = _lpss_pci_pm,
+ },
};
module_pci_driver(pwm_lpss_driver_pci);
diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c
index a914aacf6757..54433fc6d1a4 100644
--- a/drivers/pwm/pwm-lpss-platform.c
+++ b/drivers/pwm/pwm-lpss-platform.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "pwm-lpss.h"
@@ -36,6 +37,10 @@ static int pwm_lpss_probe_platform(struct platform_device
*pdev)
return PTR_ERR(lpwm);
platform_set_drvdata(pdev, lpwm);
+
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
+
return 0;
}
@@ -43,6 +48,7 @@ static int pwm_lpss_remove_platform(struct platform_device
*pdev)
{
struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
+ pm_runtime_disable(>dev);
return pwm_lpss_remove(lpwm);
}
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index df03b50f20dd..25044104003b 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "pwm-lpss.h"
@@ -105,6 +106,8 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct
pwm_device *pwm,
duty_ns = 1;
on_time_div = 255 - (255 * duty_ns / period_ns);
+ pm_runtime_get_sync(chip->dev);
+
ctrl = pwm_lpss_read(pwm);
ctrl &= ~(PWM_BASE_UNIT_MASK | PWM_ON_TIME_DIV_MASK);
ctrl |= (u16) base_unit << PWM_BASE_UNIT_SHIFT;
@@ -113,11 +116,14 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct
pwm_device *pwm,
ctrl |= PWM_SW_UPDATE;
pwm_lpss_write(pwm, ctrl);
+ pm_runtime_put(chip->dev);
+
return 0;
}
static int pwm_lpss_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ pm_runtime_get_sync(chip->dev);
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
return 0;
}
@@ -125,6 +131,7 @@ static int pwm_lpss_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
static void pwm_lpss_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
+ pm_runtime_put(chip->dev);
}
static const struct pwm_ops pwm_lpss_ops = {
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
get_maintainer.pl and too many names (was: Re: [PATCH v2 0/2] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform)
Hi Joe,
On Mon, Oct 26, 2015 at 11:47 AM, Lee Jones wrote:
> On Mon, 26 Oct 2015, Geert Uytterhoeven wrote:
>> On Mon, Oct 26, 2015 at 9:27 AM, Masahiro Yamada
>> wrote:
>> > 2015-10-26 17:17 GMT+09:00 Lee Jones :
>> >>> This series adds two I2C controller drivers.
>> >>> (they are completely different IPs.)
>> >>>
>> >>> The first one is a very simple FIFO-less I2C controller,
>> >>> which is used on some older UniPhier SoCs.
>> >>>
>> >>> The other one is higher-performance I2C controller with TX/RX FIFO,
>> >>> used on newer UniPhier SoCs.
>> >>
>> >> And you have sent this to me because ... ?
>> >
>> >
>> > No special reason.
>> >
>> >
>> > I sent this series to linux-...@vger.kernel.org.
>> >
>> > I guess you were automatically CC'ed by scripts/get_maintainer.pl.
>> >
>> > Using get_maintainer.pl is a normal process when sending patches, I think.
>>
>> Please use common sense. It doesn't make much sense to CC everybody who
>> ever made a minor edit to an affected file.
>>
>> If checkpatch comes up with more than 5 names, this should ring a bell.
get_maintainer.pl, of course
> +1
Would it be difficult to let get_maintainer.pl print a warning if more than 5
names come up?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] reset: sti: Add support for resetting co-processors
Signed-off-by: Lee Jones
---
drivers/reset/sti/reset-stih407.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/reset/sti/reset-stih407.c
b/drivers/reset/sti/reset-stih407.c
index d83db5d7..5c2d68a 100644
--- a/drivers/reset/sti/reset-stih407.c
+++ b/drivers/reset/sti/reset-stih407.c
@@ -52,6 +52,7 @@ static const struct syscfg_reset_channel_data
stih407_powerdowns[] = {
};
/* Reset Generator control 0/1 */
+#define SYSCFG_5128 0x200
#define SYSCFG_51310x20c
#define SYSCFG_51320x210
@@ -96,6 +97,10 @@ static const struct syscfg_reset_channel_data
stih407_softresets[] = {
[STIH407_ERAM_HVA_SOFTRESET] = STIH407_SRST_CORE(SYSCFG_5132, 1),
[STIH407_LPM_SOFTRESET] = STIH407_SRST_SBC(SYSCFG_4002, 2),
[STIH407_KEYSCAN_SOFTRESET] = STIH407_SRST_LPM(LPM_SYSCFG_1, 8),
+ [STIH407_ST231_AUD_SOFTRESET] = STIH407_SRST_CORE(SYSCFG_5131, 26),
+ [STIH407_ST231_DMU_SOFTRESET] = STIH407_SRST_CORE(SYSCFG_5131, 27),
+ [STIH407_ST231_GP0_SOFTRESET] = STIH407_SRST_CORE(SYSCFG_5131, 28),
+ [STIH407_ST231_GP1_SOFTRESET] = STIH407_SRST_CORE(SYSCFG_5128, 2),
};
/* PicoPHY reset/control */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: STi: Add DT defines for co-processor reset lines
Signed-off-by: Lee Jones --- include/dt-bindings/reset-controller/stih407-resets.h | 4 1 file changed, 4 insertions(+) diff --git a/include/dt-bindings/reset-controller/stih407-resets.h b/include/dt-bindings/reset-controller/stih407-resets.h index 02d4328..4ab3a1c 100644 --- a/include/dt-bindings/reset-controller/stih407-resets.h +++ b/include/dt-bindings/reset-controller/stih407-resets.h @@ -52,6 +52,10 @@ #define STIH407_KEYSCAN_SOFTRESET 26 #define STIH407_USB2_PORT0_SOFTRESET 27 #define STIH407_USB2_PORT1_SOFTRESET 28 +#define STIH407_ST231_AUD_SOFTRESET29 +#define STIH407_ST231_DMU_SOFTRESET30 +#define STIH407_ST231_GP0_SOFTRESET31 +#define STIH407_ST231_GP1_SOFTRESET32 /* Picophy reset defines */ #define STIH407_PICOPHY0_RESET 0 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] reset: sti: Provide ops .status() call-back
Signed-off-by: Lee Jones
---
drivers/reset/sti/reset-syscfg.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/reset/sti/reset-syscfg.c b/drivers/reset/sti/reset-syscfg.c
index a145cc0..4453412 100644
--- a/drivers/reset/sti/reset-syscfg.c
+++ b/drivers/reset/sti/reset-syscfg.c
@@ -110,10 +110,33 @@ static int syscfg_reset_dev(struct reset_controller_dev
*rcdev,
return syscfg_reset_deassert(rcdev, idx);
}
+static int syscfg_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ struct syscfg_reset_controller *rst = to_syscfg_reset_controller(rcdev);
+ const struct syscfg_reset_channel *ch;
+ u32 ret_val = 0;
+ int err;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ ch = >channels[idx];
+ if (ch->ack)
+ err = regmap_field_read(ch->ack, _val);
+ else
+ err = regmap_field_read(ch->reset, _val);
+ if (err)
+ return err;
+
+ return rst->active_low ? !ret_val : !!ret_val;
+}
+
static struct reset_control_ops syscfg_reset_ops = {
.reset= syscfg_reset_dev,
.assert = syscfg_reset_assert,
.deassert = syscfg_reset_deassert,
+ .status = syscfg_reset_status,
};
static int syscfg_reset_controller_register(struct device *dev,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt-bindings: add document of mediatek efuse driver
On 26/10/15 10:23, Sascha Hauer wrote: On Mon, Oct 26, 2015 at 09:56:14AM +, Srinivas Kandagatla wrote: On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote: From: Andrew-CT Chen Add Mediatek MT8173 EFUSE Devicetree binding file Signed-off-by: Andrew-CT Chen Looks good to me, minor comment below. Will queue this for v4.5 once v4.4-rc1 is released. --- .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 ++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt new file mode 100644 index 000..92edc3d --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt @@ -0,0 +1,36 @@ += Mediatek MTK-EFUSE device tree bindings = + +This binding is intended to represent MTK-EFUSE which is found in most Mediatek SOCs. + +Required properties: +- compatible: should be "mediatek,mt8173-efuse" or "mediatek,mt8135-efuse" Can we make the compatible more generic for mediatek socs? Like "mediatek,efuse" Or are they different in each SOC? While we can add an additional "mediatek,efuse" compatible we should always add the most specific compatible first. Otherwise we cannot differentiate between SoCs later without changing the device tree. Yes, that’s correct. AFAIK, Ideally the driver should have more generic compatible string unless there is any SOC specific thing, and DT can still use the order of specific, generic compatible strings. If not we would end up adding compatible strings into the driver for every new SOC. --srini Sascha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > > >> Well, I'm not quite sure why exactly everyone is so focused on probing > >> here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that > > other issues aren't if you're not directly having problems. > > > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). > > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. Taking it a step further, if functional dependencies were understood at link-time then we could optimize link order as well. There are probably lots of optimizations if we only made the effort to understand these dependencies earlier. Constructing the device/resource dependency graph before the device ever boots sounds interesting to me. Regards, Mike > > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: adc: vf610_adc: Fix division by zero error
From: Sanchayan Maity Sent: Monday, October 19, 2015 3:43 PM >To: ji...@kernel.org >Cc: ste...@agner.ch; Duan Fugang-B38611; linux-...@vger.kernel.org; >linux->ker...@vger.kernel.org; Sanchayan Maity >Subject: [PATCH] iio: adc: vf610_adc: Fix division by zero error > >In case the fsl,adck-max-frequency property is not present in >the device tree, a division by zero error results during the >probe call on kernel boot (see below). This patch fixes it and >also restores device tree compatibility in case kernels are >booting with old device trees without this property specified. > >[1.063229] Division by zero in kernel. >[1.067152] CPU: 0 PID: 1 Comm: swapper Not tainted >4.3.0-rc5-00212-gcc88cef #37 >[1.074650] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) >[1.081135] Backtrace: >[1.083694] [<800134a4>] (dump_backtrace) from [<8001369c>] >(show_stack+0x18/0x1c) >[1.091340] r7:0008 r6:8e0ae210 r5: r4:8e299800 >[1.097146] [<80013684>] (show_stack) from [<80297b1c>] >(dump_stack+0x24/0x28) >[1.104483] [<80297af8>] (dump_stack) from [<80013608>] >(__div0+0x1c/0x20) >[1.111421] [<800135ec>] (__div0) from [<802968b4>] (Ldiv0+0x8/0x10) >[1.117865] [<80424350>] (vf610_adc_probe) from [<803153b4>] >(platform_drv_probe+0x4c/0xac) >[1.126311] r10: r9:8076a5ec r8: r7:fdfb >r6:807cc67c r5:8e0ae210 >[1.134319] r4:807f6c54 >[1.136915] [<80315368>] (platform_drv_probe) from [<803138bc>] >(driver_probe_device+0x20c/0x2f8) >[1.145882] r7:807cc67c r6: r5:8e0ae210 r4:807f6c54 >[1.151657] [<803136b0>] (driver_probe_device) from [<80313a3c>] >(__driver_attach+0x94/0x98) >[1.160190] r9:8076a5ec r8:0098 r7: r6:8e0ae244 >r5:807cc67c r4:8e0ae210 >[1.168112] [<803139a8>] (__driver_attach) from [<80311cb8>] >(bus_for_each_dev+0x70/0xa4) >[1.176383] r7: r6:803139a8 r5:807cc67c r4: >[1.182159] [<80311c48>] (bus_for_each_dev) from [<80313318>] >(driver_attach+0x24/0x28) >[1.190260] r6:807bb568 r5:8e2a5b00 r4:807cc67c >[1.194996] [<803132f4>] (driver_attach) from [<80312f50>] >(bus_add_driver+0x1a4/0x21c) >[1.203113] [<80312dac>] (bus_add_driver) from [<803142a8>] >(driver_register+0x80/0x100) >[1.211275] r7:8e2a7dc0 r6:807a8160 r5:80789e14 r4:807cc67c >[1.217075] [<80314228>] (driver_register) from [<803152f8>] >(__platform_driver_register+0x5c/0x64) >[1.226216] r5:80789e14 r4:807a8160 >[1.229877] [<8031529c>] (__platform_driver_register) from >[<80789e30>] (vf610_adc_driver_init+0x1c/0x20) >[1.239556] [<80789e14>] (vf610_adc_driver_init) from [<800095f8>] >(do_one_initcall+0x94/0x1dc) >[1.248365] [<80009564>] (do_one_initcall) from [<8076ae34>] >(kernel_init_freeable+0x13c/0x1e0) >[1.257155] r10:80794830 r9:8076a5ec r8:0098 r7:807d5780 >r6:807d5780 r5:0006 >[1.265153] r4:807a0ee8 >[1.267753] [<8076acf8>] (kernel_init_freeable) from [<80590ef0>] >(kernel_init+0x18/0xf0) >[1.276021] r10: r9: r8: r7: >r6: r5:80590ed8 >[1.284015] r4:807d5780 >[1.286615] [<80590ed8>] (kernel_init) from [<8000f878>] >(ret_from_fork+0x14/0x3c) >[1.294278] r5:80590ed8 r4: > >Signed-off-by: Sanchayan Maity Acked-by: Fugang Duan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How is jiffies upation while holding spinlock in Uniprocessor or SMP environment?
On Mon, Oct 26, 2015 at 12:19:31PM +0530, raghu MG wrote: > Hello, > I have couple of questions. > 1) In case of UP how is jiffies(timer) get updated while holding spin > lock using spinlock_irq_save? It isn't, and... > > 2)My understanding is in smp environment jiffies updation cannot be > done on processor holding spinlock irrespective of spinlock API.So > timer interrupt should be enabled across all cores in SoC. Imagine a > scenario in quad core processor where 4 cores are holding 4 different > spinlocks & how is the timer interrupt for jiffies handled? You can't rely on jiffies being updated while holding a spinlock. Expecting jiffies to update while holding a spinlock is a bug. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] clk: s2mps15: Add support for S2MPS15 clocks
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+ case S2MPS15X:
+ s2mps11_reg = S2MPS15_REG_RTC_BUF;
+ clks_init = s2mps15_clks_init;
+ break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
clks_init = s2mps11_clks_init;
@@ -292,6 +315,7 @@ static const struct platform_device_id s2mps11_clk_id[] = {
{ "s2mps11-clk", S2MPS11X},
{ "s2mps13-clk", S2MPS13X},
{ "s2mps14-clk", S2MPS14X},
+ { "s2mps15-clk", S2MPS15X},
{ "s5m8767-clk", S5M8767X},
{ },
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
RTC found in s2mps15 is almost same as one found in s2mps14.
This patch add required changes to enable s2mps15 rtc timer.
Signed-off-by: Alim Akhtar
---
drivers/rtc/rtc-s5m.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..ac3286a267ba 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
val &= S5M_ALARM0_STATUS;
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -253,6 +254,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
data &= ~S5M_RTC_TIME_EN_MASK;
break;
case S2MPS14X:
+ case S2MPS15X:
data |= S2MPS_RTC_RUDR_MASK;
break;
case S2MPS13X:
@@ -317,7 +319,8 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;
- if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+ if (info->device_type == S2MPS14X || info->device_type == S2MPS15X ||
+ info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +342,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +370,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +419,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
@@ -463,6 +469,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +515,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +556,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_tm_to_data(>time, data);
@@ -631,6 +640,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
@@ -679,6 +689,7 @@ static int s5m_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
regmap_cfg = _rtc_regmap_config;
@@ -805,6 +816,7 @@ static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc",S5M8767X },
{ "s2mps13-rtc",S2MPS13X },
{ "s2mps14-rtc",S2MPS14X },
+ { "s2mps15-rtc",S2MPS15X },
{ },
};
MODULE_DEVICE_TABLE(platform, s5m_rtc_id);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] regulator: s2mps11: add support for S2MPS15 regulators
From: Thomas Abraham
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
Reviewed-by: Krzysztof Kozlowski
---
drivers/regulator/Kconfig |4 +-
drivers/regulator/s2mps11.c | 135 ++-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff557be..3e3ee5b88b3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -588,10 +588,10 @@ config REGULATOR_S2MPA01
via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
config REGULATOR_S2MPS11
- tristate "Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage regulator"
+ tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage
+This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
output regulator via I2C bus. The chip is comprised of high efficient
Buck converters including Dual-Phase Buck converter, Buck-Boost
converter, various LDOs.
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 72fc3c32db49..12c59158552c 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
/* The highest number of possible regulators for supported devices. */
@@ -661,6 +662,133 @@ static const struct regulator_desc s2mps14_regulators[] =
{
S2MPS14_BUCK1235_START_SEL),
};
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) { \
+ .name = "LDO"#num,\
+ .id = S2MPS15_LDO##num, \
+ .ops= _reg_ldo_ops, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .n_voltages = S2MPS15_LDO_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .vsel_mask = S2MPS15_LDO_VSEL_MASK,\
+ .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) { \
+ .name = "BUCK"#num, \
+ .id = S2MPS15_BUCK##num,\
+ .ops= _reg_buck_ops,\
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .ramp_delay = 12500,\
+ .n_voltages = S2MPS15_BUCK_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+ .vsel_mask = S2MPS15_BUCK_VSEL_MASK, \
+ .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(100, 0xc, 0x38, 25000),
+};
+
+/* voltage range for s2mps15 LDO 2, 6, 14,
[PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+ case S2MPS15X:
+ regmap = _regmap_config;
+ break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = _irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = _irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = _irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..7443af6a4bba
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,161 @@
+/*
+ * s2mps15.h
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but
Re: [PATCH v2 0/2] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform
On Mon, 26 Oct 2015, Geert Uytterhoeven wrote: > On Mon, Oct 26, 2015 at 9:27 AM, Masahiro Yamada > wrote: > > 2015-10-26 17:17 GMT+09:00 Lee Jones : > >>> This series adds two I2C controller drivers. > >>> (they are completely different IPs.) > >>> > >>> The first one is a very simple FIFO-less I2C controller, > >>> which is used on some older UniPhier SoCs. > >>> > >>> The other one is higher-performance I2C controller with TX/RX FIFO, > >>> used on newer UniPhier SoCs. > >> > >> And you have sent this to me because ... ? > > > > > > No special reason. > > > > > > I sent this series to linux-...@vger.kernel.org. > > > > I guess you were automatically CC'ed by scripts/get_maintainer.pl. > > > > Using get_maintainer.pl is a normal process when sending patches, I think. > > Please use common sense. It doesn't make much sense to CC everybody who > ever made a minor edit to an affected file. > > If checkpatch comes up with more than 5 names, this should ring a bell. +1 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] mfd: sec: add S2MPS15 PMIC support
Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC. The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains 27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows programming these blocks via a I2C interface. This patch series adds initial support for LDO/Buck regulators of S2MPS15 PMIC. Changes since v1: * Added suggestion from Krzysztof [1]. * Added s2mps15's 32.768 clocks support. * Added s2mps15's rtc support. V1 of these patches (with a lesser features) were posted a year back, since then there is not much progress on this, this is my attempt to move things forward. [1]-> https://lkml.org/lkml/2014/10/14/67 This series is based on linux-next-20151022. This is tested on exynos7-espresso board. Alim Akhtar (2): clk: s2mps15: Add support for S2MPS15 clocks drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC Thomas Abraham (3): dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC mfd: sec: Add support for S2MPS15 PMIC regulator: s2mps11: add support for S2MPS15 regulators Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++- drivers/clk/Kconfig |5 +- drivers/clk/clk-s2mps11.c | 24 +++ drivers/mfd/sec-core.c| 31 drivers/mfd/sec-irq.c |8 + drivers/regulator/Kconfig |4 +- drivers/regulator/s2mps11.c | 135 - drivers/rtc/rtc-s5m.c | 14 +- include/linux/mfd/samsung/core.h |1 + include/linux/mfd/samsung/s2mps15.h | 161 + 10 files changed, 392 insertions(+), 14 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mps15.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL] Module preeption fix
The following changes since commit 1b647a166f07dcf08709c8606470f4b17a4aa11d: Merge tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma (2015-08-18 12:17:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/fixes-for-linus for you to fetch changes up to 275d7d44d802ef271a42dc87ac091a495ba72fc5: module: Fix locking in symbol_put_addr() (2015-08-24 10:37:01 +0930) Turns out we should have always been disabling preemption here; someone finally caught it thanks to Peter Z's additional checks. Cheers, Rusty. Peter Zijlstra (1): module: Fix locking in symbol_put_addr() kernel/module.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
