Some results (was: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs)
On Fri, Feb 20, 2015 at 10:58:15AM -0800, Andy Lutomirski wrote: > - /* Auto enable eagerfpu for xsaveopt */ > - if (cpu_has_xsaveopt && eagerfpu != DISABLE) > + /* Auto enable eagerfpu for everyone */ > + if (eagerfpu != DISABLE) > eagerfpu = ENABLE; So Mel did run some measurements with it on an old Intel and AMD box. Attached are netperf results from both. The Intel box is a quad core very similar to this one: http://ark.intel.com/products/28020/Intel-Xeon-Processor-5063-4M-Cache-3_20-GHz-1066-MHz-FSB netperf-udp-rr shows some impact of the eagerfpu patch which is outside of the noise level. netperf-tcp-rr not so much but eager is still a bit behind. The AMD box is an old K8 and results there look like eager is better :-) Not with all though - pipetest is worse. netperf-udp-rr is better at almost every data point and tcp-rr looks a bit useless with those high noise levels. As a summary, the patch has some, albeit small, impact. We would need more benchmarks. We have one speccpu run which is currently taking forever to finish... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- amd.tar.bz2 Description: Binary data intel.tar.bz2 Description: Binary data
Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling
On Wed, Feb 25, 2015 at 10:51:16AM -0500, Steven Rostedt wrote:
> > > +static void try_to_push_tasks(void *arg)
> > > +{
> > > + struct rt_rq *rt_rq = arg;
> > > + struct rq *rq, *next_rq;
> > > + int next_cpu = -1;
> > > + int next_prio = MAX_PRIO + 1;
> > > + int this_prio;
> > > + int src_prio;
> > > + int prio;
> > > + int this_cpu;
> > > + int success;
> > > + int cpu;
> > > +
> > > + /* Make sure we can see csd_cpu */
> > > + smp_rmb();
> >
> > As per the above, interrupt are serializing, this is not needed.
>
> Because entering an interrupt is a serializing point with other CPUs?
https://lkml.org/lkml/2009/2/18/145
So raising IPI vs receiving one should be serialized. Also, both APIs
(irq_work_queue_on() and smp_call_function_single()) should guarantee
this even if we didn't require the architecture to provide this.
> > > + /*
> > > + * We use the priority that determined to send to this CPU
> > > + * even if the priority for this CPU changed. This is used
> > > + * to determine what other CPUs to send to, to keep from
> > > + * doing a ping pong from each CPU.
> > > + */
> > > + this_prio = rt_rq->push_csd_prio;
> > > + src_prio = rt_rq->highest_prio.curr;
> >
> > Should we, at this point, not check if the condition that triggered the
> > pull request is still valid on our src cpu? No point in continuing our
> > IPI chain if the CPU we're looking for work for is no longer interested
> > in it.
>
> But how do we know that?
Dunno, I didn't say I really thought about it ;-)
> I added logic here to do exactly that, but then realized I need to keep
> track of too much information. The pull happens when the rq schedules a
> task of lower priority. That new task can still be an RT task. To know
> we do not need to do the pull, we need to keep track of what the
> original priority was.
>
> Hmm, but that said, we can add an optimization here and do this:
>
> if (src_prio <= this_prio)
> goto done;
>
> As "this_prio" is what we saw that we could pull. Thus, if the rq that
> is asking to do the pull schedules a task that is equal or higher in
> priority than the highest rq it sent a pull request for, then we do not
> need to continue this IPI.
>
> I'll add that.
Yeah something like that might work. You could also put in a stop flag,
which the IPI handler would check before propagating.
> > > + /* Make sure the next cpu is seen on remote CPU */
> > > + smp_mb();
> >
> > Not required,
>
> Because irq_work_queue_on() is a full barrier, right?
Lets say yes :-)
> > > +done:
> > > + rt_rq->push_csd_pending = 0;
> > > +
> > > + /* Now make sure the src CPU can see this update */
> > > + smp_wmb();
> >
> >
> > This barrier does not make sense either, for a wmb to make sense you
> > need two stores:
> >
> > x := 0, y := 0
> >
> > [S] x = 1
> > WMB
> > [S] y = 1
> >
> > And one would typically pair that with some loads like:
> >
> > [L] r1 = y
> > RMB
> > [L] r2 = x
> >
> > Which gives you the guarantee that if r1 is true, l2 must then also be
> > true.
> >
> > How in this case, there is no subsequent store.. therefore there is no
> > order and therefore there is no use of barriers.
>
> Actually, this is a speed up, but if exiting a irq handler is also a
> full barrier, then it is not needed.
Barrieres are _NEVER_ about speedups, they're either required or not.
> Here's what I have:
>
> rmb();
> if (!pending)
> send ipi;
>
>
> The above is to make sure we see the pending bit before making the
> decision. It would suck if it was already cleared, but because we never
> flushed the cache, that it always sees it as pending.
barriers are not about flushing store buffers (although some
implementations might do so we cannot rely on that in general).
The above rmb is entirely without function; as stated you need at least
two loads for an rmb to make sense.
> > > @@ -1775,6 +1946,15 @@ static int pull_rt_task(struct rq *this_
> > >*/
> > > smp_rmb();
> > >
> > > + /* Use local just in case a feature is switched in the middle of this */
> > > + if ((use_ipi = sched_feat(RT_PUSH_IPI))) {
> > > + /* Make sure the update to pending is visible here. */
> > > + smp_rmb();
> >
> > Another dubious barriers; the sched_feat() 'LOAD' cannot matter,
> > therefore this barries doesn't add any order over the previous rmb.
>
> I added it before noticing that there was an rmb() above :-)
>
> >
> > And again, you need two loads for an RMB to make sense, and a WMB (or
> > MB) on the other side with some STORE.
> >
> > I think this refers to the store of push_csd_pending at the tail of
> > try_to_push_task(), but as there's no order there, there cannot be any
> > here either.
>
> Right, but it's more of making sure that the state of the system is
> correct at that point than a correctness thing.
-ENOPARSE, there appear to be two different definitions of correct going
about in the above sentence.
Outside
Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver
Hi Richard, On 25/02/15 17:01, Richard Cochran wrote: On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote: Let me suggest another approach that stays in line with the existing frame work. Based on the device's limitations and your own example, it seems clear that the intended use case is synchronization for AVB applications using gPTP. Also, forgot to say, expose your clock as a PTP Hardware Clock (PHC). Regarding this last point, the actual counter that generates the timestamps is not part of the sniffer H/W module. Timestamps are provided to the sniffer externally in H/W by a different module. Apart of that there is not eg. a sniffer register to read the current counter value. I wonder if it should be the driver for the module where the counter belongs (called Event Timer in the Pistachio Soc) that should register the PHC. I need some more time to study your other suggestions regarding the PHY timestamping framework. Thanks, Richard Regards, Stathis -- 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/
Dead Kconfig Option OMAP4_ERRATA_I688
During the research for my masters thesis i came across the OMAP4_ERRATA_I688 option and realized, it is never possible to enable this option. The a62a6e98 commit added the "&& !ARCH_MULTIPLATFORM" dependency to disable this option for multiplatforms. However, because of enclosing dependencies, this option isn't available for non-MULTIPLATFORM configurations either. CONFIG_OMAP4_ERRATA_I688 is defined in the menu "TI OMAP/AM/DM/DRA Family" which depends on ARCH_MULTI_V6 || ARCH_MULTI_V7. (in arch/arm/mach-omap2/Kconfig) ARCH_MULTI_V6 and ARCH_MULTI_V7 however are defined in the menu "Multiple platform selection" which depends on ARCH_MULTIPLATFORM (in arch/arm/Kconfig) Which is a contradiction. There are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, either. The question is: Was disabling this option for non-MULTIPLATFORM configurations also intentional? i have added a minimal example of the problem. Kconfig.minimal Description: Binary data
Re: [PATCH] coresight-stm: adding driver for CoreSight STM component
On 5 February 2015 at 04:27, Paul Bolle wrote:
> On Wed, 2015-02-04 at 15:22 -0700, mathieu.poir...@linaro.org wrote:
>> From: Pratik Patel
>>
>> This driver adds support for the STM CoreSight IP block,
>> allowing any system compoment (HW or SW) to log and
>> aggregate messages via a single entity.
>>
>> The STM exposes an application defined number of channels
>> called stimulus port. Configuration is done using entries
>> in sysfs and channels made available to userspace via devfs.
>>
>> Signed-off-by: Pratik Patel
>> Signed-off-by: Mathieu Poirier
>
> This needs "coresight: Adding coresight support for arm64
> architecture" (https://lkml.org/lkml/2015/2/3/677 ) in order to get
> applied. Perhaps that's obvious to the people working on this.
>
> A few comments follow.
>
>> ---
>> .../ABI/testing/sysfs-bus-coresight-devices-stm| 62 ++
>> Documentation/trace/coresight.txt | 88 +-
>> drivers/coresight/Kconfig | 10 +
>> drivers/coresight/Makefile |1 +
>> drivers/coresight/coresight-stm.c | 1090
>>
>> include/linux/coresight-stm.h | 35 +
>> include/uapi/linux/coresight-stm.h | 23 +
>> 7 files changed, 1307 insertions(+), 2 deletions(-)
>> create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> create mode 100644 drivers/coresight/coresight-stm.c
>> create mode 100644 include/linux/coresight-stm.h
>> create mode 100644 include/uapi/linux/coresight-stm.h
>>
>>[...]
>> diff --git a/drivers/coresight/Kconfig b/drivers/coresight/Kconfig
>> index fc1f1ae7a49d..08806cc7d737 100644
>> --- a/drivers/coresight/Kconfig
>> +++ b/drivers/coresight/Kconfig
>> @@ -58,4 +58,14 @@ config CORESIGHT_SOURCE_ETM3X
>> which allows tracing the instructions that a processor is executing
>> This is primarily useful for instruction level tracing. Depending
>> the ETM version data tracing may also be available.
>> +
>> +config CORESIGHT_STM
>> + bool "CoreSight System Trace Macrocell driver"
>> + depends on (ARM && !(CPU_32v4 || CPU_32v4T)) || ARM64 || (64BIT &&
>> COMPILE_TEST)
>
> I'm _guessing_ that CPU_32v4 and CPU_32v4T are needed for the ldrd and
> strd assembler instructions. If that's right a next _guess_ would be
> that you also need to mention CPU_32v3 here.
Sorry for the late reply - I've been travelling.
After taking a closer at the Kconfig files I will indeed add CPU_32v3
to the condition. On the flip side I don't see what the advantage
would be to write !CPU_32v3 && !CPU_32v4 && !CPU_32v4T as you
suggested.
>
> Furthermore, this file is only sourced by arch/arm/Kconfig.debug and
> arch/arm64/Kconfig.debug. So 64BIT should always be equal to ARM64 and
> the
> || (64BIT && COMPILE_TEST)
>
> part shouldn't be needed, isn't it?
Correct.
>
>> + select CORESIGHT_LINKS_AND_SINKS
>> + help
>> + This driver provides support for hardware assisted software
>> + instrumentation based tracing. This is primarily used for
>> + logging useful software events or data coming from various entities
>> + in the system, possibly running different OSs
>> endif
>>[...]
>> diff --git a/drivers/coresight/coresight-stm.c
>> b/drivers/coresight/coresight-stm.c
>> new file mode 100644
>> index ..e59b0fe01d87
>> --- /dev/null
>> +++ b/drivers/coresight/coresight-stm.c
>> @@ -0,0 +1,1090 @@
>>[...]
>> +#ifndef CONFIG_64BIT
>> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
>> +{
>> + asm volatile("strd %1, %0"
>> + : "+Qo" (*(volatile u64 __force *)addr)
>> + : "r" (val));
>> +}
>> +
>> +static inline u64 __raw_readq(const volatile void __iomem *addr)
>> +{
>> + u64 val;
>> +
>> + asm volatile("ldrd %1, %0"
>> + : "+Qo" (*(volatile u64 __force *)addr),
>> +"=r" (val));
>> + return val;
>> +}
>> +
>> +#undef readq_relaxed
>> +#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
>> + __raw_readq(c)); __r; })
>
> I spotted no users of readq_relaxed. Is it needed?
>
>> +#undef writeq_relaxed
>> +#define writeq_relaxed(v, c) __raw_writeq((__force u64) cpu_to_le64(v), c)
>> +#endif
>> +
>> [...]
>
>> +static ssize_t entities_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> + ssize_t len;
>> +
>> + len = bitmap_scnprintf(buf, PAGE_SIZE, drvdata->entities,
>> +STM_ENTITY_MAX);
>> +
>
> bitmap_scnprintf is gone in current linux-next. I changed it to
> len = scnprintf(buf, PAGE_SIZE, "%*pb", STM_ENTITY_MAX,
> drvdata->entities);
>
> to get this file to compile. (On x86_64, that is, but please don't tell
> anybody!)
>
>
>
[PATCH] ARM: dts: am335x-boneblack: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
--
1.8.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] ARM: dts: warp: Add initial WaRP Board support
The WaRP Board is a Wearable Reference Plaform. The board features:
- Freescale i.MX6 SoloLite processor with 512MB of RAM
- Freescale FXOS8700CQ 6-axis Xtrinsic sensor
- Freescale Kinetis KL16 MCU
- Freescale Xtrinsic MMA955xL intelligent motion sensing platform
The board implements a hybrid architecture to address the evolving
needs of the wearables market. The platform consists of a main board
and an example daughtercard with the ability to add additional
daughtercards for different usage models.
For more information about the project, visit:
http://www.warpboard.org/
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/imx6sl-warp.dts | 154 ++
2 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx6sl-warp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..1b49d57 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -299,7 +299,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
- imx6sl-evk.dtb
+ imx6sl-evk.dtb \
+ imx6sl-warp.dtb
dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sabreauto.dtb \
imx6sx-sdb.dtb
diff --git a/arch/arm/boot/dts/imx6sl-warp.dts
b/arch/arm/boot/dts/imx6sl-warp.dts
new file mode 100644
index 000..dadb92f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sl-warp.dts
@@ -0,0 +1,154 @@
+/*
+ * Copyright 2014, 2015 O.S. Systems Software LTDA.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6sl.dtsi"
+
+/ {
+ model = "WaRP Board";
+ compatible = "warp,imx6sl-warp", "fsl,imx6sl";
+
+ memory {
+ reg = <0x8000 0x2000>;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 0 0>;
+ enable-active-high;
+ };
+
+ reg_usb_otg2_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "usb_otg2_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 2 0>;
+ enable-active-high;
+ };
+
+ reg_1p8v: regulator@2 {
+ compatible = "regulator-fixed";
+ reg = <2>;
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart3>;
+ status = "okay";
+};
+
+ {
+ vbus-supply = <_usb_otg1_vbus>;
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+ {
+ vbus-supply = <_usb_otg2_vbus>;
+ disable-over-current;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <_usdhc2>;
+ pinctrl-1 = <_usdhc2_100mhz>;
+ pinctrl-2 = <_usdhc2_200mhz>;
+ non-removable;
+ status = "okay";
+};
+
+ {
+ imx6sl-warp {
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x41b0b1
+ MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x41b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6SL_PAD_AUD_RXC__UART3_RX_DATA0x41b0b1
+ MX6SL_PAD_AUD_RXC__UART3_TX_DATA0x41b0b1
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6SL_PAD_SD2_CMD__SD2_CMD 0x417059
+ MX6SL_PAD_SD2_CLK__SD2_CLK 0x410059
+ MX6SL_PAD_SD2_DAT0__SD2_DATA0
Re: [PATCH 8/8 v2] ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug
Hi Roger,
On 25 Feb 2015 17:58, Roger Quadros wrote:
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
@@ -346,16 +395,22 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* @st_bit Start Bit
* @end_bit End Bit. Must be >= @st_bit.
* @nameDTS node name, w/o "gpmc,"
+ * @cd Clock Domain of timing parameter.
+ * @shift Parameter value left shifts @shift, which is then printed instead
of value.
* @raw Raw Format Option.
* raw format: gpmc,name =
* tick format: gpmc,name = /* x ticks */
* @noval Parameter values equal to 0 are not printed.
- * @shift Parameter value left shifts @shift, which is then printed instead
of value.
*
*/
-static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
- bool raw, bool noval, int shift,
- const char *name)
+static int get_gpmc_timing_reg(
+ /* timing specifiers */
+ int cs, int reg, int st_bit, int end_bit,
+ const char *name, const enum gpmc_clk_domain cd,
+ /* value transform */
+ int shift,
+ /* format specifiers */
+ bool raw, bool noval)
now that you are rearranging the parameters, "name" parameter should probably be
at the same position (or last) in get_gpmc_timing_reg() and
set_gpmc_timing_reg()?
Also clock domain (cd) position could be matched if possible.
I rearranged them primarily, because I wanted to group the specifiers
according to function, because I found it unnatural to add clock domain
to the end, when it's "more important" than the format specifiers.
set_gpmc_timing_reg are fine in that regard as it doesn't have format
specifiers.
+/**
+ * set_gpmc_timing_reg - set a single timing parameter for Chip Select Region.
+ * @cs Chip Select Region.
+ * @reg GPMC_CS_CONFIGn register offset.
+ * @st_bit Start Bit
+ * @end_bit End Bit. Must be >= @st_bit.
+ * @timeTiming parameter in ns.
+ * @cd Timing parameter clock domain.
+ * @nameTiming parameter name.
+ * @noteCaller is expected to have initialized CONFIG1 GPMCFCLKDIVIDER
@note is not a parameter.
Well no, note's a note. This is a doxygen-style comment, so tools should
put a note in the created documentation. Doxygen will put a box with
yellow background, for instance.
- pr_err("%s: GPMC error! CS%d: %s: %d ns, %d ticks > %d\n",
+ pr_err("%s: GPMC CS%d: %s %d ns, %d ticks > %d ticks\n",
any reason for removing the "error!" string?
It's already pr_err, the "error!" in-between "GPMC CS%d" made it hard to
read and there's a WARN after that statement in all cases, because a
child _must_ fail if a timing parameter constraint is broken.
Regards,
Robert
--
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] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 04:58:35PM +0100, Arnd Bergmann wrote: > On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote: > > This patch adds support for a half-word xchg() for ARM using ldrexh/strexh > > instructions. It also fixes an asm comment for __cmpxchg2. > > > > Currently using a half-word xchg() results in the following splat on an > > ARMv7 > > machine. > > > > [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2 > > [ 45.833324] [ cut here ] > > [ 45.837939] kernel BUG at > > /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727! > > > > Signed-off-by: Pranith Kumar > > Unfortunately, the BUG message seems incomplete, can you reproduce this > with CONFIG_DEBUG_BUGVERBOSE enabled? That isn't because CONFIG_DEBUG_BUGVERBOSE isn't set. It's because the message author decided that the remainder of the kernel bug message wasn't useful to report. After all, it's just a load of hex numbers and symbolic information. Who would want that junk. (Some people really don't get this: we print stuff from the kernel because it gives _us_ useful information to debug problems like this, but because they don't understand it themselves, they decide they can omit it from their bug reports...) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps 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/
Re: [PATCH] thermal: armada: read stable temp on Armada XP
Hi Tyler,
On 10/02/2015 23:50, Tyler Hall wrote:
> The current register being used to read the temperature returns a noisy value
> that is prone to variance and occasional outliers. The value in the thermal
> manager control and status register appears to have the same scale but much
> less variability.
>
> Add a "marvell,armadaxp-filtered-thermal" config which is set up to read from
> the Thermal Manager Control and Status Register at 0x184c4 rather than the
> Thermal Sensor Status Register at 0x182b0. The only difference is the
> temperature value shift. The original "marvell,armadaxp-thermal" is retained
> for device tree compatibility.
>
> This also fixes Armada XP clearing the disable bit in the wrong register. Bit > 0
> of the sensor register was being cleared but that bit is read-only. The
> disable
> bit doesn't seem to have an effect on the temperature sensor value, however,
> so
> this doesn't make a material difference.
>
> This problem was detected when running with the watchdog(8) daemon polling the
> thermal value. In one instance I observed a single read of over 200 degrees C
> which caused a spurious watchdog-initiated reboot. I have since observed
> individual outliers of ~20 degrees C. With this change and the corresponding
> device tree update, the temperature is much more stable.
I tried your patch on a OpenBlocks AX3. Without it I observed a temperature of
47°C:
# cat /sys/class/thermal/thermal_zone0/temp
47233
Whereas with your patch I got a temperature of 228°C!
# cat /sys/class/thermal/thermal_zone0/temp
228065
It should have an error somewhere in the values used.
>
> Signed-off-by: Tyler Hall
> ---
>
> If there's a better way to handle this than a separate binding, I'm open to
> suggestions.
Now that I thought more about it, I believe that it would make more
sens extending the current binding by adding a new optional named
register, indeed at the end we use the same sensor.
The binding would become:
thermal@182b0 {
compatible = "marvell,armadaxp-thermal";
reg = <0x182b0 0x4
0x184d0 0x4
0x184c4 0x4>;
reg-names = "sensor", "ctrl", "filt-sens";
status = "okay";
};
and then in the probe function we got something like
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "filt-sens");
if res {
priv->sensor = devm_ioremap_resource(>dev, res);
if (IS_ERR(priv->sensor))
return PTR_ERR(priv->sensor);
} else {
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->sensor = devm_ioremap_resource(>dev, res);
if (IS_ERR(priv->sensor))
return PTR_ERR(priv->sensor);
}
My concern was that by introducing a new compatible string we don't
prevent to have 2 thermal nodes for the same hardware.
>
> My conclusions about these registers are based on experimental data. The
> documentation is very sparse, but the Thermal Manager Control and Status
> Register looks like the preferred register given the way it is laid out in the
> public spec.
Ezequiel,
as you worked on this do you know why we used the Thermal Sensor Status Register
instead of the Thermal Manager Control and Status Register ?
My first guess is that the giving the name of the registers the 1st one made
more sens to use for a thermal sensor.
Thanks,
Gregory
>
> I have the small corresponding patch to the dts which I can submit separately.
>
> Thanks
> Tyler
>
> .../devicetree/bindings/thermal/armada-thermal.txt | 8
> drivers/thermal/armada_thermal.c| 13
> +
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> index 4698e0e..0d6a3f1 100644
> --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> @@ -7,6 +7,14 @@ Required properties:
> marvell,armada375-thermal
> marvell,armada380-thermal
> marvell,armadaxp-thermal
> + marvell,armadaxp-filtered-thermal
> +
> + Note: "marvell,armadaxp-filtered-thermal" is adjusted to read
> + the hardware-filtered value in the thermal manager
> + control/status register rather than the raw sensor value in the
> + thermal sensor status register. "marvell,armadaxp-thermal"
> + remains for backward compatibility. The sensor reg address must
> + also point to the appropriate register.
>
> - reg: Device's register space.
> Two entries are expected, see the examples below.
> diff --git a/drivers/thermal/armada_thermal.c
> b/drivers/thermal/armada_thermal.c
> index c2556cf..d3c2ad3 100644
> --- a/drivers/thermal/armada_thermal.c
> +++
Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver
On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote: > Let me suggest another approach that stays in line with the existing > frame work. Based on the device's limitations and your own example, > it seems clear that the intended use case is synchronization for AVB > applications using gPTP. Also, forgot to say, expose your clock as a PTP Hardware Clock (PHC). Thanks, Richard -- 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] ARM: Don't use complete() during __cpu_die
On Wed, Feb 25, 2015 at 11:47:48AM -0500, Nicolas Pitre wrote: > I completely agree with the r/w spinlock. Something like this ought to > be sufficient to make gic_raise_softirq() reentrant which is the issue > here, right? I've been stress-testing it for a while with no problems > so far. No. The issue is that we need a totally lockless way to raise an IPI during CPU hot-unplug, so we can raise an IPI in __cpu_die() to tell the __cpu_kill() code that it's safe to proceed to platform code. As soon sa that IPI has been received, the receiving CPU can decide to cut power to the dying CPU. So, it's entirely possible that power could be lost on the dying CPU before the unlock has become visible. It's a catch-22 - the reason we're sending the IPI is for synchronisation, but right now we need another form of synchronisation because we're using a form of synchronisation... We could just use the spin-and-poll solution instead of an IPI, but I really don't like that - when you see the complexity needed to re-initialise it each time, it quickly becomes very yucky because there is no well defined order between __cpu_die() and __cpu_kill() being called by the two respective CPUs. The last patch I saw doing that had multiple bits to indicate success and timeout, and rather a lot of complexity to recover from failures, and reinitialise state for a second CPU going down. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps 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/
Re: [PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs
On 24 February 2015 at 12:23, Ashwin Chaugule
wrote:
> On 20 February 2015 at 15:16, Stephen Boyd wrote:
>> On 02/20, Will Deacon wrote:
>>> On Fri, Feb 13, 2015 at 06:24:09PM +, Stephen Boyd wrote:
>>>
>>> > +static void scorpion_evt_setup(int idx, u32 config_base)
>>> > +{
>>> > + u32 val;
>>> > + u32 mask;
>>> > + u32 vval, fval;
>>> > + unsigned int region;
>>> > + unsigned int group;
>>> > + unsigned int code;
>>> > + unsigned int group_shift;
>>> > + bool venum_event;
>>> > +
>>> > + krait_decode_event(config_base, , , ,
>>> > _event,
>>> > + NULL);
>>> > +
>>> > + group_shift = group * 8;
>>> > + mask = 0xff << group_shift;
>>> > +
>>> > + /* Configure evtsel for the region and group */
>>> > + if (venum_event)
>>> > + val = SCORPION_VLPM_GROUP0;
>>> > + else
>>> > + val = scorpion_get_pmresrn_event(region);
>>> > + val += group;
>>> > + /* Mix in mode-exclusion bits */
>>> > + val |= config_base & (ARMV7_EXCLUDE_USER | ARMV7_EXCLUDE_PL1);
>>> > + armv7_pmnc_write_evtsel(idx, val);
>>> > +
>>> > + asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
>>>
>>> What's this guy doing?
>>
>> This is the same as Krait. It's clearing some implementation
>> defined register. From what I can tell it's a per-event register
>> (i.e. PMSELR decides which event this register write actually
>> affects) and we do this here to reset this register to some
>> defined value, zero. Otherwise the reset value of this register
>> is UNPREDICTABLE and that would be bad. I think we might be able
>> to move it to the pmu reset path, but I don't know. Ashwin?
>
Its a count control register (PMxEVCNTCR). Theres various conditions
on which you can select when to start/stop counting. e.g. start when
another counter register overflows. Setting it to 0 was the
recommended default value on Scorpions and Kraits. Reset value is
unpredictable. So, just need to make sure this is set every time a
counter is setup. Will that still work if this is moved to the reset
path?
Cheers,
Ashwin.
--
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] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wednesday 25 February 2015 11:11:28 Pranith Kumar wrote:
> On Wed, Feb 25, 2015 at 10:58 AM, Arnd Bergmann wrote:
> > On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
> >> This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
> >> instructions. It also fixes an asm comment for __cmpxchg2.
> >>
> >> Currently using a half-word xchg() results in the following splat on an
> >> ARMv7
> >> machine.
> >>
> >> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
> >> [ 45.833324] [ cut here ]
> >> [ 45.837939] kernel BUG at
> >> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
> >>
> >> Signed-off-by: Pranith Kumar
> >
> > Unfortunately, the BUG message seems incomplete, can you reproduce this
> > with CONFIG_DEBUG_BUGVERBOSE enabled?
>
> The bug here is in a module caused when xchg() was used on uint16_t
> variable. It is caused by the __bad_xchg() for 2 byte swap.
>
> More information:
> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
> [ 45.833324] [ cut here ]
> [ 45.837939] kernel BUG at
> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
> [ 45.846450] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [ 45.852275] Modules linked in: test(O+) nvhost_vi
> [ 45.857012] CPU: 0 PID: 1848 Comm: insmod Tainted: G O
> 3.10.24-g6a2d13a #1
> [ 45.864744] task: ee406580 ti: eb18c000 task.ti: eb18c000
> [ 45.870141] PC is at __bad_xchg+0x24/0x28
> [ 45.874146] LR is at __bad_xchg+0x24/0x28
I'm more interested in the backtrace here, it's possible we should fix the
driver instead.
> >> arch/arm/include/asm/cmpxchg.h | 18 +-
> >> 1 file changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/include/asm/cmpxchg.h
> >> b/arch/arm/include/asm/cmpxchg.h
> >> index abb2c37..9505cca 100644
> >> --- a/arch/arm/include/asm/cmpxchg.h
> >> +++ b/arch/arm/include/asm/cmpxchg.h
> >> @@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x,
> >> volatile void *ptr, int size
> >> : "r" (x), "r" (ptr)
> >> : "memory", "cc");
> >> break;
> >> + case 2:
> >> + asm volatile("@ __xchg2\n"
> >> + "1: ldrexh %0, [%3]\n"
> >> + " strexh %1, %2, [%3]\n"
> >> + " teq %1, #0\n"
> >> + " bne 1b"
> >> + : "=" (ret), "=" (tmp)
> >> + : "r" (x), "r" (ptr)
> >> + : "memory", "cc");
> >> + break;
> >> case 4:
> >> asm volatile("@ __xchg4\n"
> >> "1: ldrex %0, [%3]\n"
> >
> > Does this work on all ARMv6 or just ARMv6k?
> >
>
> ldrexh/strexh is being used in cmpxchg() in the same file in a similar
> manner, and the comment there says that it works for all ARCH >=
> ARMv6k, so not ARMv6 I guess.
Ok, then you need to put the same check in __xchg too. I'm not sure
about the 1-byte case here, because that is already used in ARMv6
__xchg.
Arnd
--
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 8/8 v2] ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug
Robert,
On 24/02/15 22:05, Robert ABEL wrote:
> The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
> even though the access is defined as asynchronous, and no GPMC_CLK clock
> is provided to the external device. Still, GPMCFCLKDIVIDER is used as a
> divider
> for the GPMC clock, so it must be programmed to define the
> correct WAITMONITORINGTIME delay.
>
> This patch correctly computes WAITMONITORINGTIME in GPMC_CLK cycles instead
> of GPMC_FCLK cycles,
> both during programming (gpmc_cs_set_timings) and during retrieval
> (gpmc_cs_show_timings).
>
> Signed-off-by: Robert ABEL
> ---
> drivers/memory/omap-gpmc.c | 125
> +++--
> 1 file changed, 99 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 9cf8d21..6591991 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -170,6 +170,11 @@
> */
> #define GPMC_NR_IRQ 2
>
> +enum gpmc_clk_domain {
> + GPMC_CD_FCLK,
> + GPMC_CD_CLK
> +};
> +
> struct gpmc_cs_data {
> const char *name;
>
> @@ -268,16 +273,55 @@ static unsigned long gpmc_get_fclk_period(void)
> return rate;
> }
>
> -static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
> +/**
> + * gpmc_get_clk_period - get period of selected clock domain in ps
> + * @cs Chip Select Region.
> + * @cd Clock Domain.
> + *
> + * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
> + * prior to calling this function with GPMC_CD_CLK.
> + *
> + */
> +static unsigned long gpmc_get_clk_period(int cs, enum gpmc_clk_domain cd)
> +{
> +
> + unsigned long tick_ps = gpmc_get_fclk_period();
> + u32 l;
> + int div;
> +
> + switch (cd) {
> + case GPMC_CD_CLK:
> + /* get current clk divider */
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> + div = (l & 0x03) + 1;
> + /* get GPMC_CLK period */
> + tick_ps *= div;
> + break;
> + case GPMC_CD_FCLK:
> + /* FALL-THROUGH */
> + default:
> + break;
> + }
> +
> + return tick_ps;
> +
> +}
> +
> +static unsigned int gpmc_ns_to_clk_ticks(unsigned int time_ns, int cs, enum
> gpmc_clk_domain cd)
> {
> unsigned long tick_ps;
>
> /* Calculate in picosecs to yield more exact results */
> - tick_ps = gpmc_get_fclk_period();
> + tick_ps = gpmc_get_clk_period(cs, cd);
>
> return (time_ns * 1000 + tick_ps - 1) / tick_ps;
> }
>
> +static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
> +{
> + return gpmc_ns_to_clk_ticks(time_ns, /* any CS */ 0, GPMC_CD_FCLK);
> +}
> +
> static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
> {
> unsigned long tick_ps;
> @@ -288,9 +332,14 @@ static unsigned int gpmc_ps_to_ticks(unsigned int
> time_ps)
> return (time_ps + tick_ps - 1) / tick_ps;
> }
>
> +unsigned int gpmc_clk_ticks_to_ns(unsigned ticks, int cs, enum
> gpmc_clk_domain cd)
> +{
> + return ticks * gpmc_get_clk_period(cs, cd) / 1000;
> +}
> +
> unsigned int gpmc_ticks_to_ns(unsigned int ticks)
> {
> - return ticks * gpmc_get_fclk_period() / 1000;
> + return gpmc_clk_ticks_to_ns(ticks, /* any CS */ 0, GPMC_CD_FCLK);
> }
>
> static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
> @@ -346,16 +395,22 @@ static void gpmc_cs_bool_timings(int cs, const struct
> gpmc_bool_timings *p)
> * @st_bit Start Bit
> * @end_bit End Bit. Must be >= @st_bit.
> * @nameDTS node name, w/o "gpmc,"
> + * @cd Clock Domain of timing parameter.
> + * @shift Parameter value left shifts @shift, which is then printed
> instead of value.
> * @raw Raw Format Option.
> * raw format: gpmc,name =
> * tick format: gpmc,name = /* x ticks */
> * @noval Parameter values equal to 0 are not printed.
> - * @shift Parameter value left shifts @shift, which is then printed
> instead of value.
> *
> */
> -static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
> -bool raw, bool noval, int shift,
> -const char *name)
> +static int get_gpmc_timing_reg(
> + /* timing specifiers */
> + int cs, int reg, int st_bit, int end_bit,
> + const char *name, const enum gpmc_clk_domain cd,
> + /* value transform */
> + int shift,
> + /* format specifiers */
> + bool raw, bool noval)
now that you are rearranging the parameters, "name" parameter should probably be
at the same position (or last) in get_gpmc_timing_reg() and
set_gpmc_timing_reg()?
Also clock domain (cd) position could be matched if possible.
> {
> u32 l;
> int nr_bits;
> @@ -373,7 +428,7 @@ static int get_gpmc_timing_reg(int cs, int reg, int
> st_bit, int end_bit,
> /* DTS tick format for timings in ns */
> unsigned int time_ns;
>
> - time_ns =
Re: [PATCH 1/2] Drivers: hv: hv_balloon: report offline pages as being used
KY Srinivasan writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Thursday, February 19, 2015 8:27 AM
>> To: KY Srinivasan; de...@linuxdriverproject.org
>> Cc: Haiyang Zhang; linux-kernel@vger.kernel.org; Dexuan Cui
>> Subject: [PATCH 1/2] Drivers: hv: hv_balloon: report offline pages as being
>> used
>>
>> When hot-added memory pages are not brought online or when some
>> memory blocks
>> are sent offline the subsequent ballooning process kills the guest with OOM
>> killer. This happens as we don't report these pages as neither used nor free
>> and apparently host algorythm considers them as being unused. Keep track
>> of
>> all online/offline operations and report all currently offline pages as being
>> used so host won't try to balloon them out.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/hv_balloon.c | 33 -
>> 1 file changed, 24 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>> index a095b70..e4b4454 100644
>> --- a/drivers/hv/hv_balloon.c
>> +++ b/drivers/hv/hv_balloon.c
>> @@ -503,6 +503,8 @@ struct hv_dynmem_device {
>> * Number of pages we have currently ballooned out.
>> */
>> unsigned int num_pages_ballooned;
>> +unsigned int num_pages_onlined;
>> +unsigned int num_pages_added;
>>
>> /*
>> * State to manage the ballooning (up) operation.
>> @@ -556,12 +558,15 @@ static void post_status(struct hv_dynmem_device
>> *dm);
>> static int hv_memory_notifier(struct notifier_block *nb, unsigned long val,
>>void *v)
>> {
>> +struct memory_notify *mem = (struct memory_notify *)v;
>> +
>> switch (val) {
>> case MEM_GOING_ONLINE:
>> mutex_lock(_device.ha_region_mutex);
>> break;
>>
>> case MEM_ONLINE:
>> +dm_device.num_pages_onlined += mem->nr_pages;
>> case MEM_CANCEL_ONLINE:
>
> Why are we not adjusting num_pages_onlined when we cancel the online
> Operation.
Because we didn't increase the number yet.
To my understanding, events come in the following order:
1) MEM_GOING_ONLINE - we just take the lock
2) MEM_ONLINE - and we increase nr_pages and drop the lock
or
MEM_CANCEL_ONLINE - we just drop the lock (mem never was online so
nr_pages wasn't increased)
3) MEM_GOING_OFFLINE - we do nothing
4) MEM_OFFLINE - and we decrease nr_pages
or
MEM_CANCEL_OFFLINE - we do nothing (mem is still online, no need to
adjust nr_pages)
>
> K. Y
--
Vitaly
--
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 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"
On 02/25/2015 01:37 PM, Andrey Wagin wrote: > Hello Denys, > > My test vm doesn't boot with this patch. Could you help to investigate > this issue? > > I have attached a kernel config and console log. > > [2.508252] traps: systemd-cgroups[380] general protection ip:7f68ad096028 > sp:7fffba298af8 error:0 in ld-2.18.so[7f68ad07e000+2][ OK > [2.600179] traps: systemd-cgroups[384] general protection ip:7f11b9a9c028 > sp:7fff4420f978 error:0 in ld-2.18.so[7f11b9a84000+2] > [2.743790] traps: systemd-cgroups[392] general protection ip:7f7f40a44028 > sp:7fffe1c1b8b8 error:0 in ld-2.18.so[7f7f40a2c000+2] > [2.754576] traps: systemd-cgroups[393] general protection ip:7fd1314bd028 > sp:776ecc88 error:0 in ld-2.18.so[7fd1314a5000+2] > [2.765343] traps: systemd-cgroups[396] general protection ip:7ff4537b7028 > sp:7fff05902378 error:0 in ld-2.18.so[7ff45379f000+2] > [2.798782] traps: systemd-cgroups[399] general protection ip:7f4d5bc9c028 > sp:7fff35cb3a48 error:0 in ld-2.18.so[7f4d5bc84000+2] These SEGVs are always at the same location within ld-2.18.so: (ip - load_address) is always 0x18028. For Sabrine's case, SEGVing address in ld-2.21.so also the same all the time: 0x184f8. Please send me your ld-2.18.so / ld-2.21.so files. -- 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] perf, tools, record: Support recording running/enabled time
On 2/24/15 4:13 PM, Andi Kleen wrote:
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -241,6 +241,9 @@ Capture machine state (registers) at interrupt, i.e., on
counter overflows for
each sample. List of captured registers depends on the architecture. This
option
is off by default.
+--running::
+Record running and enabled time for read events (:S)
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index d0d02a8..4fdad06 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -839,6 +839,8 @@ struct option __record_options[] = {
"use per-thread mmaps"),
OPT_BOOLEAN('I', "intr-regs", _intr_regs,
"Sample machine registers on interrupt"),
+ OPT_BOOLEAN(0, "running-time", _time,
+ "Record running/enabled time of read (:S) events"),
OPT_END()
Documentation differs from option in the record command.
David
--
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] ARM: Don't use complete() during __cpu_die
On Wed, 25 Feb 2015, Russell King - ARM Linux wrote: > On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote: > > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote: > > > Works for me, assuming no hidden uses of RCU in the IPI code. ;-) > > > > Sigh... I kind'a new it wouldn't be this simple. The gic code which > > actually raises the IPI takes a raw spinlock, so it's not going to be > > this simple - there's a small theoretical window where we have taken > > this lock, written the register to send the IPI, and then dropped the > > lock - the update to the lock to release it could get lost if the > > CPU power is quickly cut at that point. > > > > Also, we _do_ need the second cache flush in place to ensure that the > > unlock is seen to other CPUs. > > It's time to start discussing this problem again now that we're the > other side of the merge window. > > I've been thinking about the lock in the GIC code. Do we actually need > this lock in gic_raise_softirq(), or could we move this lock into the > higher level code? It could be a rw lock as you say. > Let's consider the bL switcher. > > I think the bL switcher is racy wrt CPU hotplug at the moment. What > happens if we're sleeping in wait_for_completion(_alive) and > CPU hotplug unplugs the CPU outgoing CPU? What protects us against > this scenario? I can't see anything in bL_switch_to() which ensures > that CPU hotplug can't run. True. The actual switch would then be suspended in mid air until that CPU is plugged back in. The inbound CPU would wait at mcpm_entry_gated until the outbound CPU comes back to open the gate. There wouldn't be much harm besides the minor fact that the inbound CPU would be wasting more power while looping on a WFE compared to its previously disabled state. I'm still debating if this is worth fixing. > Let's assume that this rather glaring bug has been fixed, and that CPU > hotplug can't run in parallel with the bL switcher (and hence > gic_migrate_target() can't run concurrently with a CPU being taken > offline.) I'm still trying to figure out how this might happen. At the point where gic_migrate_target() is called, IRQs are disabled and nothing can prevent the switch from happening anymore. Any IPI attempting to stop that CPU for hotplug would be pending until the inbound CPU eventually honors it. > If we have that guarantee, then we don't need to take a lock when sending > the completion IPI - we would know that while a CPU is being taken down, > the bL switcher could not run. What we now need is a lock-less way to > raise an IPI. > > Now, is the locking between the normal IPI paths and the bL switcher > something that is specific to the interrupt controller, or should generic > code care about it? I think it's something generic code should care about > - and I believe that would make life a little easier. Well... The only reason for having a lock there is to ensure that no IPIs are sent to the outbound CPU after gic_cpu_map[] has been modified and pending IPIs on the outbound CPU have been migrated to the inbound CPU. I think this is pretty specific to the GIC driver code. If there was a way for gic_migrate_target() to be sure no other CPUs are using the old gic_cpu_map value any longer then no lock would be needed in gic_raise_softirq(). The code in gic_migrate_target() would only have to wait until it is safe to migrate pending IPIs on the outbound CPU without missing any. > The current bL switcher idea is to bring the new CPU up, disable IRQs > and FIQs on the outgoing CPU, change the IRQ/IPI targets, then read > any pending SGIs and raise them on the new CPU. But what about any > pending SPIs? These look like they could be lost. SPIs are raised and cleared independently of their distribution config. So the only thing that gic_migrate_target() has to do is to disable the distribution target for the outbound CPU and enable the target for the inbound CPU. This way unserviced IRQs become pending on the outbound CPU automatically. The only other part that plays with targets is gic_set_affinity() and irq_controller_lock protects against concurrency here. > How about this for an idea instead - the bL switcher code: > > - brings the new CPU online. > - disables IRQs and FIQs. > - takes the IPI lock, which prevents new IPIs being raised. > - re-targets IRQs and IPIs onto the new CPU. > - releases the IPI lock. But aren't we trying to get rid of that IPI lock to start with? I'd personally love to remove it -- it's been nagging me since I initially added it. > - re-enables IRQs and FIQs. > - polls the IRQ controller to wait for any remaining IRQs and IPIs > to be delivered. Poll for how long? How can you be sure no other CPU is in the process of targetting an IPI to the outbound CPU? With things like the FIQ debugger coming to mainline or even JTAG-based debuggers, this could represent an indetermined amount of time if the
Re: [PATCH v6 1/5] mfd: max77843: Add max77843 MFD driver core driver
On Tue, 24 Feb 2015, Jaewon Kim wrote:
> This patch adds MAX77843 core/irq driver to support PMIC,
> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
> LED and Haptic device.
>
> Cc: Lee Jones
> Signed-off-by: Jaewon Kim
> Signed-off-by: Beomho Seo
> ---
> drivers/mfd/Kconfig | 14 ++
> drivers/mfd/Makefile |1 +
> drivers/mfd/max77843.c | 248 +++
> include/linux/mfd/max77843-private.h | 454
> ++
> 4 files changed, 717 insertions(+)
> create mode 100644 drivers/mfd/max77843.c
> create mode 100644 include/linux/mfd/max77843-private.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 38356e3..f2fd5e5 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -455,6 +455,20 @@ config MFD_MAX77693
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_MAX77843
> + bool "Maxim Semiconductor MAX77843 PMIC Support"
> + depends on I2C=y
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + help
> + Say yes here to add support for Maxim Semiconductor MAX77843.
> + This is companion Power Management IC with LEDs, Haptic, Charger,
> + Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
> + This driver provides common support for accessing the device;
> + additional drivers must be enabled in order to use the functionality
> + of the device.
> +
> config MFD_MAX8907
> tristate "Maxim Semiconductor MAX8907 PMIC Support"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 19f3d74..b8ac555 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9150) += da9150-core.o
> obj-$(CONFIG_MFD_MAX14577) += max14577.o
> obj-$(CONFIG_MFD_MAX77686) += max77686.o
> obj-$(CONFIG_MFD_MAX77693) += max77693.o
> +obj-$(CONFIG_MFD_MAX77843) += max77843.o
> obj-$(CONFIG_MFD_MAX8907)+= max8907.o
> max8925-objs := max8925-core.o max8925-i2c.o
> obj-$(CONFIG_MFD_MAX8925)+= max8925.o
> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> new file mode 100644
> index 000..2d8b3cc
> --- /dev/null
> +++ b/drivers/mfd/max77843.c
> @@ -0,0 +1,248 @@
> +/*
> + * max77843.c - MFD core driver for the Maxim MAX77843
Please remove the filename.
> + * Copyright (C) 2015 Samsung Electronics
> + * Author: Jaewon Kim
> + * Author: Beomho Seo
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct mfd_cell max77843_devs[] = {
> + {
> + .name = "max77843-muic",
> + .of_compatible = "maxim,max77843-muic",
> + }, {
> + .name = "max77843-regulator",
> + .of_compatible = "maxim,max77843-regulator",
> + }, {
> + .name = "max77843-charger",
> + .of_compatible = "maxim,max77843-charger"
> + }, {
> + .name = "max77843-fuelgauge",
> + .of_compatible = "maxim,max77843-fuelgauge",
> + }, {
> + .name = "max77843-haptic",
> + .of_compatible = "maxim,max77843-haptic",
> + },
> +};
> +
> +static const struct regmap_config max77843_charger_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MAX77843_CHG_REG_END,
> +};
> +
> +static const struct regmap_config max77843_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MAX77843_SYS_REG_END,
> +};
> +
> +static const struct regmap_irq max77843_irqs[] = {
> + /* TOPSYS interrupts */
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
> +};
> +
> +static const struct regmap_irq_chip max77843_irq_chip = {
> + .name = "max77843",
> + .status_base= MAX77843_SYS_REG_SYSINTSRC,
> + .mask_base = MAX77843_SYS_REG_SYSINTMASK,
> + .mask_invert= false,
> + .num_regs = 1,
> + .irqs = max77843_irqs,
> + .num_irqs = ARRAY_SIZE(max77843_irqs),
> +};
> +
> +/* Charger and Charger regulator use same regmap. */
> +static int max77843_chg_init(struct max77843 *max77843)
> +{
> + int ret;
> +
> + max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
> + if (!max77843->i2c_chg) {
Re: [PATCH 3.18 00/20] 3.18.8-stable review
On Tue, Feb 24, 2015 at 06:10:15PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.8 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Feb 27 02:08:41 UTC 2015. > Anything received after that time might be too late. > Build results: total: 121 pass: 121 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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/2] HID: wacom: add full support of the Wacom Bamboo PAD
The stylus of this device works just fine out of the box.
The touch is seen by default as a mouse with relative events and some
gestures.
The wireless and the wired version have slightly different firmwares, but
the debug mode 2 on the feature 2 is common to the 2 devices. In this mode,
all the reports are emitted through the debug interface (pen, raw touch
and mouse emulation), so we have to re-route manually the events.
We keep the Pen interface as a HID_GENERIC one because it works, and only
parse the raw touches while discarding the mouse emulation & gestures.
Switching the default in raw mode allows us to have a consistent user
experience accross all the multitouch touchpads (and enable the touch part
of the devices).
Note that the buttons of this devices are reported through the touch
interface. There is no 'Pad' interface. It seemed more natural to have
the BTN_LEFT and BTN_RIGHT reported with the touch because they are
placed under the touch interface and it looks like they belong to the
touch part.
Tested-by: Josep Sanchez Ferreres
Signed-off-by: Benjamin Tissoires
---
drivers/hid/wacom_sys.c | 24
drivers/hid/wacom_wac.c | 100
drivers/hid/wacom_wac.h | 5 +++
3 files changed, 129 insertions(+)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index b3c2395..957699f 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -406,6 +406,9 @@ static int wacom_query_tablet_data(struct hid_device *hdev,
else if (features->type == WACOM_27QHDT) {
return wacom_set_device_mode(hdev, 131, 3, 2);
}
+ else if (features->type == BAMBOO_PAD) {
+ return wacom_set_device_mode(hdev, 2, 2, 2);
+ }
} else if (features->device_type == BTN_TOOL_PEN) {
if (features->type <= BAMBOO_PT && features->type != WIRELESS) {
return wacom_set_device_mode(hdev, 2, 2, 2);
@@ -1425,6 +1428,21 @@ static int wacom_probe(struct hid_device *hdev,
goto fail_allocate_inputs;
}
+ /*
+* Bamboo Pad has a generic hid handling for the Pen, and we switch it
+* into debug mode for the touch part.
+* We ignore the other interfaces.
+*/
+ if (features->type == BAMBOO_PAD) {
+ if (features->pktlen == WACOM_PKGLEN_PENABLED) {
+ features->type = HID_GENERIC;
+ } else if ((features->pktlen != WACOM_PKGLEN_BPAD_TOUCH) &&
+ (features->pktlen != WACOM_PKGLEN_BPAD_TOUCH_USB)) {
+ error = -ENODEV;
+ goto fail_shared_data;
+ }
+ }
+
/* set the default size in case we do not get them from hid */
wacom_set_default_phy(features);
@@ -1459,6 +1477,12 @@ static int wacom_probe(struct hid_device *hdev,
features->y_max = 4096;
}
+ /*
+* Same thing for Bamboo PAD
+*/
+ if (features->type == BAMBOO_PAD)
+ features->device_type = BTN_TOOL_FINGER;
+
if (hdev->bus == BUS_BLUETOOTH)
features->quirks |= WACOM_QUIRK_BATTERY;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 16e8d28..ff693a6 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1826,6 +1826,87 @@ static int wacom_bpt_irq(struct wacom_wac *wacom, size_t
len)
return 0;
}
+static void wacom_bamboo_pad_pen_event(struct wacom_wac *wacom,
+ unsigned char *data)
+{
+ unsigned char prefix;
+
+ /*
+* We need to reroute the event from the debug interface to the
+* pen interface.
+* We need to add the report ID to the actual pen report, so we
+* temporary overwrite the first byte to prevent having to kzalloc/kfree
+* and memcpy the report.
+*/
+ prefix = data[0];
+ data[0] = WACOM_REPORT_BPAD_PEN;
+
+ /*
+* actually reroute the event.
+* No need to check if wacom->shared->pen is valid, hid_input_report()
+* will check for us.
+*/
+ hid_input_report(wacom->shared->pen, HID_INPUT_REPORT, data,
+WACOM_PKGLEN_PENABLED, 1);
+
+ data[0] = prefix;
+}
+
+static int wacom_bamboo_pad_touch_event(struct wacom_wac *wacom,
+ unsigned char *data)
+{
+ struct input_dev *input = wacom->input;
+ unsigned char *finger_data, prefix;
+ unsigned id;
+ int x, y;
+ bool valid;
+
+ prefix = data[0];
+
+ for (id = 0; id < wacom->features.touch_max; id++) {
+ valid = !!(prefix & BIT(id)) &&
+ !wacom->shared->stylus_in_proximity;
+
+ input_mt_slot(input, id);
+ input_mt_report_slot_state(input, MT_TOOL_FINGER, valid);
+
+ if (!valid)
[PATCH v2 1/2] HID: wacom: store the hid_device pointers of the sibling devices
The Bamboo PAD in debug mode needs to re-route events from the debug
interface to the Pen interface. This can be easily done with
hid_input_report(), but that means that we need to keep a reference to
the various hid_devices.
There should be only one touch and one pen interface per physical tablet,
so there is no need to keep a list of hid-devices, plain pointers are
sufficient.
Tested-by: Josep Sanchez Ferreres
Signed-off-by: Benjamin Tissoires
---
drivers/hid/wacom_sys.c | 25 +++--
drivers/hid/wacom_wac.h | 2 ++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index f0568a7..b3c2395 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -524,6 +524,11 @@ static int wacom_add_shared_data(struct hid_device *hdev)
wacom_wac->shared = >shared;
+ if (wacom_wac->features.device_type == BTN_TOOL_FINGER)
+ wacom_wac->shared->touch = hdev;
+ else if (wacom_wac->features.device_type == BTN_TOOL_PEN)
+ wacom_wac->shared->pen = hdev;
+
out:
mutex_unlock(_udev_list_lock);
return retval;
@@ -541,14 +546,22 @@ static void wacom_release_shared_data(struct kref *kref)
kfree(data);
}
-static void wacom_remove_shared_data(struct wacom_wac *wacom)
+static void wacom_remove_shared_data(struct wacom *wacom)
{
struct wacom_hdev_data *data;
+ struct wacom_wac *wacom_wac = >wacom_wac;
+
+ if (wacom_wac->shared) {
+ data = container_of(wacom_wac->shared, struct wacom_hdev_data,
+ shared);
+
+ if (wacom_wac->shared->touch == wacom->hdev)
+ wacom_wac->shared->touch = NULL;
+ else if (wacom_wac->shared->pen == wacom->hdev)
+ wacom_wac->shared->pen = NULL;
- if (wacom->shared) {
- data = container_of(wacom->shared, struct wacom_hdev_data,
shared);
kref_put(>kref, wacom_release_shared_data);
- wacom->shared = NULL;
+ wacom_wac->shared = NULL;
}
}
@@ -1527,7 +1540,7 @@ fail_register_inputs:
wacom_clean_inputs(wacom);
wacom_destroy_battery(wacom);
fail_battery:
- wacom_remove_shared_data(wacom_wac);
+ wacom_remove_shared_data(wacom);
fail_shared_data:
wacom_clean_inputs(wacom);
fail_allocate_inputs:
@@ -1550,7 +1563,7 @@ static void wacom_remove(struct hid_device *hdev)
if (hdev->bus == BUS_BLUETOOTH)
device_remove_file(>dev, _attr_speed);
wacom_destroy_battery(wacom);
- wacom_remove_shared_data(>wacom_wac);
+ wacom_remove_shared_data(wacom);
hid_set_drvdata(hdev, NULL);
kfree(wacom);
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 021ee1c..e42efbe 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -169,6 +169,8 @@ struct wacom_shared {
unsigned touch_max;
int type;
struct input_dev *touch_input;
+ struct hid_device *pen;
+ struct hid_device *touch;
};
struct hid_data {
--
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] clk: qcom: Add MSM8916 Global Clock Controller support
This patch adds support for the global clock controller found on the MSM8916
based devices. It allows the various device drivers to probe and control
their clocks and resets.
Signed-off-by: Georgi Djakov
---
Changes since v1:
* Addressed comments from Stephen Boyd and Archit Taneja
* Fixed some incorrect offsets, parents etc.
* Driver is tested on MSM8916-MTP device.
.../devicetree/bindings/clock/qcom,gcc.txt |1 +
drivers/clk/qcom/Kconfig |8 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-msm8916.c | 2871
include/dt-bindings/clock/qcom,gcc-msm8916.h | 156 ++
include/dt-bindings/reset/qcom,gcc-msm8916.h | 108 +
6 files changed, 3145 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-msm8916.c
create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8916.h
create mode 100644 include/dt-bindings/reset/qcom,gcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d254e037..54c23f34f194 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -8,6 +8,7 @@ Required properties :
"qcom,gcc-apq8084"
"qcom,gcc-ipq8064"
"qcom,gcc-msm8660"
+ "qcom,gcc-msm8916"
"qcom,gcc-msm8960"
"qcom,gcc-msm8974"
"qcom,gcc-msm8974pro"
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0d7ab52b7ab0..48d51512d009 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -46,6 +46,14 @@ config MSM_GCC_8660
Say Y if you want to use peripheral devices such as UART, SPI,
i2c, USB, SD/eMMC, etc.
+config MSM_GCC_8916
+ tristate "MSM8916 Global Clock Controller"
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the global clock controller on msm8916 devices.
+ Say Y if you want to use devices such as UART, SPI i2c, USB,
+ SD/eMMC, display, graphics, camera etc.
+
config MSM_GCC_8960
tristate "APQ8064/MSM8960 Global Clock Controller"
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 617826469595..50b337a24a87 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
+obj-$(CONFIG_MSM_GCC_8916) += gcc-msm8916.o
obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
new file mode 100644
index ..810c38004520
--- /dev/null
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -0,0 +1,2871 @@
+/*
+ * Copyright 2015 Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+
+#define P_XO 0
+#define P_GPLL01
+#define P_GPLL0_AUX1
+#define P_BIMC 2
+#define P_GPLL12
+#define P_GPLL1_AUX2
+#define P_GPLL23
+#define P_GPLL2_AUX3
+#define P_SLEEP_CLK3
+#define P_DSI0_PHYPLL_BYTE 2
+#define P_DSI0_PHYPLL_DSI 2
+
+static const u8 gcc_xo_gpll0_map[] = {
+ [P_XO] = 0,
+ [P_GPLL0] = 1,
+};
+
+static const char *gcc_xo_gpll0[] = {
+ "xo",
+ "gpll0_vote",
+};
+
+static const u8 gcc_xo_gpll0_bimc_map[] = {
+ [P_XO] = 0,
+ [P_GPLL0] = 1,
+ [P_BIMC]= 2,
+};
+
+static const char *gcc_xo_gpll0_bimc[] = {
+ "xo",
+ "gpll0_vote",
+ "bimc_pll_vote",
+};
+
+static const u8 gcc_xo_gpll0a_gpll1_gpll2a_map[] = {
+ [P_XO] = 0,
+ [P_GPLL0_AUX] = 3,
+ [P_GPLL1] = 1,
+ [P_GPLL2_AUX] = 2,
+};
+
+static const char *gcc_xo_gpll0a_gpll1_gpll2a[] = {
+ "xo",
+ "gpll0_vote",
+
[PATCH v2 0/2] HID: wacom: add support of Bamboo PAD
So here is the v2 of the patch set to support the Bamboo PAD. It has been tested by Josep (thanks!) on the wired version and I developped it on the wireless version. I guess it should be good to go if the reviews goes well. Cheers, Benjamin Benjamin Tissoires (2): HID: wacom: store the hid_device pointers of the sibling devices HID: wacom: add full support of the Wacom Bamboo PAD drivers/hid/wacom_sys.c | 49 +--- drivers/hid/wacom_wac.c | 100 drivers/hid/wacom_wac.h | 7 3 files changed, 150 insertions(+), 6 deletions(-) -- 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/
Re: [PATCH 3.14 00/17] 3.14.34-stable review
On Tue, Feb 24, 2015 at 06:10:02PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.34 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Feb 27 02:08:17 UTC 2015. > Anything received after that time might be too late. > Build results: total: 123 pass: 123 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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 3.10 00/16] 3.10.70-stable review
On Tue, Feb 24, 2015 at 06:09:52PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.70 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Feb 27 02:07:52 UTC 2015. > Anything received after that time might be too late. > Build results: total: 123 pass: 123 fail: 0 Qemu tests: total: 27 pass: 27 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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 v2 0/5] introduce gcma
On Wed, 25 Feb 2015, Michal Hocko wrote:
On Wed 25-02-15 14:31:08, SeongJae Park wrote:
Hello Michal,
Thanks for your comment :)
On Tue, 24 Feb 2015, Michal Hocko wrote:
On Tue 24-02-15 04:54:18, SeongJae Park wrote:
[...]
include/linux/cma.h |4 +
include/linux/gcma.h | 64 +++
mm/Kconfig | 24 +
mm/Makefile |1 +
mm/cma.c | 113 -
mm/gcma.c| 1321 ++
6 files changed, 1508 insertions(+), 19 deletions(-)
create mode 100644 include/linux/gcma.h
create mode 100644 mm/gcma.c
Wow this is huge! And I do not see reason for it to be so big. Why
cannot you simply define (per-cma area) 2-class users policy? Either via
kernel command line or export areas to userspace and allow to set policy
there.
For implementation of the idea, we should develop not only policy selection,
but also backend for discardable memory. Most part of this patch were made
for the backend.
What is the backend and why is it needed? I thought the discardable will
go back to the CMA pool. I mean the cover email explained why the
current CMA allocation policy might lead to lower success rate or
stalls. So I would expect a new policy would be a relatively small
change in the CMA allocation path to serve 2-class users as per policy.
It is not clear to my why we need to pull a whole gcma layer in. I might
be missing something obvious because I haven't looked at the patches yet
but this should better be explained in the cover letter.
I meant backend for 2nd-class clients like cleancache and frontswap.
Because implementing backend for cleancache or frontswap is subsystem's
responsibility, gcma was needed to implement those backend. I believe
second ("gcma: utilize reserved memory as discardable memory") and
third ("gcma: adopt cleancache and frontswap as second-class
clients") could be helpful to understand about that.
And yes, I agree the explanation was not enough. My fault, sorry. My
explanation was too concentrated on policy itself. I should explained
about how the policy could be implemented and how gcma did. I will explain
about that in coverletter with next version.
Thanks for your helpful and nice comment.
Thanks,
SeongJae Park
Thanks!
--
Michal Hocko
SUSE Labs
--
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 V4 0/7] x86/intel_rdt: Intel Cache Allocation Technology
> The CAT thing was annoying already, but at least one can find that in > the SDM, this RDT thing, not a single mention. The problems of development at the bleeding edge. Would you rather Linux sat on the sidelines until there are enough Google hits from other users of new features? I did get one hit for a search for: intel "resource director technology" ... but it only has one line in a table with a 50,000' view of what it does. http://www.intel.com/content/dam/www/public/us/en/documents/guides/xeon-intel-server-processor-comparison-guide.pdf Technology: Intel Resource Director Technology Description: Allows the hypervisor to monitor Last Level Cache usage at the application and VM levels. Benefit: Helps to improve performance and efficiency by providing better information for scheduling, load balancing, and workload migration Which isn't any help in evaluating this patch series :-( -Tony -- 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/2] cpusets,isolcpus: exclude isolcpus from load balancing in cpusets
From: Rik van Riel
Ensure that cpus specified with the isolcpus= boot commandline
option stay outside of the load balancing in the kernel scheduler.
Operations like load balancing can introduce unwanted latencies,
which is exactly what the isolcpus= commandline is there to prevent.
Previously, simply creating a new cpuset, without even touching the
cpuset.cpus field inside the new cpuset, would undo the effects of
isolcpus=, by creating a scheduler domain spanning the whole system,
and setting up load balancing inside that domain. The cpuset root
cpuset.cpus file is read-only, so there was not even a way to undo
that effect.
This does not impact the majority of cpusets users, since isolcpus=
is a fairly specialized feature used for realtime purposes.
Cc: Peter Zijlstra
Cc: Clark Williams
Cc: Li Zefan
Cc: Ingo Molnar
Cc: Luiz Capitulino
Cc: Mike Galbraith
Cc: cgro...@vger.kernel.org
Signed-off-by: Rik van Riel
Tested-by: David Rientjes
---
include/linux/sched.h | 2 ++
kernel/cpuset.c | 13 +++--
kernel/sched/core.c | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6d77432e14ff..aeae02435717 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1038,6 +1038,8 @@ static inline struct cpumask *sched_domain_span(struct
sched_domain *sd)
extern void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
struct sched_domain_attr *dattr_new);
+extern cpumask_var_t cpu_isolated_map;
+
/* Allocate an array of sched domains, for partition_sched_domains(). */
cpumask_var_t *alloc_sched_domains(unsigned int ndoms);
void free_sched_domains(cpumask_var_t doms[], unsigned int ndoms);
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 1d1fe9361d29..b544e5229d99 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -625,6 +625,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
int csn;/* how many cpuset ptrs in csa so far */
int i, j, k;/* indices for partition finding loops */
cpumask_var_t *doms;/* resulting partition; i.e. sched domains */
+ cpumask_var_t non_isolated_cpus; /* load balanced CPUs */
struct sched_domain_attr *dattr; /* attributes for custom domains */
int ndoms = 0; /* number of sched domains in result */
int nslot; /* next empty doms[] struct cpumask slot */
@@ -634,6 +635,10 @@ static int generate_sched_domains(cpumask_var_t **domains,
dattr = NULL;
csa = NULL;
+ if (!alloc_cpumask_var(_isolated_cpus, GFP_KERNEL))
+ goto done;
+ cpumask_andnot(non_isolated_cpus, cpu_possible_mask, cpu_isolated_map);
+
/* Special case for the 99% of systems with one, full, sched domain */
if (is_sched_load_balance(_cpuset)) {
ndoms = 1;
@@ -646,7 +651,8 @@ static int generate_sched_domains(cpumask_var_t **domains,
*dattr = SD_ATTR_INIT;
update_domain_attr_tree(dattr, _cpuset);
}
- cpumask_copy(doms[0], top_cpuset.effective_cpus);
+ cpumask_and(doms[0], top_cpuset.effective_cpus,
+non_isolated_cpus);
goto done;
}
@@ -669,7 +675,8 @@ static int generate_sched_domains(cpumask_var_t **domains,
* the corresponding sched domain.
*/
if (!cpumask_empty(cp->cpus_allowed) &&
- !is_sched_load_balance(cp))
+ !(is_sched_load_balance(cp) &&
+ cpumask_intersects(cp->cpus_allowed, non_isolated_cpus)))
continue;
if (is_sched_load_balance(cp))
@@ -751,6 +758,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
if (apn == b->pn) {
cpumask_or(dp, dp, b->effective_cpus);
+ cpumask_and(dp, dp, non_isolated_cpus);
if (dattr)
update_domain_attr_tree(dattr + nslot,
b);
@@ -763,6 +771,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
BUG_ON(nslot != ndoms);
done:
+ free_cpumask_var(non_isolated_cpus);
kfree(csa);
/*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f0f831e8a345..3db1beace19b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5812,7 +5812,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
root_domain *rd, int cpu)
}
/* cpus with isolated domains */
-static cpumask_var_t cpu_isolated_map;
+cpumask_var_t cpu_isolated_map;
/* Setup the mask of cpus configured for isolated domains */
static int __init isolated_cpu_setup(char *str)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[PATCH 2/2] cpusets,isolcpus: add file to show isolated cpus in cpuset
From: Rik van Riel
The previous patch makes it so the code skips over isolcpus when
building scheduler load balancing domains. This makes it hard to
see for a user which of the CPUs in a cpuset are participating in
load balancing, and which ones are isolated cpus.
Add a cpuset.isolcpus file with info on which cpus in a cpuset are
isolated CPUs.
This file is read-only for now. In the future we could extend things
so isolcpus can be changed at run time, for the root (system wide)
cpuset only.
Cc: Peter Zijlstra
Cc: Clark Williams
Cc: Li Zefan
Cc: Ingo Molnar
Cc: Luiz Capitulino
Cc: David Rientjes
Cc: Mike Galbraith
Cc: cgro...@vger.kernel.org
Signed-off-by: Rik van Riel
---
kernel/cpuset.c | 24
1 file changed, 24 insertions(+)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index b544e5229d99..94bf59588e23 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1563,6 +1563,7 @@ typedef enum {
FILE_MEMORY_PRESSURE,
FILE_SPREAD_PAGE,
FILE_SPREAD_SLAB,
+ FILE_ISOLCPUS,
} cpuset_filetype_t;
static int cpuset_write_u64(struct cgroup_subsys_state *css, struct cftype
*cft,
@@ -1704,6 +1705,20 @@ static ssize_t cpuset_write_resmask(struct
kernfs_open_file *of,
return retval ?: nbytes;
}
+static void cpuset_seq_print_isolcpus(struct seq_file *sf, struct cpuset *cs)
+{
+ cpumask_var_t my_isolated_cpus;
+
+ if (!alloc_cpumask_var(_isolated_cpus, GFP_KERNEL))
+ return;
+
+ cpumask_and(my_isolated_cpus, cs->cpus_allowed, cpu_isolated_map);
+
+ seq_printf(sf, "%*pbl\n", nodemask_pr_args(my_isolated_cpus));
+
+ free_cpumask_var(my_isolated_cpus);
+}
+
/*
* These ascii lists should be read in a single call, by using a user
* buffer large enough to hold the entire map. If read in smaller
@@ -1733,6 +1748,9 @@ static int cpuset_common_seq_show(struct seq_file *sf,
void *v)
case FILE_EFFECTIVE_MEMLIST:
seq_printf(sf, "%*pbl\n",
nodemask_pr_args(>effective_mems));
break;
+ case FILE_ISOLCPUS:
+ cpuset_seq_print_isolcpus(sf, cs);
+ break;
default:
ret = -EINVAL;
}
@@ -1893,6 +1911,12 @@ static struct cftype files[] = {
.private = FILE_MEMORY_PRESSURE_ENABLED,
},
+ {
+ .name = "isolcpus",
+ .seq_show = cpuset_common_seq_show,
+ .private = FILE_ISOLCPUS,
+ },
+
{ } /* terminate */
};
--
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/2] cpusets,isolcpus: resolve conflict between cpusets and isolcpus
-v2 addresses the conflict David Rientjes spotted between my previous
patches and commit e8e6d97c9b ("cpuset: use %*pb[l] to print bitmaps
including cpumasks and nodemasks")
Ensure that cpus specified with the isolcpus= boot commandline
option stay outside of the load balancing in the kernel scheduler.
Operations like load balancing can introduce unwanted latencies,
which is exactly what the isolcpus= commandline is there to prevent.
Previously, simply creating a new cpuset, without even touching the
cpuset.cpus field inside the new cpuset, would undo the effects of
isolcpus=, by creating a scheduler domain spanning the whole system,
and setting up load balancing inside that domain. The cpuset root
cpuset.cpus file is read-only, so there was not even a way to undo
that effect.
This does not impact the majority of cpusets users, since isolcpus=
is a fairly specialized feature used for realtime purposes.
--
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 0/2] powerpc/kvm: Enable running guests on RT Linux
* Scott Wood | 2015-02-23 17:27:31 [-0600]: >This isn't a host PIC driver. It's guest PIC emulation, some of which >is indeed not suitable for a rawlock (in particular, openpic_update_irq >which loops on the number of vcpus, with a loop body that calls >IRQ_check() which loops over all pending IRQs). The vcpu limits are a >temporary bandaid to avoid the worst latencies, but I'm still skeptical >about this being upstream material. Okay. >-Scott Sebastian -- 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 00/18] Add support to STMicroelectronics STM32 family
Maxime Coquelin wrote: > > Is support for this in upstream binutils and gcc? What's the preferred > > target tuple? I'll add support to Fedora's cross-binutils and cross-gcc > > sets if I can. > > I just rebuilt using latest upstream binutils and gcc. > To compile Kernel and bootloader, I build a Bare Metal toolchain with > this configuration: > > --target=arm-none-eabi --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 > --with-float=hard --with-mode=thumb Ah, no matter. I thought this was a new arch. I already have 32-bit and 64-bit cross-compilers that should work. Thanks anyway, David -- 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] Hal8188ERateAdaptive.c : Expression is always false because 'else if' condition matches previous condition at line 404.
else if at line 406 has the same condition as the else if at line 404. i chosed 0x5 because it's half 0xb (just a rate controller) Signed-off-by : Ameen Ali --- drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c index 3c651d5..944cf7b 100644 --- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c +++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c @@ -403,7 +403,7 @@ static int odm_ARFBRefresh_8188E(struct odm_dm_struct *dm_odm, struct odm_ra_inf pRaInfo->PTModeSS = 3; else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 2; - else if (pRaInfo->HighestRate > 0x0b) + else if (pRaInfo->HighestRate > 0x5) pRaInfo->PTModeSS = 1; else pRaInfo->PTModeSS = 0; -- 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/
Re: [PATCH 7/8 v2] ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME
On 24/02/15 22:05, Robert ABEL wrote:
> The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
> even though the access is defined as asynchronous, and no GPMC_CLK clock
> is provided to the external device. Still, GPMCFCLKDIVIDER is used as a
> divider
> for the GPMC clock, so it must be programmed to define the
> correct WAITMONITORINGTIME delay.
>
> Calculate GPMCFCLKDIVIDER independent of gpmc,sync-clk-ps in DT for
> truly asynchronous accesses, i.e. both read and write asynchronous.
>
> Signed-off-by: Robert ABEL
> ---
> arch/arm/mach-omap2/gpmc-nand.c| 17 -
> arch/arm/mach-omap2/gpmc-onenand.c | 4 +--
> drivers/memory/omap-gpmc.c | 74
> ++
> include/linux/omap-gpmc.h | 2 +-
> 4 files changed, 80 insertions(+), 17 deletions(-)
>
./scripts/checkpatch.pl detects some styling errors.
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index d5951b1..e863a59 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -96,14 +96,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
> *gpmc_nand_data,
> gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
> gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
>
> - if (gpmc_t) {
> - err = gpmc_cs_set_timings(gpmc_nand_data->cs, gpmc_t);
> - if (err < 0) {
> - pr_err("omap2-gpmc: Unable to set gpmc timings: %d\n",
> err);
> - return err;
> - }
> - }
> -
> memset(, 0, sizeof(struct gpmc_settings));
> if (gpmc_nand_data->of_node)
> gpmc_read_settings_dt(gpmc_nand_data->of_node, );
> @@ -111,6 +103,15 @@ int gpmc_nand_init(struct omap_nand_platform_data
> *gpmc_nand_data,
> gpmc_set_legacy(gpmc_nand_data, );
>
> s.device_nand = true;
> +
> + if (gpmc_t) {
> + err = gpmc_cs_set_timings(gpmc_nand_data->cs, gpmc_t, );
> + if (err < 0) {
> + pr_err("omap2-gpmc: Unable to set gpmc timings: %d\n",
> err);
> + return err;
> + }
> + }
> +
> err = gpmc_cs_program_settings(gpmc_nand_data->cs, );
> if (err < 0)
> goto out_free_cs;
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
> b/arch/arm/mach-omap2/gpmc-onenand.c
> index 53d197e..f899e77 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -293,7 +293,7 @@ static int omap2_onenand_setup_async(void __iomem
> *onenand_base)
> if (ret < 0)
> return ret;
>
> - ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, );
> + ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, , _async);
> if (ret < 0)
> return ret;
>
> @@ -331,7 +331,7 @@ static int omap2_onenand_setup_sync(void __iomem
> *onenand_base, int *freq_ptr)
> if (ret < 0)
> return ret;
>
> - ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, );
> + ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, , _sync);
> if (ret < 0)
> return ret;
>
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index a6abaf0..9cf8d21 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -139,6 +139,8 @@
> #define GPMC_CONFIG1_WAIT_READ_MON (1 << 22)
> #define GPMC_CONFIG1_WAIT_WRITE_MON (1 << 21)
> #define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val & 3) << 18)
Not caused by your patch but we can fix the typo
GPMC_CONFIG1_WAIT_MON_IIME -> GPMC_CONFIG1_WAIT_MON_TIME
> +/** WAITMONITORINGTIME Max Ticks */
> +#define GPMC_CONFIG1_WAIT_MON_TIME_MAX 2
> #define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val & 3) << 16)
> #define GPMC_CONFIG1_DEVICESIZE(val)((val & 3) << 12)
> #define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
> @@ -511,13 +513,41 @@ static int set_gpmc_timing_reg(int cs, int reg, int
> st_bit, int end_bit,
> t->field, #field) < 0) \
> return -1
>
> +/**
> + * gpmc_calc_waitmonitoring_divider - calculate proper GPMCFCLKDIVIDER based
> on WAITMONITORINGTIME
> + * @wait_monitoring WAITMONITORINGTIME in ns.
> + * @return -1 on failure to scale, else proper divider > 0.
> + * @noteWAITMONITORINGTIME will be _at least_ as long as desired.
> + * i.e. read timings should be kept-> don't
> sample bus too early
> + * while write timings should work out as well -> data is
> longer on bus
> + */
> +static int gpmc_calc_waitmonitoring_divider(unsigned int wait_monitoring)
> +{
> +
> + int div = gpmc_ns_to_ticks(wait_monitoring);
> +
> + div += GPMC_CONFIG1_WAIT_MON_TIME_MAX - 1;
> + div /= GPMC_CONFIG1_WAIT_MON_TIME_MAX;
Sorry I didn't understand how this works. :P
>From the TRM,
Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
On Wed, Feb 25, 2015 at 09:28:36PM +0800, zhangfei wrote:
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
> + enum usb_otg_state state;
> +
> + if (!gpio_is_valid(priv->gpio_id) ||
> !gpio_is_valid(priv->gpio_vbus))
> + return;
> +
> + gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> + gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >>>
> >>>looks like this should be using extcon
> >>Not used extcon before.
> >>However, we need gpio_vbus interrupt.
> >>Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> >>interrupt.
> >>Will investigate tomorrow.
> >
> >drivers/extcon/extcon-gpio.c
> I think there is no need to use extcon, gpio is clear enough.
> extcon-gpio.c even do not support dt.
> >>>
> >>>well, add DT. The whole idea of free software is that we improve on
> >>>things we already have. EXTCON is *the* API to handle such things.
> >>
> >>I think I am still not understanding extcon-gpio, not sure why need
> >>use this API here.
> >
> >because extcon is the API to use for external connectors. The same way
> >you use regulator framework to control that single GPIO tied to an
> >enable signal of a fixed regulator, you use extcon when you need to read
> >that gpio signal tied to id pin of the USB connector.
> >
> >>Here two gpio requires, one gpio as interrupt, in the interrupt
> >>handler, we detect the gpio status judging the otg status.
> >>extcon-gpio.c use the interrupt, then can we also use the gpio
> >>interrupt. Using extcon-gpio is used for saving gpio_request?
> >
> >extcon is used to hide gpio_request from dwc2. dwc2 only knows about
> >extcon, not gpios. extcon will request the gpio and use it as interrupt
> >source. When an IRQ fires, it will read the gpio state and decide if it
> >should broadcast a message to tell dwc2 to become host or peripheral.
>
> Thanks for the kind education, understand now.
hey, no problem ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH Resend] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject
On 2/24/2015 9:47 PM, Ethan Zhao wrote: Viresh, Will do that when I get the test box. Thanks Ethan. On Wed, Feb 25, 2015 at 12:35 PM, viresh kumar wrote: On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote: Viresh, With this patch applied, still got the following warning and panic, seems it needs more care. 54.474618] [ cut here ] [ 54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47 kobject_get+0x41/0x50() [ 54.642595] Modules linked in: i2c_i801(+) mfd_core shpchp(+) acpi_cpufreq(+) edac_core ioatdma(+) xfs libcrc32c ast syscopyarea ixgbe sysfillrect sysimgblt sr_mod sd_mod drm_kms_helper igb mdio cdrom e1000e ahci dca ttm libahci uas drm i2c_algo_bit ptp megaraid_sas libata usb_storage i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod [ 55.007264] CPU: 0 PID: 213 Comm: kworker/0:2 Not tainted 3.18.5 [ 55.099970] Hardware name: Oracle Corporation SUN FIRE X4170 M2 SERVER /ASSY,MOTHERBOARD,X4170, BIOS 08120104 05/08/2012 [ 55.239736] Workqueue: kacpi_notify acpi_os_execute_deferred [ 55.308598] bd730b61 88046742baf8 816b7edb [ 55.398305] 88046742bb38 81078ae1 [ 55.488040] 88046742bbd8 8806706b3000 0292 [ 55.56] Call Trace: [ 55.608228] [] dump_stack+0x46/0x58 [ 55.670895] [] warn_slowpath_common+0x81/0xa0 [ 55.743952] [] warn_slowpath_null+0x1a/0x20 [ 55.814929] [] kobject_get+0x41/0x50 [ 55.878654] [] cpufreq_cpu_get+0x75/0xc0 [ 55.946528] [] cpufreq_update_policy+0x2e/0x1f0 [ 56.021682] [] ? up+0x32/0x50 [ 56.078126] [] ? acpi_ns_get_node+0xcb/0xf2 [ 56.148974] [] ? acpi_evaluate_object+0x22c/0x252 [ 56.226066] [] ? acpi_get_handle+0x95/0xc0 [ 56.295871] [] ? acpi_has_method+0x25/0x40 [ 56.365661] [] acpi_processor_ppc_has_changed+0x77/0x82 [ 56.448956] [] ? move_linked_works+0x66/0x90 [ 56.520842] [] acpi_processor_notify+0x58/0xe7 [ 56.594807] [] acpi_ev_notify_dispatch+0x44/0x5c [ 56.670859] [] acpi_os_execute_deferred+0x15/0x22 [ 56.747936] [] process_one_work+0x14e/0x3f0 [ 56.818766] [] worker_thread+0x11b/0x4d0 [ 56.886486] [] ? rescuer_thread+0x350/0x350 [ 56.957316] [] kthread+0xe1/0x100 [ 57.017742] [] ? kthread_create_on_node+0x1b0/0x1b0 [ 57.096903] [] ret_from_fork+0x7c/0xb0 [ 57.162534] [] ? kthread_create_on_node+0x1b0/0x1b0 [ 57.241680] ---[ end trace dce06bb76f547de5 ]--- Any idea ? No. Santosh reported this to me few days back, I asked him to perform some testing but don't know what happened after that.. I didn't get time to re-look into it so far. Regards, Santosh -- 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 3/8 v2] ARM OMAP2+ GPMC: add bus children
On 25/02/15 18:23, Robert Abel wrote: > Hi Roger, > > On 25 Feb 2015 17:18, Roger Quadros wrote: >> OK. Would be interesting to see how unconditional call to >> of_platform_decide_create() behaves >> for your case. > I'm not able to test today, so results will be in tomorrow. If that doesn't > work, I'll just resubmit my first patch with the conditional. Tomorrow is fine. > > I'll be posting a v3 of this entire patch series tomorrow after testing. I > think I should leave your ACKs out for you to re-ACK? If you are not changing the patches I've acked you can keep my ACK. cheers, -roger -- 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 0/3] epoll: introduce round robin wakeup mode
On 02/25/2015 02:38 AM, Ingo Molnar wrote: > * Jason Baron wrote: > >> Hi, >> >> When we are sharing a wakeup source among multiple epoll >> fds, we end up with thundering herd wakeups, since there >> is currently no way to add to the wakeup source >> exclusively. This series introduces a new EPOLL_ROTATE >> flag to allow for round robin exclusive wakeups. >> >> I believe this patch series addresses the two main >> concerns that were raised in prior postings. Namely, that >> it affected code (and potentially performance) of the >> core kernel wakeup functions, even in cases where it was >> not strictly needed, and that it could lead to wakeup >> starvation (since we were are no longer waking up all >> waiters). It does so by adding an extra layer of >> indirection, whereby waiters are attached to a 'psuedo' >> epoll fd, which in turn is attached directly to the >> wakeup source. >> sched/wait: add __wake_up_rotate() >> include/linux/wait.h | 1 + >> kernel/sched/wait.c| 27 ++ > So the scheduler bits are looking good to me in principle, > because they just add a new round-robin-rotating wakeup > variant and don't disturb the others. > > Is there consensus on the epoll ABI changes? With Davide I'm not sure there is a clear consensus on this change, but I'm hoping that I've addressed the outstanding concerns in this latest version. I also think the addition of a way to do a 'wakeup policy' here will open up other 'policies', such as taking into account cpu affinity as you suggested. So, I think its potentially an interesting direction for this code. > Libenzi inactive eventpoll appears to be without a > dedicated maintainer since 2011 or so. Is there anyone who > knows the code and its usages in detail and does final ABI > decisions on eventpoll - Andrew, Al or Linus? > Generally, Andrew and Al do more 'final' reviews here, and a lot of others on lkml are always very helpful in looking at this code. However, its not always clear, at least to me, who I should pester. Thanks, -Jason -- 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 5/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
Hi Tony, On 25 Feb 2015 16:23, Tony Lindgren wrote: * Roger Quadros [150225 05:28]: On 24/02/15 22:05, Robert ABEL wrote: DTS output was formatted to require additional work when copy-pasting into DTS. Nano-second timings were removed, because they were not a confidence interval nor an indication what timing values would result in the same #ticks If they were not is it possible to dump min,max timings that will result in the same ticks? Yeah my plan was o display the nanosecond range resulting in the same tick value. That makes it a bit easier to compare the timings to the data sheet. So maybe show both tick and ns range? Ah, so my hunch was right. I reimplemented that correctly now. Basically, your code just went [ticks-1, ticks+1] in ns. But times are always ceiling(ns / gpmc_[f]clk), i.e. (ticks - 1, ticks] in ns. Some other patches change as well because of this change, so a v3 is in order =]. Regards, Robert -- 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 3/8 v2] ARM OMAP2+ GPMC: add bus children
Hi Roger, On 25 Feb 2015 17:18, Roger Quadros wrote: OK. Would be interesting to see how unconditional call to of_platform_decide_create() behaves for your case. I'm not able to test today, so results will be in tomorrow. If that doesn't work, I'll just resubmit my first patch with the conditional. I'll be posting a v3 of this entire patch series tomorrow after testing. I think I should leave your ACKs out for you to re-ACK? Regards, Robert -- 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/1] Intel Quark X1000 DTS thermal driver
Dear maintainers, This patch introduces DTS thermal driver for Intel Quark X1000. The code implementation is based on intel_soc_dts_thermal.c. Intel Quark X1000 has one on-die DTS with two configurable trip points: critical and hot trip points. However, todate, UEFI BIOS for Quark X1000 uses only critical trip point. UEFI BIOS always lock DTS register before hand-over to Linux kernel. The minimalist thermal design is meant to trigger Linux distro to gracefully power-down the system when its DTS temperature exceeds the configured critical trip point. In anticipation that other variant of Quark platform may come with UEFI BIOS that does not lock DTS register during hand-over, this DTS driver is built with logics to handle such case too. I have tested v1 of the patch on Intel Galileo Gen v2 board and found it satisfactory with logs below: root@quark:/sys/class/thermal/thermal_zone0# echo disabled > mode [ 46.276881] intel_quark_dts_thermal: DTS is locked. Cannot disable DTS -sh: echo: write error: Operation not permitted root@quark:/sys/class/thermal/thermal_zone0# root@quark:/sys/class/thermal/thermal_zone0# cat temp 53 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_temp 105 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_type critical root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_1_temp 20 root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_1_type hot root@quark:/sys/class/thermal/thermal_zone0# cat type quark_dts root@quark:/sys/class/thermal/thermal_zone0# echo 105 > emul_temp [ 179.372981] thermal thermal_zone0: critical temperature reached(0 C),shutting down root@quark:/sys/class/thermal/thermal_zone0# Stopping WPA supplicant... [ OK ] Stopped target Multi-User System. Stopping Telephony service... Stopping Lightning Fast Webserver With Light System Requirements... Stopping Target Communication Framework agent... Stopping Galileo Arduino Layer... [ OK ] Stopped target Login Prompts. Stopping Getty on tty1... Stopping Serial Getty on ttyS1... Stopping Login Service... Stopping D-Bus System Message Bus... Starting Store Sound Card State... [ OK ] Stopped Telephony service. [ OK ] Stopped Galileo Arduino Layer. [ OK ] Stopped Login Service. [ OK ] Stopped D-Bus System Message Bus. [ OK ] Stopped Target Communication Framework agent. [ OK ] Stopped Lightning Fast Webserver With Light System Requirements. [ OK ] Stopped WPA supplicant. [ OK ] Stopped Getty on tty1. [ OK ] Stopped Serial Getty on ttyS1. Please kindly review the patch at your convenient time and provide me feedback for improvement. Appreciate your time and effort. Thank You Ong Boon Leong Intel Corp. --- Changes in v2: * Fix several commit write-up grammar, choice of words. * Ensure "int ret" in correct order * Add comment to explain DTS register field read/write bit operation * Change to Dual BSD/GPL license * Add logic to ensure safe trip point threshold value being set Ong Boon Leong (1): thermal: intel Quark SoC X1000 DTS thermal driver drivers/thermal/Kconfig | 10 drivers/thermal/Makefile |1 drivers/thermal/intel_quark_dts_thermal.c | 434 + 3 files changed, 445 insertions(+) create mode 100644 drivers/thermal/intel_quark_dts_thermal.c -- 1.7.9.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/
irqchip status (please read)
All,
I hate to put the burden on submitters, but I've got to keep the ball
moving. This will not become the status quo.
Due to changes in my work schedule, I lost track of the status of
submissions during the last cycle and over the merge window. Normally,
I keep everything irqchip related in one maildir and as I push things,
it gets flagged and I can easily tell what hasn't been handled yet.
Unfortunately, I needed some help from Thomas last window and that
screwed up my system (my fault entirely).
In order to get back on track, I've marked-as-read and archived
everything prior to February 14th. This is completely arbitrary and not
ideal. So here is what I have in my queue:
[PATCH v2 0/6] enhance configuring an ITS
Yun Wu
20150215
[PATCH v3 0/8] irqchip: New driver for ST's SysCfg controlled IRQs
Lee Jones
20150218
[PATCH v5 0/6] irqchip: Move Tegra LIC to use stacked domains
Marc Zyngier
20150223
[RFC PATCH 0/3] genirq: mixing IRQF_NO_SUSPEND and wakeup sources on shared
IRQs
Boris Brezillon
20150224
[PATCH v5 0/2] irqchip: Move Exynos PM to use stacked domains
Marc Zyngier
20150223
[PATCH v9 16/21] irqchip: Add GICv2 specific ACPI boot support
Hanjun Guo
20150225
[PATCH v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
Marc Zyngier
20150223
"In my queue" means it's queued up for review, nothing more.
I'm certain there are patches for consideration for this cycle which are
not on the above list. If they are yours, I ask you to please bear with
me as I get back into the swing of things and please resend as soon as
possible.
Also, since Cc'ing everyone potentially needing to read this would be
unwieldy and error-prone, if you know someone who is affected by this,
please send them a gentle ping and a pointer to this email.
thx,
Jason.
--
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 3/8 v2] ARM OMAP2+ GPMC: add bus children
Robert, On 25/02/15 17:06, Robert Abel wrote: > Hi Roger, > > On 25 Feb 2015 13:02, Roger Quadros wrote: >> This creates platform devices for the children of child, but what about >> platform device for the child itself? > It seems my first try in the other patch set wasn't so wrong after all. Maybe > unconditionally call > > of_platform_device_create(child,...) and > of_platform_populate(child, ...)? > >> Shouldn't the bus driver for that bus be responsible for spawning children >> of its bus? > Well, a bus driver doesn't actually do much work here. The standard buses are > just there for offset and so on. > And that's my use case. Have one CS region with fixed settings and multiple > devices in it. > > Creating code that in effect replicates what simple-bus does isn't > worthwhile. Basically, it would replicate half the code that > of_platform_populate goes through anyway without good reason. > > If complex bus-behavior is needed -- more than single-bus offset shifts --, a > complex bus driver can always be written. > Since it wouldn't match of_default_match_table, it itself would be > responsible for creating children. > > I think I'll go with my first patch for this one, maybe call > of_platform_decide_create unconditionally to check whether buses are > available. OK. Would be interesting to see how unconditional call to of_platform_decide_create() behaves for your case. cheers, -roger -- 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 2/4] x86: get rid of KERNEL_STACK_OFFSET
On Wed, Feb 25, 2015 at 1:45 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> - BUG_ON(((current_stack_pointer() ^ >> this_cpu_read_stable(kernel_stack)) >> + BUG_ON(((current_stack_pointer() ^ >> +(this_cpu_read_stable(kernel_stack) - 1)) >> & ~(THREAD_SIZE - 1)) != 0); >> >> preempt_count_sub(HARDIRQ_OFFSET); >> >> I added that in and applied this patch. > > So this is not just slightly buggy, it's fundamentally > wrong as well as it removes the possibility of an RSP value > optimization from the 64-bit path, see my previous mail. This is just trying to check that the function is executing on the per-thread stack. It was correct (and fairly heavily tested by Tony) wither KERNEL_STACK_OFFSET being nonzero, but we're checking the wrong page if KERNEL_STACK_OFFSET becomes zero. I don't think I understand your objection to this bit. > > The right solution would be to make SAVE_ARGS recognize > when KERNEL_STACK_OFFSET == args-offset and omit the RSP > fixup in that case, or to simply use a __SAVE_ARGS for the > 64-bit path, knowing that RSP has the right value already. > > Please also add comments that explain the relationship > between percpu::kernel_stack, KERNEL_STACK_OFFSET and the > 64-bit system call entry code. > > Also, guys, please slow down a bit and be more careful. > Andy, could you please send me all currently pending entry > bits pending in your tree, because all the in-flight > changes make it hard for me to review patches? Please > (re-)send all patches as well as part of the submission. Will do later today. Note that someone just found a bug as a result of this being in -next. --Andy -- 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/1] thermal: intel Quark SoC X1000 DTS thermal driver
In Intel Quark SoC X1000, there is one on-die digital temperature sensor(DTS). The DTS offers both hot & critical trip points. However, in current distribution of UEFI BIOS for Quark platform, only critical trip point is configured to be 105 degree Celsius (based on Quark SW ver1.0.1 and hot trip point is not used due to lack of IRQ. There is no active cooling device for Quark SoC, so Quark SoC thermal management logic expects Linux distro to orderly power-off when temperature of the DTS exceeds the configured critical trip point. Kernel param "polling_delay" in milliseconds is used to control the frequency the DTS temperature is read by thermal framework. It defaults to 2-second. To change it, use kernel boot param "intel_quark_dts_thermal.polling_delay=X". User interacts with Quark SoC DTS thermal driver through sysfs via: /sys/class/thermal/thermal_zone0/ For example: - to read DTS temperature $ cat temp - to read critical trip point $ cat trip_point_0_temp - to read trip point type $ cat trip_point_0_type - to emulate temperature raise to test orderly shutdown by Linux distro $ echo 105 > emul_temp Signed-off-by: Ong Boon Leong --- drivers/thermal/Kconfig | 10 drivers/thermal/Makefile |1 drivers/thermal/intel_quark_dts_thermal.c | 434 + 3 files changed, 445 insertions(+) create mode 100644 drivers/thermal/intel_quark_dts_thermal.c diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f554d25..b80f09f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -229,6 +229,16 @@ config INTEL_SOC_DTS_THERMAL notification methods.The other trip is a critical trip point, which was set by the driver based on the TJ MAX temperature. +config INTEL_QUARK_DTS_THERMAL + tristate "Intel Quark DTS thermal driver" + depends on X86 && IOSF_MBI + help + Enable this to register Intel Quark SoC (e.g. X1000) platform digital + temperature sensor (DTS). For X1000 SoC, it has one on-die DTS. + The DTS will be registered as a thermal zone. There are two trip points: + hot & critical. The critical trip point default value is set by + underlying BIOS/Firmware. + config INT340X_THERMAL tristate "ACPI INT340X thermal drivers" depends on X86 && ACPI diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 39c4fe8..50c5991 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)+= intel_soc_dts_thermal.o +obj-$(CONFIG_INTEL_QUARK_DTS_THERMAL) += intel_quark_dts_thermal.o obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/ obj-$(CONFIG_INT340X_THERMAL) += int340x_thermal/ obj-$(CONFIG_ST_THERMAL) += st/ diff --git a/drivers/thermal/intel_quark_dts_thermal.c b/drivers/thermal/intel_quark_dts_thermal.c new file mode 100644 index 000..ca605ed --- /dev/null +++ b/drivers/thermal/intel_quark_dts_thermal.c @@ -0,0 +1,434 @@ +/* + * intel_quark_dts_thermal.c + * Copyright (c) 2015, Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * Quark DTS thermal driver is implemented by referencing + * intel_soc_dts_thermal.c. + */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include +#include +#include +#include +#include +#include + +#define X86_FAMILY_QUARK 0x5 +#define X86_MODEL_QUARK_X1000 0x9 + +/* DTS reset is programmed via QRK_MBI_UNIT_SOC */ +#define QRK_DTS_REG_OFFSET_RESET 0x34 +#define QRK_DTS_RESET_BIT BIT(0) + +/* DTS enable is programmed via QRK_MBI_UNIT_RMU */ +#define QRK_DTS_REG_OFFSET_ENABLE 0xB0 +#define QRK_DTS_ENABLE_BIT BIT(15) + +/* Temperature Register is read via QRK_MBI_UNIT_RMU */ +#define QRK_DTS_REG_OFFSET_TEMP0xB1 +#define QRK_DTS_MASK_TEMP 0xFF +#define QRK_DTS_OFFSET_TEMP0 +#define QRK_DTS_OFFSET_REL_TEMP16 +#define QRK_DTS_TEMP_BASE 50 + +/* Programmable Trip Point Register is configured via QRK_MBI_UNIT_RMU */ +#define QRK_DTS_REG_OFFSET_PTPS0xB2 +#define QRK_DTS_MASK_TP_THRES 0xFF +#define QRK_DTS_SHIFT_TP 8 +#define QRK_DTS_ID_TP_CRITICAL 0 +#define QRK_DTS_SAFE_TP_THRES 105 + +/* Thermal Sensor Register Lock
[PATCH 3/4] arm/arm64: KVM: Fix migration race in the arch timer
From: Christoffer Dall
When a VCPU is no longer running, we currently check to see if it has a
timer scheduled in the future, and if it does, we schedule a host
hrtimer to notify is in case the timer expires while the VCPU is still
not running. When the hrtimer fires, we mask the guest's timer and
inject the timer IRQ (still relying on the guest unmasking the time when
it receives the IRQ).
This is all good and fine, but when migration a VM (checkpoint/restore)
this introduces a race. It is unlikely, but possible, for the following
sequence of events to happen:
1. Userspace stops the VM
2. Hrtimer for VCPU is scheduled
3. Userspace checkpoints the VGIC state (no pending timer interrupts)
4. The hrtimer fires, schedules work in a workqueue
5. Workqueue function runs, masks the timer and injects timer interrupt
6. Userspace checkpoints the timer state (timer masked)
At restore time, you end up with a masked timer without any timer
interrupts and your guest halts never receiving timer interrupts.
Fix this by only kicking the VCPU in the workqueue function, and sample
the expired state of the timer when entering the guest again and inject
the interrupt and mask the timer only then.
Signed-off-by: Christoffer Dall
Signed-off-by: Alex Bennée
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8531536..f7fd76e 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -269,7 +269,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
{
- return 0;
+ return kvm_timer_should_fire(vcpu);
}
int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index b3f45a5..98cc9f4 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -72,6 +72,8 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
+bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
+
#else
static inline int kvm_timer_hyp_init(void)
{
@@ -96,6 +98,11 @@ static inline u64 kvm_arm_timer_get_reg(struct kvm_vcpu
*vcpu, u64 regid)
{
return 0;
}
+
+static inline bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
+{
+ return false;
+}
#endif
#endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 6e54f35..98c95f2 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -85,13 +85,22 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+/*
+ * Work function for handling the backup timer that we schedule when a vcpu is
+ * no longer running, but had a timer programmed to fire in the future.
+ */
static void kvm_timer_inject_irq_work(struct work_struct *work)
{
struct kvm_vcpu *vcpu;
vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
vcpu->arch.timer_cpu.armed = false;
- kvm_timer_inject_irq(vcpu);
+
+ /*
+* If the vcpu is blocked we want to wake it up so that it will see
+* the timer has expired when entering the guest.
+*/
+ kvm_vcpu_kick(vcpu);
}
static enum hrtimer_restart kvm_timer_expire(struct hrtimer *hrt)
@@ -102,6 +111,21 @@ static enum hrtimer_restart kvm_timer_expire(struct
hrtimer *hrt)
return HRTIMER_NORESTART;
}
+bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_cpu *timer = >arch.timer_cpu;
+ cycle_t cval, now;
+
+ if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
+ !(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
+ return false;
+
+ cval = timer->cntv_cval;
+ now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
+
+ return cval <= now;
+}
+
/**
* kvm_timer_flush_hwstate - prepare to move the virt timer to the cpu
* @vcpu: The vcpu pointer
@@ -119,6 +143,13 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
* populate the CPU timer again.
*/
timer_disarm(timer);
+
+ /*
+* If the timer expired while we were not scheduled, now is the time
+* to inject it.
+*/
+ if (kvm_timer_should_fire(vcpu))
+ kvm_timer_inject_irq(vcpu);
}
/**
@@ -134,16 +165,9 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
cycle_t cval, now;
u64 ns;
- if ((timer->cntv_ctl & ARCH_TIMER_CTRL_IT_MASK) ||
- !(timer->cntv_ctl & ARCH_TIMER_CTRL_ENABLE))
- return;
-
- cval = timer->cntv_cval;
- now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
-
BUG_ON(timer_is_armed(timer));
- if (cval <= now) {
+ if (kvm_timer_should_fire(vcpu)) {
/*
* Timer has already expired while we were not
* looking. Inject the interrupt and carry on.
@@ -152,6 +176,9
[PATCH 2/4] arm/arm64: KVM: Implement support for unqueueing active IRQs
From: Christoffer Dall
Migrating active interrupts causes the active state to be lost
completely. This implements some additional bitmaps to track the active
state on the distributor and export this to user space.
Signed-off-by: Christoffer Dall
Signed-off-by: Alex Bennée
---
AJB:
- fixed merge conflicts
- moved additional shared bitmaps to be dynamically allocated
- make irq_active_on_cpu dynamically allocated as well
- in vgic_queue_irq don't queue pending if already active
- in __kvm_vgic_flush_hwstate use pr_shared when checking SPIs
- vgic: clear active on CPU bit
- checkpatch, remove extraneous braces
- checkpatch, remove debug, fix overflows
- move register access fns to re-factored vgic-v2-emul.c
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 7c55dd5..7042251 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -196,6 +196,9 @@ struct vgic_dist {
/* Level-triggered interrupt queued on VCPU interface */
struct vgic_bitmap irq_queued;
+ /* Interrupt was active when unqueue from VCPU interface */
+ struct vgic_bitmap irq_active;
+
/* Interrupt priority. Not used yet. */
struct vgic_bytemap irq_priority;
@@ -236,6 +239,9 @@ struct vgic_dist {
/* Bitmap indicating which CPU has something pending */
unsigned long *irq_pending_on_cpu;
+ /* Bitmap indicating which CPU has active IRQs */
+ unsigned long *irq_active_on_cpu;
+
struct vgic_vm_ops vm_ops;
#endif
};
@@ -269,9 +275,15 @@ struct vgic_cpu {
/* per IRQ to LR mapping */
u8 *vgic_irq_lr_map;
- /* Pending interrupts on this VCPU */
+ /* Pending/active/both interrupts on this VCPU */
DECLARE_BITMAP( pending_percpu, VGIC_NR_PRIVATE_IRQS);
+ DECLARE_BITMAP( active_percpu, VGIC_NR_PRIVATE_IRQS);
+ DECLARE_BITMAP( pend_act_percpu, VGIC_NR_PRIVATE_IRQS);
+
+ /* Pending/active/both shared interrupts, dynamically sized */
unsigned long *pending_shared;
+ unsigned long *active_shared;
+ unsigned long *pend_act_shared;
/* Bitmap of used/free list registers */
DECLARE_BITMAP( lr_used, VGIC_V2_MAX_LRS);
@@ -311,6 +323,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
unsigned int irq_num,
bool level);
void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
+int kvm_vgic_vcpu_active_irq(struct kvm_vcpu *vcpu);
bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
struct kvm_exit_mmio *mmio);
diff --git a/virt/kvm/arm/vgic-v2-emul.c b/virt/kvm/arm/vgic-v2-emul.c
index 19c6210..c818662 100644
--- a/virt/kvm/arm/vgic-v2-emul.c
+++ b/virt/kvm/arm/vgic-v2-emul.c
@@ -107,6 +107,22 @@ static bool handle_mmio_clear_pending_reg(struct kvm_vcpu
*vcpu,
vcpu->vcpu_id);
}
+static bool handle_mmio_set_active_reg(struct kvm_vcpu *vcpu,
+ struct kvm_exit_mmio *mmio,
+ phys_addr_t offset)
+{
+ return vgic_handle_set_active_reg(vcpu->kvm, mmio, offset,
+ vcpu->vcpu_id);
+}
+
+static bool handle_mmio_clear_active_reg(struct kvm_vcpu *vcpu,
+struct kvm_exit_mmio *mmio,
+phys_addr_t offset)
+{
+ return vgic_handle_clear_active_reg(vcpu->kvm, mmio, offset,
+ vcpu->vcpu_id);
+}
+
static bool handle_mmio_priority_reg(struct kvm_vcpu *vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
@@ -344,13 +360,13 @@ static const struct kvm_mmio_range vgic_dist_ranges[] = {
.base = GIC_DIST_ACTIVE_SET,
.len= VGIC_MAX_IRQS / 8,
.bits_per_irq = 1,
- .handle_mmio= handle_mmio_raz_wi,
+ .handle_mmio= handle_mmio_set_active_reg,
},
{
.base = GIC_DIST_ACTIVE_CLEAR,
.len= VGIC_MAX_IRQS / 8,
.bits_per_irq = 1,
- .handle_mmio= handle_mmio_raz_wi,
+ .handle_mmio= handle_mmio_clear_active_reg,
},
{
.base = GIC_DIST_PRI,
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 0cc6ab6..af6a521 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -277,6 +277,14 @@ static void vgic_irq_clear_queued(struct kvm_vcpu *vcpu,
int irq)
vgic_bitmap_set_irq_val(>irq_queued, vcpu->vcpu_id, irq, 0);
}
+
+static void vgic_irq_set_active(struct kvm_vcpu *vcpu, int irq)
+{
+ struct vgic_dist *dist = >kvm->arch.vgic;
+
+
[PATCH 4/4] arm/arm64: KVM: Keep elrsr/aisr in sync with software model
From: Christoffer Dall
There is an interesting bug in the vgic code, which manifests itself
when the KVM run loop has a signal pending or needs a vmid generation
rollover after having disabled interrupts but before actually switching
to the guest.
In this case, we flush the vgic as usual, but we sync back the vgic
state and exit to userspace before entering the guest. The consequence
is that we will be syncing the list registers back to the software model
using the GICH_ELRSR and GICH_EISR from the last execution of the guest,
potentially overwriting a list register containing an interrupt.
This showed up during migration testing where we would capture a state
where the VM has masked the arch timer but there were no interrupts,
resulting in a hung test.
Cc: Marc Zyngier
Reported-by: Alex Bennee
Signed-off-by: Christoffer Dall
Signed-off-by: Alex Bennée
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 7042251..e2a676e 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -114,6 +114,7 @@ struct vgic_ops {
void(*sync_lr_elrsr)(struct kvm_vcpu *, int, struct vgic_lr);
u64 (*get_elrsr)(const struct kvm_vcpu *vcpu);
u64 (*get_eisr)(const struct kvm_vcpu *vcpu);
+ void(*clear_eisr)(struct kvm_vcpu *vcpu);
u32 (*get_interrupt_status)(const struct kvm_vcpu *vcpu);
void(*enable_underflow)(struct kvm_vcpu *vcpu);
void(*disable_underflow)(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/arm/vgic-v2.c b/virt/kvm/arm/vgic-v2.c
index a0a7b5d..f9b9c7c 100644
--- a/virt/kvm/arm/vgic-v2.c
+++ b/virt/kvm/arm/vgic-v2.c
@@ -72,6 +72,8 @@ static void vgic_v2_sync_lr_elrsr(struct kvm_vcpu *vcpu, int
lr,
{
if (!(lr_desc.state & LR_STATE_MASK))
vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr |= (1ULL << lr);
+ else
+ vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr &= ~(1ULL << lr);
}
static u64 vgic_v2_get_elrsr(const struct kvm_vcpu *vcpu)
@@ -84,6 +86,11 @@ static u64 vgic_v2_get_eisr(const struct kvm_vcpu *vcpu)
return vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr;
}
+static void vgic_v2_clear_eisr(struct kvm_vcpu *vcpu)
+{
+ vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr = 0;
+}
+
static u32 vgic_v2_get_interrupt_status(const struct kvm_vcpu *vcpu)
{
u32 misr = vcpu->arch.vgic_cpu.vgic_v2.vgic_misr;
@@ -148,6 +155,7 @@ static const struct vgic_ops vgic_v2_ops = {
.sync_lr_elrsr = vgic_v2_sync_lr_elrsr,
.get_elrsr = vgic_v2_get_elrsr,
.get_eisr = vgic_v2_get_eisr,
+ .clear_eisr = vgic_v2_clear_eisr,
.get_interrupt_status = vgic_v2_get_interrupt_status,
.enable_underflow = vgic_v2_enable_underflow,
.disable_underflow = vgic_v2_disable_underflow,
diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index 3a62d8a..dff0602 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -104,6 +104,8 @@ static void vgic_v3_sync_lr_elrsr(struct kvm_vcpu *vcpu,
int lr,
{
if (!(lr_desc.state & LR_STATE_MASK))
vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr |= (1U << lr);
+ else
+ vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr &= ~(1U << lr);
}
static u64 vgic_v3_get_elrsr(const struct kvm_vcpu *vcpu)
@@ -116,6 +118,11 @@ static u64 vgic_v3_get_eisr(const struct kvm_vcpu *vcpu)
return vcpu->arch.vgic_cpu.vgic_v3.vgic_eisr;
}
+static void vgic_v3_clear_eisr(struct kvm_vcpu *vcpu)
+{
+ vcpu->arch.vgic_cpu.vgic_v3.vgic_eisr = 0;
+}
+
static u32 vgic_v3_get_interrupt_status(const struct kvm_vcpu *vcpu)
{
u32 misr = vcpu->arch.vgic_cpu.vgic_v3.vgic_misr;
@@ -192,6 +199,7 @@ static const struct vgic_ops vgic_v3_ops = {
.sync_lr_elrsr = vgic_v3_sync_lr_elrsr,
.get_elrsr = vgic_v3_get_elrsr,
.get_eisr = vgic_v3_get_eisr,
+ .clear_eisr = vgic_v3_clear_eisr,
.get_interrupt_status = vgic_v3_get_interrupt_status,
.enable_underflow = vgic_v3_enable_underflow,
.disable_underflow = vgic_v3_disable_underflow,
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 3b4ded2..3690c1e 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -980,6 +980,11 @@ static inline u64 vgic_get_eisr(struct kvm_vcpu *vcpu)
return vgic_ops->get_eisr(vcpu);
}
+static inline void vgic_clear_eisr(struct kvm_vcpu *vcpu)
+{
+ vgic_ops->clear_eisr(vcpu);
+}
+
static inline u32 vgic_get_interrupt_status(struct kvm_vcpu *vcpu)
{
return vgic_ops->get_interrupt_status(vcpu);
@@ -1019,6 +1024,7 @@ static void vgic_retire_lr(int lr_nr, int irq, struct
kvm_vcpu *vcpu)
vgic_set_lr(vcpu, lr_nr, vlr);
clear_bit(lr_nr, vgic_cpu->lr_used);
vgic_cpu->vgic_irq_lr_map[irq] = LR_EMPTY;
+ vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
}
/*
@@ -1063,6 +1069,7 @@ static
Re: [RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 10:58 AM, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
>> This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
>> instructions. It also fixes an asm comment for __cmpxchg2.
>>
>> Currently using a half-word xchg() results in the following splat on an ARMv7
>> machine.
>>
>> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
>> [ 45.833324] [ cut here ]
>> [ 45.837939] kernel BUG at
>> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
>>
>> Signed-off-by: Pranith Kumar
>
> Unfortunately, the BUG message seems incomplete, can you reproduce this
> with CONFIG_DEBUG_BUGVERBOSE enabled?
The bug here is in a module caused when xchg() was used on uint16_t
variable. It is caused by the __bad_xchg() for 2 byte swap.
More information:
[ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
[ 45.846450] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 45.852275] Modules linked in: test(O+) nvhost_vi
[ 45.857012] CPU: 0 PID: 1848 Comm: insmod Tainted: G O
3.10.24-g6a2d13a #1
[ 45.864744] task: ee406580 ti: eb18c000 task.ti: eb18c000
[ 45.870141] PC is at __bad_xchg+0x24/0x28
[ 45.874146] LR is at __bad_xchg+0x24/0x28
>
>> arch/arm/include/asm/cmpxchg.h | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
>> index abb2c37..9505cca 100644
>> --- a/arch/arm/include/asm/cmpxchg.h
>> +++ b/arch/arm/include/asm/cmpxchg.h
>> @@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x,
>> volatile void *ptr, int size
>> : "r" (x), "r" (ptr)
>> : "memory", "cc");
>> break;
>> + case 2:
>> + asm volatile("@ __xchg2\n"
>> + "1: ldrexh %0, [%3]\n"
>> + " strexh %1, %2, [%3]\n"
>> + " teq %1, #0\n"
>> + " bne 1b"
>> + : "=" (ret), "=" (tmp)
>> + : "r" (x), "r" (ptr)
>> + : "memory", "cc");
>> + break;
>> case 4:
>> asm volatile("@ __xchg4\n"
>> "1: ldrex %0, [%3]\n"
>
> Does this work on all ARMv6 or just ARMv6k?
>
ldrexh/strexh is being used in cmpxchg() in the same file in a similar
manner, and the comment there says that it works for all ARCH >=
ARMv6k, so not ARMv6 I guess.
--
Pranith
--
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 v2 0/5] introduce gcma
On Wed 25-02-15 14:31:08, SeongJae Park wrote: > Hello Michal, > > Thanks for your comment :) > > On Tue, 24 Feb 2015, Michal Hocko wrote: > > >On Tue 24-02-15 04:54:18, SeongJae Park wrote: > >[...] > >> include/linux/cma.h |4 + > >> include/linux/gcma.h | 64 +++ > >> mm/Kconfig | 24 + > >> mm/Makefile |1 + > >> mm/cma.c | 113 - > >> mm/gcma.c| 1321 > >> ++ > >> 6 files changed, 1508 insertions(+), 19 deletions(-) > >> create mode 100644 include/linux/gcma.h > >> create mode 100644 mm/gcma.c > > > >Wow this is huge! And I do not see reason for it to be so big. Why > >cannot you simply define (per-cma area) 2-class users policy? Either via > >kernel command line or export areas to userspace and allow to set policy > >there. > > For implementation of the idea, we should develop not only policy selection, > but also backend for discardable memory. Most part of this patch were made > for the backend. What is the backend and why is it needed? I thought the discardable will go back to the CMA pool. I mean the cover email explained why the current CMA allocation policy might lead to lower success rate or stalls. So I would expect a new policy would be a relatively small change in the CMA allocation path to serve 2-class users as per policy. It is not clear to my why we need to pull a whole gcma layer in. I might be missing something obvious because I haven't looked at the patches yet but this should better be explained in the cover letter. Thanks! -- Michal Hocko SUSE Labs -- 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/4] arm: KVM: export vcpi->pause state via MP_STATE ioctls
To cleanly restore an SMP VM we need to ensure that the current pause
state of each vcpu is correctly recorded. Things could get confused if
the CPU starts running after migration restore completes when it was
paused before it state was captured.
We use the existing KVM_GET/SET_MP_STATE ioctl to do this. The arm/arm64
interface is a lot simpler as the only valid states are
KVM_MP_STATE_RUNNABLE and KVM_MP_STATE_HALTED.
Signed-off-by: Alex Bennée
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index b112efc..602156f 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -997,7 +997,7 @@ for vm-wide capabilities.
4.38 KVM_GET_MP_STATE
Capability: KVM_CAP_MP_STATE
-Architectures: x86, s390
+Architectures: x86, s390, arm, arm64
Type: vcpu ioctl
Parameters: struct kvm_mp_state (out)
Returns: 0 on success; -1 on error
@@ -1027,15 +1027,21 @@ Possible values are:
- KVM_MP_STATE_LOAD:the vcpu is in a special load/startup state
[s390]
-On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
-in-kernel irqchip, the multiprocessing state must be maintained by userspace on
+For x86:
+
+This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
+irqchip, the multiprocessing state must be maintained by userspace on
these architectures.
+For arm/arm64:
+
+The only states that are valid are KVM_MP_STATE_HALTED and
+KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not.
4.39 KVM_SET_MP_STATE
Capability: KVM_CAP_MP_STATE
-Architectures: x86, s390
+Architectures: x86, s390, arm, arm64
Type: vcpu ioctl
Parameters: struct kvm_mp_state (in)
Returns: 0 on success; -1 on error
@@ -1043,10 +1049,16 @@ Returns: 0 on success; -1 on error
Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for
arguments.
-On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an
-in-kernel irqchip, the multiprocessing state must be maintained by userspace on
+For x86:
+
+This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
+irqchip, the multiprocessing state must be maintained by userspace on
these architectures.
+For arm/arm64:
+
+The only states that are valid are KVM_MP_STATE_HALTED and
+KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not.
4.40 KVM_SET_IDENTITY_MAP_ADDR
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 5560f74..8531536 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -183,6 +183,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PSCI:
case KVM_CAP_ARM_PSCI_0_2:
case KVM_CAP_READONLY_MEM:
+ case KVM_CAP_MP_STATE:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -313,13 +314,29 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
*vcpu,
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
- return -EINVAL;
+ if (vcpu->arch.pause)
+ mp_state->mp_state = KVM_MP_STATE_HALTED;
+ else
+ mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
+
+ return 0;
}
int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
- return -EINVAL;
+ switch (mp_state->mp_state) {
+ case KVM_MP_STATE_RUNNABLE:
+ vcpu->arch.pause = false;
+ break;
+ case KVM_MP_STATE_HALTED:
+ vcpu->arch.pause = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
}
/**
--
2.3.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: [PATCH v6 6/7] PCI: update dma configuration from DT
On Wednesday 25 February 2015 11:03:02 Murali Karicheri wrote: > > > (I don't know exactly how these patches all fit together, so that's > > probably not accurate, but that's the *sort* of thing I'd like to include.) > > > > If that actually *is* what's going on, I have to wonder why this isn't > > implemented as a very simple IOMMU instead of adding dma_pfn_offset, > > which is present on all arches but only used on ARM. In some sense that > > offset is parallel but incompatible with an IOMMU: they both translate DMA > > addresses into system RAM addresses. > > I don't have much history on any previous discussion on the subject you > are referring to. I assume it would have happened when > of_dma_configure() was first introduced. On Keystone, we don't have > IOMMU support and dma_pfn_offset is needed to translate DMA address to > System RAM address and vice-versa. So this has to be supported for > Keystone. There can be enhancement for IOMMU with out impacting this > feature for Keystone. The direction we are taking with IOMMU in general is opposite to what Bjorn is suggesting: I believe what he wants to say is that we should use the traditional approach of having a specialized dma_map_ops implementation for this, just like we do for IOMMU implementations on x86, IA64 or PowerPC. However, with the recent explosion of IOMMU implementations on ARM, we are moving towards having a single dma_map_ops structure for all of them, and that structure does not work with the keystone hardware. Instead, the normal ARM dma_map_ops have been changed to handle the offset, which is the same thing we do on PowerPC. Arnd -- 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] thermal: armada: read stable temp on Armada XP
Hi Tyler, Eduardo, On 24/02/2015 20:56, Tyler Hall wrote: > Eduardo, > > On Tue, Feb 24, 2015 at 1:36 PM, Eduardo Valentin wrote: >> The fix seams reasonable. Although, it remains the question what is >> applicability to other Armada chips? Besides, shouldn't we simply use it >> by default? Also, do you plan to send updates in the DTS files? > > As far as I can tell, Armada 370 is already using the equivalent of > this register I'd like to use in Armada XP. I'm not sure about the > other mvebu platforms. I couldn't just change the device tree for XP > to instantiate the 370 sensor, however, as they have different > initialization routines. Possibly Eziquiel can comment on the > significance of the differences between armadaxp_init_sensor() and > armada370_init_sensor(). > > I would like to change the default going forward, but I don't think it > can be changed on platforms using an older DTB. Here you introduced a new kind of thermal sensor, at least from the point of view of the device tree. You used a new compatible string associated to a different register. By using it by default do you mean removing marvell,armadaxp-thermal and adding armadaxp-filtered-thermal instead ? Does that new thermal sensors only improve the stability or does it also modify the value? In the second case it will more or less break the user space expectation. > > I had planned to submit the dts change separately. It's not clear to > me how that's supposed to be handled if they might go through > different trees. For this, there is no problem be handled in a different tree. At the end we will need both the a new dts and a new driver to use it, so the fact that the dts or the driver patch is merged in mainline first is not important. Thanks, Gregory > > Thanks, > Tyler > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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/
Re: [PATCH 9/8 v2] ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters
Robert, On 25/02/15 17:17, Robert Abel wrote: > Hi Roger, > > On 25 Feb 2015 11:44, Roger Quadros wrote: >> typo ATTCHEDDEVICEPAGELENGTH->ATTACHEDDEVICEPAGELENGTH > Yep. >>> +/** DEVICESIZE Max Value */ >>> +#define GPMC_CONFIG1_DEVICESIZE_MAX GPMC_CONFIG1_DEVICESIZE_16 >> Shouldn't this be 1 instead? I'm hoping max value is without the shift >> based on GPMC_CONFIG1_CLKACTIVATIONTIME_MAX. > Yes, it should. It's a remnant from the change below... >>> + * @max Maximum parameter value (after optional @shift). >> max should be absolute value, without the shift. > Yes, forgot to change that. >>> +#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, max, field) \ >>> +get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, >>> GPMC_CD_FCLK, (shift), 1, 1) >> Is it better to rename this to GPMC_GET_RAW_SHIFT_MAX() as it takes the max >> parameter. > Ok. >>> +GPMC_GET_RAW_SHIFT(GPMC_CS_CONFIG1, 23, 24, 4, 2, "burst-length"); >> want to define GPMC_CONFIG1_BURSTLENGTH_MAX? > Yes, for consistency. Originally, i was not going to create defines for > limits used only in one place, as opposed to WAITMONITORINGTIME and > CLKACTIVATIONTIME. >>> -GPMC_GET_TICKS_CD(GPMC_CS_CONFIG1, 18, 19, "wait-monitoring-ns", >>> GPMC_CD_CLK); >>> -GPMC_GET_TICKS(GPMC_CS_CONFIG1, 25, 26, "clk-activation-ns"); >>> +GPMC_GET_TICKS_CD_MAX(GPMC_CS_CONFIG1, 18, 19, >>> GPMC_CONFIG1_WAIT_MON_TIME_MAX, "wait-monitoring-ns", GPMC_CD_CLK); >> use GPMC_CONFIG1_WAITMONTIME_MAX to have consistent naming. > I used the naming the other define had. Saw no point in changing them. They > go mostly unused anyway. > Might as well change it. Not much of an issue. I leave it upto you. cheers, -roger > >>> +#define GPMC_SET_ONE_CD(reg, st, end, field, cd) \ >>> +GPMC_SET_ONE_CD_MAX(reg, st, end, 0, field, GPMC_CD_FCLK) >> last parameter should be (cd) instead of GPMC_CD_FCLK. > Ah, copy-paste, there you are again. Luckily this define goes unused, because > all GPMC_SET_ONE_CD became GPMC_SET_ONE_CD_MAX anyway. > So I'll delete that. Quite a keen eye, though ;) > > Regards, > > Robert -- 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: (almost) getting rid of FIXUP/RESTORE_TOP_OF_STACK?
On Tue, Feb 24, 2015 at 3:45 AM, Denys Vlasenko wrote: > On 02/24/2015 12:58 AM, Andy Lutomirski wrote: >>> - Next possible change is to use PUSH insns to build the stack. Something >>> along the lines of >>> swapgs >>> mov %rsp,%gs:old_rsp >>> mov %gs:kernel_stack,%rsp >>> sti >>> push$__USER_DS /* pt_regs->ss */ >>> push%gs:old_rsp /* ->rsp */ >>> push%r11 /* ->rflags */ >>> push$__USER_CS /* ->cs */ >>> push%rcx /* ->rip */ >>> push%rax /* ->orig_rax */ >>> push%rdi >>> push%rsi >>> push%rdx >>> push%rcx >>> push$-ENOSYS /* ->rax */ >>> push%r8 >>> push%r9 >>> push%r10 >>> push%r11 >>> sub $(6*8),%rsp /* rbx, rbp, r12-r15 not saved */ > > Correction: > push%r11 > sub $(6*8),%rsp /* rbx, rbp, r12-r15 not saved */ > should be > sub $(7*8),%rsp /* r11, rbx, rbp, r12-r15 not saved */ > since we don't need to save r11 either. > >> >> Yay! > > "yay!" as in "I like this!" or as in "I am surprised" ? > >> Can we have a macro PUSH_XYZ for most of this? > > Yes, it can be a macro. I'm not sure we'll have more than one > such place, tho. > Do you want a macro even if it will be once-use only? > Maybe not. If it gets other uses, it can be macro-ized. -- Andy Lutomirski AMA Capital Management, LLC -- 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/4] x86: entry.S: tidy up several suboptimal insns
On Wed, Feb 25, 2015 at 11:01:29AM -0500, Steven Rostedt wrote: > I'm just curious, do all these micro optimizations have any real impact > on real use cases? > > That is, if we are going to make the system less robust, shouldn't we > show that it has real benefit? I'm wondering the same thing this whole time. Is it even worth the bother if those "improvements" don't show on any reasonable benchmark...? And maybe we should benchmark stuff first and then apply. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 V2 08/12] i2c: dln2: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-dln2.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
index b3fb86af4cbb14..b6f9ba7eb17564 100644
--- a/drivers/i2c/busses/i2c-dln2.c
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -144,7 +144,6 @@ static int dln2_i2c_xfer(struct i2c_adapter *adapter,
{
struct dln2_i2c *dln2 = i2c_get_adapdata(adapter);
struct i2c_msg *pmsg;
- struct device *dev = >adapter.dev;
int i;
for (i = 0; i < num; i++) {
@@ -152,11 +151,6 @@ static int dln2_i2c_xfer(struct i2c_adapter *adapter,
pmsg = [i];
- if (pmsg->len > DLN2_I2C_MAX_XFER_SIZE) {
- dev_warn(dev, "maximum transfer size exceeded\n");
- return -EOPNOTSUPP;
- }
-
if (pmsg->flags & I2C_M_RD) {
ret = dln2_i2c_read(dln2, pmsg->addr, pmsg->buf,
pmsg->len);
@@ -187,6 +181,11 @@ static const struct i2c_algorithm dln2_i2c_usb_algorithm =
{
.functionality = dln2_i2c_func,
};
+static struct i2c_adapter_quirks dln2_i2c_quirks = {
+ .max_read_len = DLN2_I2C_MAX_XFER_SIZE,
+ .max_write_len = DLN2_I2C_MAX_XFER_SIZE,
+};
+
static int dln2_i2c_probe(struct platform_device *pdev)
{
int ret;
@@ -209,6 +208,7 @@ static int dln2_i2c_probe(struct platform_device *pdev)
dln2->adapter.owner = THIS_MODULE;
dln2->adapter.class = I2C_CLASS_HWMON;
dln2->adapter.algo = _i2c_usb_algorithm;
+ dln2->adapter.quirks = _i2c_quirks;
dln2->adapter.dev.parent = dev;
i2c_set_adapdata(>adapter, dln2);
snprintf(dln2->adapter.name, sizeof(dln2->adapter.name), "%s-%s-%d",
--
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/
[RFC V2 04/12] i2c: opal: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-opal.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 16f90b1a750894..b2788ecad5b3cb 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -104,17 +104,6 @@ static int i2c_opal_master_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
req.buffer_ra = cpu_to_be64(__pa(msgs[0].buf));
break;
case 2:
- /* For two messages, we basically support only simple
-* smbus transactions of a write plus a read. We might
-* want to allow also two writes but we'd have to bounce
-* the data into a single buffer.
-*/
- if ((msgs[0].flags & I2C_M_RD) || !(msgs[1].flags & I2C_M_RD))
- return -EOPNOTSUPP;
- if (msgs[0].len > 4)
- return -EOPNOTSUPP;
- if (msgs[0].addr != msgs[1].addr)
- return -EOPNOTSUPP;
req.type = OPAL_I2C_SM_READ;
req.addr = cpu_to_be16(msgs[0].addr);
req.subaddr_sz = msgs[0].len;
@@ -210,6 +199,16 @@ static const struct i2c_algorithm i2c_opal_algo = {
.functionality = i2c_opal_func,
};
+/* For two messages, we basically support only simple
+ * smbus transactions of a write plus a read. We might
+ * want to allow also two writes but we'd have to bounce
+ * the data into a single buffer.
+ */
+static struct i2c_adapter_quirks i2c_opal_quirks = {
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .max_comb_1st_msg_len = 4,
+};
+
static int i2c_opal_probe(struct platform_device *pdev)
{
struct i2c_adapter *adapter;
@@ -232,6 +231,7 @@ static int i2c_opal_probe(struct platform_device *pdev)
adapter->algo = _opal_algo;
adapter->algo_data = (void *)(unsigned long)opal_id;
+ adapter->quirks = _opal_quirks;
adapter->dev.parent = >dev;
adapter->dev.of_node = of_node_get(pdev->dev.of_node);
pname = of_get_property(pdev->dev.of_node, "ibm,port-name", NULL);
--
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/
[RFC V2 03/12] i2c: at91: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-at91.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 636fd2efad8850..b3a70e8fc653c5 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -487,30 +487,10 @@ static int at91_twi_xfer(struct i2c_adapter *adap, struct
i2c_msg *msg, int num)
if (ret < 0)
goto out;
- /*
-* The hardware can handle at most two messages concatenated by a
-* repeated start via it's internal address feature.
-*/
- if (num > 2) {
- dev_err(dev->dev,
- "cannot handle more than two concatenated messages.\n");
- ret = 0;
- goto out;
- } else if (num == 2) {
+ if (num == 2) {
int internal_address = 0;
int i;
- if (msg->flags & I2C_M_RD) {
- dev_err(dev->dev, "first transfer must be write.\n");
- ret = -EINVAL;
- goto out;
- }
- if (msg->len > 3) {
- dev_err(dev->dev, "first message size must be <= 3.\n");
- ret = -EINVAL;
- goto out;
- }
-
/* 1st msg is put into the internal address, start with 2nd */
m_start = [1];
for (i = 0; i < msg->len; ++i) {
@@ -540,6 +520,15 @@ out:
return ret;
}
+/*
+ * The hardware can handle at most two messages concatenated by a
+ * repeated start via it's internal address feature.
+ */
+static struct i2c_adapter_quirks at91_twi_quirks = {
+ .flags = I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST | I2C_AQ_COMB_SAME_ADDR,
+ .max_comb_1st_msg_len = 3,
+};
+
static u32 at91_twi_func(struct i2c_adapter *adapter)
{
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL
@@ -777,6 +766,7 @@ static int at91_twi_probe(struct platform_device *pdev)
dev->adapter.owner = THIS_MODULE;
dev->adapter.class = I2C_CLASS_DEPRECATED;
dev->adapter.algo = _twi_algorithm;
+ dev->adapter.quirks = _twi_quirks;
dev->adapter.dev.parent = dev->dev;
dev->adapter.nr = pdev->id;
dev->adapter.timeout = AT91_I2C_TIMEOUT;
--
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/
[RFC V2 01/12] i2c: add quirk structure to describe adapter flaws
From: Wolfram Sang
The number of I2C adapters which are not fully I2C compatible is rising,
sadly. Drivers usually do handle the flaws, still the user receives only
some errno for a transfer which normally can be expected to work. This
patch introduces a formal description of flaws. One advantage is that
the core can check before the actual transfer if the messages could be
transferred at all. This is done in the next patch. Another advantage is
that we can pass this information to the user so the restrictions are
exactly known and further actions can be based on that. This will be
done later after some stabilization period for this description.
Signed-off-by: Wolfram Sang
---
include/linux/i2c.h | 43 +++
1 file changed, 43 insertions(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index f17da50402a4da..243d1a1d78b248 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -449,6 +449,48 @@ int i2c_recover_bus(struct i2c_adapter *adap);
int i2c_generic_gpio_recovery(struct i2c_adapter *adap);
int i2c_generic_scl_recovery(struct i2c_adapter *adap);
+/**
+ * struct i2c_adapter_quirks - describe flaws of an i2c adapter
+ * @flags: see I2C_AQ_* for possible flags and read below
+ * @max_num_msgs: maximum number of messages per transfer
+ * @max_write_len: maximum length of a write message
+ * @max_read_len: maximum length of a read message
+ * @max_comb_1st_msg_len: maximum length of the first msg in a combined message
+ * @max_comb_2nd_msg_len: maximum length of the second msg in a combined
message
+ *
+ * Note about combined messages: Some I2C controllers can only send one message
+ * per transfer, plus something called combined message or write-then-read.
+ * This is (usually) a small write message followed by a read message and
+ * barely enough to access register based devices like EEPROMs. There is a flag
+ * to support this mode. It implies max_num_msg = 2 and does the length checks
+ * with max_comb_*_len because combined message mode usually has its own
+ * limitations. Because of HW implementations, some controllers can actually do
+ * write-then-anything or other variants. To support that, write-then-read has
+ * been broken out into smaller bits like write-first and read-second which can
+ * be combined as needed.
+ */
+
+struct i2c_adapter_quirks {
+ u64 flags;
+ int max_num_msgs;
+ u16 max_write_len;
+ u16 max_read_len;
+ u16 max_comb_1st_msg_len;
+ u16 max_comb_2nd_msg_len;
+};
+
+/* enforce max_num_msgs = 2 and use max_comb_*_len for length checks */
+#define I2C_AQ_COMBBIT(0)
+/* first combined message must be write */
+#define I2C_AQ_COMB_WRITE_FIRSTBIT(1)
+/* second combined message must be read */
+#define I2C_AQ_COMB_READ_SECONDBIT(2)
+/* both combined messages must have the same target address */
+#define I2C_AQ_COMB_SAME_ADDR BIT(3)
+/* convenience macro for typical write-then read case */
+#define I2C_AQ_COMB_WRITE_THEN_READ(I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST
| \
+I2C_AQ_COMB_READ_SECOND |
I2C_AQ_COMB_SAME_ADDR)
+
/*
* i2c_adapter is the structure used to identify a physical i2c bus along
* with the access algorithms necessary to access it.
@@ -474,6 +516,7 @@ struct i2c_adapter {
struct list_head userspace_clients;
struct i2c_bus_recovery_info *bus_recovery_info;
+ const struct i2c_adapter_quirks *quirks;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
--
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/
[RFC V2 00/12] i2c: describe adapter quirks in a generic way
From: Wolfram Sang Here is the second version of the patch series to describe i2c adapter quirks in a generic way. For the motivation, please read description of patch 1. This is still RFC because I would like to do some more tests on my own, but I need to write a tool for that. However, I'd really like to have the driver authors to have a look already. Actual testing is very much appreciated. Thanks to the Mediatek guys for rebasing their new driver to this framework. That helps, too! The branch is also here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirks Thanks, Wolfram Major changes since V1: * more fine-grained options to describe modes with combined messages. This should also cover the Mediatek HW now as well as all other permutations I can think of. * the core code and at91 driver had to be refactored to reflect the above change * added the bcm-iproc driver which came to mainline recently Wolfram Sang (12): i2c: add quirk structure to describe adapter flaws i2c: add quirk checks to core i2c: at91: make use of the new infrastructure for quirks i2c: opal: make use of the new infrastructure for quirks i2c: qup: make use of the new infrastructure for quirks i2c: cpm: make use of the new infrastructure for quirks i2c: axxia: make use of the new infrastructure for quirks i2c: dln2: make use of the new infrastructure for quirks i2c: powermac: make use of the new infrastructure for quirks i2c: viperboard: make use of the new infrastructure for quirks i2c: pmcmsp: make use of the new infrastructure for quirks i2c: bcm-iproc: make use of the new infrastructure for quirks drivers/i2c/busses/i2c-at91.c | 32 +++ drivers/i2c/busses/i2c-axxia.c | 11 --- drivers/i2c/busses/i2c-bcm-iproc.c | 15 + drivers/i2c/busses/i2c-cpm.c| 20 ++-- drivers/i2c/busses/i2c-dln2.c | 12 +++ drivers/i2c/busses/i2c-opal.c | 22 ++--- drivers/i2c/busses/i2c-pmcmsp.c | 42 ++--- drivers/i2c/busses/i2c-powermac.c | 10 +++--- drivers/i2c/busses/i2c-qup.c| 21 ++--- drivers/i2c/busses/i2c-viperboard.c | 10 +++--- drivers/i2c/i2c-core.c | 62 + include/linux/i2c.h | 43 + 12 files changed, 191 insertions(+), 109 deletions(-) -- 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/
[RFC V2 02/12] i2c: add quirk checks to core
From: Wolfram Sang
Let the core do the checks if HW quirks prevent a transfer. Saves code
from drivers and adds consistency.
Signed-off-by: Wolfram Sang
---
drivers/i2c/i2c-core.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 210cf4874cb7ea..c5ca0e4006edb7 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1929,6 +1929,65 @@ module_exit(i2c_exit);
*
*/
+/* Check if val is exceeding the quirk IFF quirk is non 0 */
+#define i2c_quirk_exceeded(val, quirk) ((quirk) && ((val) > (quirk)))
+
+static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg, char
*err_msg)
+{
+ dev_err_ratelimited(>dev, "quirk: %s (addr 0x%04x, size %u,
%s)\n",
+ err_msg, msg->addr, msg->len,
+ msg->flags & I2C_M_RD ? "read" : "write");
+ return -EOPNOTSUPP;
+}
+
+static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg
*msgs, int num)
+{
+ const struct i2c_adapter_quirks *q = adap->quirks;
+ int max_num = q->max_num_msgs, i;
+ bool do_len_check = true;
+
+ if (q->flags & I2C_AQ_COMB) {
+ max_num = 2;
+
+ /* special checks for combined messages */
+ if (num == 2) {
+ if (q->flags & I2C_AQ_COMB_WRITE_FIRST && msgs[0].flags
& I2C_M_RD)
+ return i2c_quirk_error(adap, [0], "1st
comb msg not write");
+
+ if (q->flags & I2C_AQ_COMB_READ_SECOND &&
!(msgs[1].flags & I2C_M_RD))
+ return i2c_quirk_error(adap, [1], "2nd
comb msg not read");
+
+ if (q->flags & I2C_AQ_COMB_SAME_ADDR && msgs[0].addr !=
msgs[1].addr)
+ return i2c_quirk_error(adap, [0],
"addresses do not match");
+
+ if (i2c_quirk_exceeded(msgs[0].len,
q->max_comb_1st_msg_len))
+ return i2c_quirk_error(adap, [0], "msg too
long");
+
+ if (i2c_quirk_exceeded(msgs[1].len,
q->max_comb_2nd_msg_len))
+ return i2c_quirk_error(adap, [1], "msg too
long");
+
+ do_len_check = false;
+ }
+ }
+
+ if (i2c_quirk_exceeded(num, max_num))
+ return i2c_quirk_error(adap, [0], "too many messages");
+
+ for (i = 0; i < num; i++) {
+ u16 len = msgs[i].len;
+
+ if (msgs[i].flags & I2C_M_RD) {
+ if (do_len_check && i2c_quirk_exceeded(len,
q->max_read_len))
+ return i2c_quirk_error(adap, [i], "msg too
long");
+ } else {
+ if (do_len_check && i2c_quirk_exceeded(len,
q->max_write_len))
+ return i2c_quirk_error(adap, [i], "msg too
long");
+ }
+ }
+
+ return 0;
+}
+
/**
* __i2c_transfer - unlocked flavor of i2c_transfer
* @adap: Handle to I2C bus
@@ -1946,6 +2005,9 @@ int __i2c_transfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
unsigned long orig_jiffies;
int ret, try;
+ if (adap->quirks && i2c_check_for_quirks(adap, msgs, num))
+ return -EOPNOTSUPP;
+
/* i2c_trace_msg gets enabled when tracepoint i2c_transfer gets
* enabled. This is an efficient way of keeping the for-loop from
* being executed when not needed.
--
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/
[RFC V2 07/12] i2c: axxia: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-axxia.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index 768a598d8d03ad..488c5d3bf9dba7 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -336,11 +336,6 @@ static int axxia_i2c_xfer_msg(struct axxia_i2c_dev *idev,
struct i2c_msg *msg)
u32 addr_1, addr_2;
int ret;
- if (msg->len > 255) {
- dev_warn(idev->dev, "unsupported length %u\n", msg->len);
- return -EINVAL;
- }
-
idev->msg = msg;
idev->msg_xfrd = 0;
idev->msg_err = 0;
@@ -454,6 +449,11 @@ static const struct i2c_algorithm axxia_i2c_algo = {
.functionality = axxia_i2c_func,
};
+static struct i2c_adapter_quirks axxia_i2c_quirks = {
+ .max_read_len = 255,
+ .max_write_len = 255,
+};
+
static int axxia_i2c_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -511,6 +511,7 @@ static int axxia_i2c_probe(struct platform_device *pdev)
strlcpy(idev->adapter.name, pdev->name, sizeof(idev->adapter.name));
idev->adapter.owner = THIS_MODULE;
idev->adapter.algo = _i2c_algo;
+ idev->adapter.quirks = _i2c_quirks;
idev->adapter.dev.parent = >dev;
idev->adapter.dev.of_node = pdev->dev.of_node;
--
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/
[RFC V2 12/12] i2c: bcm-iproc: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-bcm-iproc.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index d3c89157b33774..f9f2c2082151e2 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -160,14 +160,6 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
u32 val;
unsigned long time_left = msecs_to_jiffies(I2C_TIMEOUT_MESC);
- /* need to reserve one byte in the FIFO for the slave address */
- if (msg->len > M_TX_RX_FIFO_SIZE - 1) {
- dev_err(iproc_i2c->device,
- "only support data length up to %u bytes\n",
- M_TX_RX_FIFO_SIZE - 1);
- return -EOPNOTSUPP;
- }
-
/* check if bus is busy */
if (!!(readl(iproc_i2c->base + M_CMD_OFFSET) &
BIT(M_CMD_START_BUSY_SHIFT))) {
@@ -287,6 +279,12 @@ static const struct i2c_algorithm bcm_iproc_algo = {
.functionality = bcm_iproc_i2c_functionality,
};
+static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
+ /* need to reserve one byte in the FIFO for the slave address */
+ .max_read_len = M_TX_RX_FIFO_SIZE - 1,
+ .max_write_len = M_TX_RX_FIFO_SIZE - 1,
+};
+
static int bcm_iproc_i2c_cfg_speed(struct bcm_iproc_i2c_dev *iproc_i2c)
{
unsigned int bus_speed;
@@ -413,6 +411,7 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(adap, iproc_i2c);
strlcpy(adap->name, "Broadcom iProc I2C adapter", sizeof(adap->name));
adap->algo = _iproc_algo;
+ adap->quirks = _iproc_i2c_quirks;
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;
--
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/
[RFC V2 11/12] i2c: pmcmsp: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-pmcmsp.c | 42 -
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pmcmsp.c b/drivers/i2c/busses/i2c-pmcmsp.c
index d37d9db6681e7b..2c40edbf6224eb 100644
--- a/drivers/i2c/busses/i2c-pmcmsp.c
+++ b/drivers/i2c/busses/i2c-pmcmsp.c
@@ -456,14 +456,6 @@ static enum pmcmsptwi_xfer_result pmcmsptwi_xfer_cmd(
return -EINVAL;
}
- if (cmd->read_len > MSP_MAX_BYTES_PER_RW ||
- cmd->write_len > MSP_MAX_BYTES_PER_RW) {
- dev_err(_adapter.dev,
- "%s: Cannot transfer more than %d bytes\n",
- __func__, MSP_MAX_BYTES_PER_RW);
- return -EINVAL;
- }
-
mutex_lock(>lock);
dev_dbg(_adapter.dev,
"Setting address to 0x%04x\n", cmd->addr);
@@ -520,25 +512,14 @@ static int pmcmsptwi_master_xfer(struct i2c_adapter *adap,
struct pmcmsptwi_cfg oldcfg, newcfg;
int ret;
- if (num > 2) {
- dev_dbg(>dev, "%d messages unsupported\n", num);
- return -EINVAL;
- } else if (num == 2) {
- /* Check for a dual write-then-read command */
+ if (num == 2) {
struct i2c_msg *nextmsg = msg + 1;
- if (!(msg->flags & I2C_M_RD) &&
- (nextmsg->flags & I2C_M_RD) &&
- msg->addr == nextmsg->addr) {
- cmd.type = MSP_TWI_CMD_WRITE_READ;
- cmd.write_len = msg->len;
- cmd.write_data = msg->buf;
- cmd.read_len = nextmsg->len;
- cmd.read_data = nextmsg->buf;
- } else {
- dev_dbg(>dev,
- "Non write-read dual messages unsupported\n");
- return -EINVAL;
- }
+
+ cmd.type = MSP_TWI_CMD_WRITE_READ;
+ cmd.write_len = msg->len;
+ cmd.write_data = msg->buf;
+ cmd.read_len = nextmsg->len;
+ cmd.read_data = nextmsg->buf;
} else if (msg->flags & I2C_M_RD) {
cmd.type = MSP_TWI_CMD_READ;
cmd.read_len = msg->len;
@@ -598,6 +579,14 @@ static u32 pmcmsptwi_i2c_func(struct i2c_adapter *adapter)
I2C_FUNC_SMBUS_WORD_DATA | I2C_FUNC_SMBUS_PROC_CALL;
}
+static struct i2c_adapter_quirks pmcmsptwi_i2c_quirks = {
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .max_write_len = MSP_MAX_BYTES_PER_RW,
+ .max_read_len = MSP_MAX_BYTES_PER_RW,
+ .max_comb_1st_msg_len = MSP_MAX_BYTES_PER_RW,
+ .max_comb_2nd_msg_len = MSP_MAX_BYTES_PER_RW,
+};
+
/* -- Initialization -- */
static struct i2c_algorithm pmcmsptwi_algo = {
@@ -609,6 +598,7 @@ static struct i2c_adapter pmcmsptwi_adapter = {
.owner = THIS_MODULE,
.class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
.algo = _algo,
+ .quirks = _i2c_quirks,
.name = DRV_NAME,
};
--
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: [PATCH v6 6/7] PCI: update dma configuration from DT
On 02/24/2015 08:53 PM, Bjorn Helgaas wrote: On Thu, Feb 05, 2015 at 04:52:58PM -0500, Murali Karicheri wrote: If there is a DT node available for the root bridge's parent device, use the dma configuration from that device node. For example, keystone PCI devices would require dma_pfn_offset to be set correctly in the device structure of the pci device in order to have the correct dma mask. The DT node will have dma-ranges defined for this. Also support using the DT property dma-coherent to allow coherent DMA operation by the PCI device. Hi Murali, I'm guessing this is the patch that actually fixes things for Keystone. Yes, but depends on other patches in the series. And it looks like it should also fix things for other hardware that has similar characteristics. This originally started as a patch for Keystone, but modified to apply for other platforms as well. Tested by one another platform AFAIK, by Suravee Suthikulpanit on AMD Seattle platform w/ PCI Generic Host Controller. See the Tested-By from him against this series. So I'd like to include some higher-level text about that here. For example: This fixes DMA on systems where DMA addresses are a constant offset from CPU physical addresses. That is one fix. It also update dma configuration for the device such as dma operations through a call to of_dma_configure() in 5/7. You may add the above description in 5/7. I didn't add it in the description because of_dma_configure() API call takes care of it already. (I don't know exactly how these patches all fit together, so that's probably not accurate, but that's the *sort* of thing I'd like to include.) If that actually *is* what's going on, I have to wonder why this isn't implemented as a very simple IOMMU instead of adding dma_pfn_offset, which is present on all arches but only used on ARM. In some sense that offset is parallel but incompatible with an IOMMU: they both translate DMA addresses into system RAM addresses. I don't have much history on any previous discussion on the subject you are referring to. I assume it would have happened when of_dma_configure() was first introduced. On Keystone, we don't have IOMMU support and dma_pfn_offset is needed to translate DMA address to System RAM address and vice-versa. So this has to be supported for Keystone. There can be enhancement for IOMMU with out impacting this feature for Keystone. I know that Will Deacon is working on updates for IOMMU which is partially touched by my series (1/7). Probably this can be a question when that patches comes up for review or could be a seperate discussion topic. I think it is better this series is applied to the next branch for v4.1 as soon as possible so that others can add features on top of this without breaking the function for Keystone. I am looking forward for the merge of this series to the next branch at the earliest. Thanks. Murali I know you're not adding this, and I assume somebody explored that option and rejected it for good reasons. I just missed that discussion. This patch use the new helper function of_pci_dma_configure() to update the device dma configuration. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Acked-by: Bjorn Helgaas Signed-off-by: Murali Karicheri --- drivers/pci/probe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 23212f8..d7dcd6c 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) dev->dev.dma_mask =>dma_mask; dev->dev.dma_parms =>dma_parms; dev->dev.coherent_dma_mask = 0xull; + of_pci_dma_configure(dev); pci_set_dma_max_seg_size(dev, 65536); pci_set_dma_seg_boundary(dev, 0x); -- 1.7.9.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/ -- Murali Karicheri Linux Kernel, Texas Instruments -- 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 V2 10/12] i2c: viperboard: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-viperboard.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-viperboard.c
b/drivers/i2c/busses/i2c-viperboard.c
index 7533fa34d73711..47e88adf2011e1 100644
--- a/drivers/i2c/busses/i2c-viperboard.c
+++ b/drivers/i2c/busses/i2c-viperboard.c
@@ -288,10 +288,6 @@ static int vprbrd_i2c_xfer(struct i2c_adapter *i2c, struct
i2c_msg *msgs,
i, pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->flags, pmsg->len, pmsg->addr);
- /* msgs longer than 2048 bytes are not supported by adapter */
- if (pmsg->len > 2048)
- return -EINVAL;
-
mutex_lock(>lock);
/* directly send the message */
if (pmsg->flags & I2C_M_RD) {
@@ -358,6 +354,11 @@ static const struct i2c_algorithm vprbrd_algorithm = {
.functionality = vprbrd_i2c_func,
};
+static struct i2c_adapter_quirks vprbrd_quirks = {
+ .max_read_len = 2048,
+ .max_write_len = 2048,
+};
+
static int vprbrd_i2c_probe(struct platform_device *pdev)
{
struct vprbrd *vb = dev_get_drvdata(pdev->dev.parent);
@@ -373,6 +374,7 @@ static int vprbrd_i2c_probe(struct platform_device *pdev)
vb_i2c->i2c.owner = THIS_MODULE;
vb_i2c->i2c.class = I2C_CLASS_HWMON;
vb_i2c->i2c.algo = _algorithm;
+ vb_i2c->i2c.quirks = _quirks;
vb_i2c->i2c.algo_data = vb;
/* save the param in usb capabable memory */
vb_i2c->bus_freq_param = i2c_bus_param;
--
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/
[RFC V2 09/12] i2c: powermac: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-powermac.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 60a53c169ed2b3..6abcf696e3594b 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -153,12 +153,6 @@ static int i2c_powermac_master_xfer( struct
i2c_adapter *adap,
int read;
int addrdir;
- if (num != 1) {
- dev_err(>dev,
- "Multi-message I2C transactions not supported\n");
- return -EOPNOTSUPP;
- }
-
if (msgs->flags & I2C_M_TEN)
return -EINVAL;
read = (msgs->flags & I2C_M_RD) != 0;
@@ -205,6 +199,9 @@ static const struct i2c_algorithm i2c_powermac_algorithm = {
.functionality = i2c_powermac_func,
};
+static struct i2c_adapter_quirks i2c_powermac_quirks = {
+ .max_num_msgs = 1,
+};
static int i2c_powermac_remove(struct platform_device *dev)
{
@@ -434,6 +431,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
platform_set_drvdata(dev, adapter);
adapter->algo = _powermac_algorithm;
+ adapter->quirks = _powermac_quirks;
i2c_set_adapdata(adapter, bus);
adapter->dev.parent = >dev;
--
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/
[RFC V2 06/12] i2c: cpm: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-cpm.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 2d466538b2e2c9..714bdc837769fd 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -308,22 +308,12 @@ static int cpm_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
struct i2c_reg __iomem *i2c_reg = cpm->i2c_reg;
struct i2c_ram __iomem *i2c_ram = cpm->i2c_ram;
struct i2c_msg *pmsg;
- int ret, i;
+ int ret;
int tptr;
int rptr;
cbd_t __iomem *tbdf;
cbd_t __iomem *rbdf;
- if (num > CPM_MAXBD)
- return -EINVAL;
-
- /* Check if we have any oversized READ requests */
- for (i = 0; i < num; i++) {
- pmsg = [i];
- if (pmsg->len >= CPM_MAX_READ)
- return -EINVAL;
- }
-
/* Reset to use first buffer */
out_be16(_ram->rbptr, in_be16(_ram->rbase));
out_be16(_ram->tbptr, in_be16(_ram->tbase));
@@ -424,10 +414,18 @@ static const struct i2c_algorithm cpm_i2c_algo = {
.functionality = cpm_i2c_func,
};
+/* CPM_MAX_READ is also limiting writes according to the code! */
+static struct i2c_adapter_quirks cpm_i2c_quirks = {
+ .max_num_msgs = CPM_MAXBD,
+ .max_read_len = CPM_MAX_READ,
+ .max_write_len = CPM_MAX_READ,
+};
+
static const struct i2c_adapter cpm_ops = {
.owner = THIS_MODULE,
.name = "i2c-cpm",
.algo = _i2c_algo,
+ .quirks = _i2c_quirks,
};
static int cpm_i2c_setup(struct cpm_i2c *cpm)
--
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/
[RFC V2 05/12] i2c: qup: make use of the new infrastructure for quirks
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-qup.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 4dad23bdffbe90..fdcbdab808e9fc 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -412,17 +412,6 @@ static int qup_i2c_read_one(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
unsigned long left;
int ret;
- /*
-* The QUP block will issue a NACK and STOP on the bus when reaching
-* the end of the read, the length of the read is specified as one byte
-* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
-*/
- if (msg->len > QUP_READ_LIMIT) {
- dev_err(qup->dev, "HW not capable of reads over %d bytes\n",
- QUP_READ_LIMIT);
- return -EINVAL;
- }
-
qup->msg = msg;
qup->pos = 0;
@@ -534,6 +523,15 @@ static const struct i2c_algorithm qup_i2c_algo = {
.functionality = qup_i2c_func,
};
+/*
+ * The QUP block will issue a NACK and STOP on the bus when reaching
+ * the end of the read, the length of the read is specified as one byte
+ * which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
+ */
+static struct i2c_adapter_quirks qup_i2c_quirks = {
+ .max_read_len = QUP_READ_LIMIT,
+};
+
static void qup_i2c_enable_clocks(struct qup_i2c_dev *qup)
{
clk_prepare_enable(qup->clk);
@@ -670,6 +668,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(>adap, qup);
qup->adap.algo = _i2c_algo;
+ qup->adap.quirks = _i2c_quirks;
qup->adap.dev.parent = qup->dev;
qup->adap.dev.of_node = pdev->dev.of_node;
strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name));
--
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: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns
On Wed, 25 Feb 2015 16:40:49 +0100 Denys Vlasenko wrote: > >> The downside would be that if we ever grow past 1024 > >> syscall entries we'll be in trouble if new userspace calls > >> syscall 513 on an old kernel and gets syscall 1. > > > > What if we test against ~0x3ff and jump to sys_ni if anything is set. > > This would still work with new userspace calls on older kernels. > > That would require a branch insn. The whole idea of masking > was merely to avoid that branch. If you need a branch, > then you can as well just retain current code. I'm just curious, do all these micro optimizations have any real impact on real use cases? That is, if we are going to make the system less robust, shouldn't we show that it has real benefit? And yes, I consider user space passing in a system call of 0x401 and having it work the same as 0x1 as being less robust. -- Steve -- 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/
b4eef9b36db4 ("kvm: x86: vmx: NULL out hwapic_isr_update() in case of !enable_apicv")
Hi, commit in $Subject breaks my kvm guest on AMD host, causing it to do the following below. Mouse doesn't work anymore in the guest, network is gone too. Reverting it fixes the issue. --- ... [4.849095] Freeing unused kernel memory: 2972K (81aee000 - 81dd5000) [7.016259] random: nonblocking pool is initialized [7.323793] udevd[861]: starting version 175 [7.592220] usb 1-1: New USB device found, idVendor=0627, idProduct=0001 [7.595710] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [7.621394] usb 1-1: Product: QEMU USB Tablet [7.623522] usb 1-1: Manufacturer: QEMU [7.623525] usb 1-1: SerialNumber: 42 [9.577403] input: QEMU QEMU USB Tablet as /devices/pci:00/:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input3 [9.613569] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU QEMU USB Tablet] on usb-:00:01.2-1/input0 [9.626452] WARNING! power/level is deprecated; use power/control instead [ 11.260824] Adding 917500k swap on /dev/sda2. Priority:-1 extents:1 across:917500k [ 12.004418] EXT3-fs (sda1): using internal journal [ 26.336196] 8139cp :00:03.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 [ 28.773323] mtrr: no MTRR for fc00,10 found [ 32.816498] [ cut here ] [ 32.819112] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x247/0x250() [ 32.823695] NETDEV WATCHDOG: eth0 (8139cp): transmit queue 0 timed out [ 32.827693] Modules linked in: [ 32.829830] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.18.0 #11 [ 32.832562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 32.835844] 0009 88007c403d18 816fbc75 [ 32.838565] 88007c403d68 88007c403d58 8105822c 88007c403d38 [ 32.841197] 0001 88007bf5a680 88007b4c6000 [ 32.843733] Call Trace: [ 32.844510][] dump_stack+0x4f/0x7c [ 32.846476] [] warn_slowpath_common+0x8c/0xc0 [ 32.848476] [] warn_slowpath_fmt+0x46/0x50 [ 32.850279] [] dev_watchdog+0x247/0x250 [ 32.851950] [] ? dev_graft_qdisc+0x90/0x90 [ 32.853930] [] call_timer_fn+0xbd/0x500 [ 32.856086] [] ? call_timer_fn+0x5/0x500 [ 32.858996] [] ? dev_graft_qdisc+0x90/0x90 [ 32.861821] [] ? dev_graft_qdisc+0x90/0x90 [ 32.864966] [] run_timer_softirq+0x2b4/0x4c0 [ 32.867724] [] __do_softirq+0x167/0x6c0 [ 32.869367] [] irq_exit+0x96/0xc0 [ 32.870782] [] smp_apic_timer_interrupt+0x4a/0x60 [ 32.872654] [] apic_timer_interrupt+0x6f/0x80 [ 32.874408][] ? native_safe_halt+0x6/0x10 [ 32.876354] [] ? trace_hardirqs_on+0xd/0x10 [ 32.878247] [] default_idle+0x20/0x260 [ 32.880167] [] arch_cpu_idle+0xf/0x20 [ 32.882518] [] cpu_startup_entry+0x4ef/0x6a0 [ 32.885022] [] ? _raw_spin_unlock_irqrestore+0x53/0xa0 [ 32.888341] [] ? clockevents_register_device+0xbc/0x120 [ 32.891748] [] start_secondary+0x193/0x1a0 [ 32.893524] ---[ end trace 1bcb92948e89c39f ]--- [ 32.895203] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b4 80ff [ 44.816516] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b4 80ff [ 56.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b4 80ff [ 68.816513] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 80.816510] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 92.816513] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 104.816513] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 116.816512] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 128.816512] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 140.816508] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 152.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 164.816518] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 176.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 188.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 200.816514] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 212.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 224.816514] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 236.816514] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 248.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 260.816512] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 272.816515] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5 80ff [ 284.816512] 8139cp :00:03.0 eth0: Transmit timeout, status d 3b5
Re: [PATCH V6 00/12] Tegra xHCI support
On Mon, Nov 24, 2014 at 04:17:12PM -0800, Andrew Bresticker wrote: > This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: > - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, > - patches 4 and 5: adding a driver for the mailbox used to communicate >with the xHCI controller's firmware, > - patches 6 and 7: extending the XUSB pad controller driver to support >the USB PHY types (UTMI, HSIC, and USB3), > - patches 8 and 9: adding a xHCI host-controller driver, and > - patches 10, 11, and 12: updating the relevant DT files. > > The mailbox driver (patch 5) has a compile-time dependency on patch 2 and > a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) > drivers have compile-time dependencies on the mailbox driver. The host > driver also has a run-time dependency on patch 1. Because of this, this > entire series should probably go through the Tegra tree. Patches 11 and 12 > should probably not be merged until the controller firmware [0] lands in > linux-firmware since they disable the EHCI controllers. > > Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and > USB3.0 memory sticks and ethernet dongles. This has also been tested, > with additional out-of-tree patches, on a Tegra132-based board. > > Based on v3.18-rc6. A branch with the entire series is available at: > https://github.com/abrestic/linux/tree/tegra-xhci-v6 > > Notes: > - HSIC support is mostly untested and I think there are still some issues >to work out there. I do have a Tegra124 board with a HSIC hub so I'll >try to sort those out later. > - The XUSB padctl driver doesn't play nice with the existing Tegra USB2.0 >PHY driver, so all ports should be assigned to the XHCI controller. > > Based on work by: > a lot of people, but from what I can tell from the L4T tree [1], the > original authors of the Tegra xHCI driver are: > Ajay Gupta > Bharath Yadav > > [0] https://patchwork.ozlabs.org/patch/400110/ > [1] git://nv-tegra.nvidia.com/linux-3.10.git > > Changes from v5: > - Addressed review comments from Jassi and Felipe. > > Changes from v4: > - Made USB support optional in padctl driver. > - Made usb3-port a pinconfig property again. > - Cleaned up mbox_request_channel() error handling and allowed it to defer >probing (patch 3). > - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested >by Thierry. > - Addressed Thierry's review comments. > > Changes from v3: > - Fixed USB2.0 flakiness on Jetson-TK1. > - Switched to 32-bit DMA mask for host. > - Addressed Stephen's review comments. > > Chagnes from v2: > - Dropped mailbox channel specifier. The mailbox driver allocates virtual >channels backed by the single physical channel. > - Added support for HS_CURR_LEVEL adjustment pinconfig property, which >will be required for the Blaze board. > - Addressed Stephen's review comments. > > Changes from v1: > - Converted mailbox driver to use the common mailbox framework. > - Fixed up host driver so that it can now be built and used as a module. > - Addressed Stephen's review comments. > - Misc. cleanups. > > Andrew Bresticker (11): > xhci: Set shared HCD's hcd_priv in xhci_gen_setup > mailbox: Make struct mbox_controller's ops field const > of: Add NVIDIA Tegra XUSB mailbox binding > mailbox: Add NVIDIA Tegra XUSB mailbox driver > of: Update Tegra XUSB pad controller binding for USB > pinctrl: tegra-xusb: Add USB PHY support > of: Add NVIDIA Tegra xHCI controller binding > usb: xhci: Add NVIDIA Tegra xHCI host-controller driver > ARM: tegra: jetson-tk1: Add xHCI support > ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller > ARM: tegra: venice2: Add xHCI support > > Benson Leung (1): > mailbox: Fix up error handling in mbox_request_channel() > > .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 + > .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 63 +- > .../bindings/usb/nvidia,tegra124-xhci.txt | 104 ++ > arch/arm/boot/dts/tegra124-jetson-tk1.dts | 46 +- > arch/arm/boot/dts/tegra124-venice2.dts | 79 +- > arch/arm/boot/dts/tegra124.dtsi| 41 + > drivers/mailbox/Kconfig|3 + > drivers/mailbox/Makefile |2 + > drivers/mailbox/mailbox.c | 11 +- > drivers/mailbox/tegra-xusb-mailbox.c | 278 + > drivers/pinctrl/Kconfig|1 + > drivers/pinctrl/pinctrl-tegra-xusb.c | 1262 > +++- > drivers/usb/host/Kconfig | 10 + > drivers/usb/host/Makefile |1 + > drivers/usb/host/xhci-pci.c|5 - > drivers/usb/host/xhci-plat.c |5 - > drivers/usb/host/xhci-tegra.c | 931 +++ >
Re: [Xen-devel] [PATCH 06/13] xen: detect pre-allocated memory interfering with e820 map
On 02/25/2015 03:24 PM, David Vrabel wrote:
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsigned i;
+
+for (i = 0; i < XEN_N_RESERVED_AREAS; i++) {
+
+if (!xen_reserved_area[i].size)
+break;
+
+area_start = PFN_DOWN(xen_reserved_area[i].start);
+area_end = PFN_UP(xen_reserved_area[i].start +
+ xen_reserved_area[i].size);
+if (area_start >= end_pfn || area_end <= start_pfn)
+continue;
+
+if (area_start > start_pfn)
+xen_set_identity_and_remap_chunk(start_pfn, area_start,
+ released, remapped);
+
+if (area_end < end_pfn)
+xen_set_identity_and_remap_chunk(area_end, end_pfn,
+ released, remapped);
+
+*remapped += min(area_end, end_pfn) -
+max(area_start, start_pfn);
+
+return;
Why not defer the whole chunk that conflicts? Or for that matter defer
all this remapping to the last minute.
There are two problems arising from this:
- In the initrd case remapping would be deferred too long: the initrd
data is still in use when device initialization is running. And we
really want the remap to have happened before PCI space is being used.
I'm not sure I understand what you're saying here.
I thought you wanted to defer the remapping to the point where the
initrd memory is no longer being used. But the suggestion below is
more clear.
I'm suggesting:
1. Reserve all holes.
2. Relocate (if necessary) all modules (initrd, etc.) to regions that
are RAM in the e820.
3. Rebuild the p2m in RAM.
4. Relocate frames from E820 holes/reserved to the end, free p2m pages
from the holes and replacing them with the read-only 1:1 page (where
possible).
- Delaying all remapping to the point where the new p2m list is in place
would either result in a p2m list with all memory holes covered with
individual entries as the new list is built with those holes still
populated, ...
The first option could easily waste significant amounts of memory (on
my test machine with 1TB RAM this would have been about 1GB), while
the second option would be performance critical.
I don't understand how this wastes memory. When you relocate the
frames from the holes you can reclaim the p2m pages for the holes (and
replace them with the r/o mapped identity p2m page).
Okay, this would work, I guess.
I'll have a try with some new patches...
Juergen
--
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] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
> This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
> instructions. It also fixes an asm comment for __cmpxchg2.
>
> Currently using a half-word xchg() results in the following splat on an ARMv7
> machine.
>
> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
> [ 45.833324] [ cut here ]
> [ 45.837939] kernel BUG at
> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
>
> Signed-off-by: Pranith Kumar
Unfortunately, the BUG message seems incomplete, can you reproduce this
with CONFIG_DEBUG_BUGVERBOSE enabled?
> arch/arm/include/asm/cmpxchg.h | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
> index abb2c37..9505cca 100644
> --- a/arch/arm/include/asm/cmpxchg.h
> +++ b/arch/arm/include/asm/cmpxchg.h
> @@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void *ptr, int size
> : "r" (x), "r" (ptr)
> : "memory", "cc");
> break;
> + case 2:
> + asm volatile("@ __xchg2\n"
> + "1: ldrexh %0, [%3]\n"
> + " strexh %1, %2, [%3]\n"
> + " teq %1, #0\n"
> + " bne 1b"
> + : "=" (ret), "=" (tmp)
> + : "r" (x), "r" (ptr)
> + : "memory", "cc");
> + break;
> case 4:
> asm volatile("@ __xchg4\n"
> "1: ldrex %0, [%3]\n"
Does this work on all ARMv6 or just ARMv6k?
Arnd
--
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] sched/rt: Use IPI to trigger RT task push migration instead of pulling
On Wed, 25 Feb 2015 11:35:35 +0100
Peter Zijlstra wrote:
> On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> > Index: linux-rt.git/kernel/sched/rt.c
> > ===
> > --- linux-rt.git.orig/kernel/sched/rt.c 2015-02-24 10:44:08.798785452
> > -0500
> > +++ linux-rt.git/kernel/sched/rt.c 2015-02-24 13:07:20.154735448 -0500
>
> > @@ -1760,11 +1771,171 @@ static void push_rt_tasks(struct rq *rq)
> > ;
> > }
> >
> > +static void tell_cpu_to_push(int cpu, struct rq *rq, int prio)
> > +{
> > + /* We should never be here if the IPI is already out. */
> > + BUG_ON(rq->rt.push_csd_pending);
> > +
> > + rq->rt.push_csd_pending = 1;
> > + rq->rt.push_csd_cpu = cpu;
> > + /* Save the prio that we used to find this CPU */
> > + rq->rt.push_csd_prio = prio;
> > +
> > + /* Make sure csd_cpu is visible before we send the ipi */
> > + smp_mb();
>
> We've architecturally defined the raising of interrupts vs the execution
> of the handler to be a serializing event, therefore this full barrier is
> not required.
>
> I think we documented it in places, but I never can find it.
>
> > +
> > + smp_call_function_single_async(cpu, >rt.push_csd);
>
> I'm confused why are you mixing smp_call_function_single_async() and
> irq_work_queue_on() in the same logic?
I originally started with smp_call_function_single_async(), but found
that it takes csd locks and holds them while the functions are
executed. Meaning, you can not call another
smp_call_function_single_async() from within a previous call. I left
the code that starts the IPI as the smp_call_function but changed the
internal calls to use irq_queue_work_on(). I guess I can switch all to
just use that if you want only one, as the
smp_call_function_single_async() is not even an option.
>
> Pick one and stick to it.
>
> Also:
> lkml.kernel.org/r/ca+55afz492bzlfhdbkn-hygjcreup7cjmeyk3ntsfrwjppz...@mail.gmail.com
Ah that would have helped. I talked about doing this too in the past.
I think I mentioned it to you on IRC.
But I believe this still requires the user making sure the original
call is synchronized, which breaks making a change for you below. I'll
discuss that further down.
>
> Now I would suggest you use irq_wok_queue_on() for this, consistently,
> because irq_works are ran after the smp function calls complete and
> therefore minimize the latency for people waiting on the (sync) smp
> function calls.
Well, we still want the pull to happen as fast as possible. But sure,
I get your point.
>
> > +}
> > +
> > +static void try_to_push_tasks(void *arg)
> > +{
> > + struct rt_rq *rt_rq = arg;
> > + struct rq *rq, *next_rq;
> > + int next_cpu = -1;
> > + int next_prio = MAX_PRIO + 1;
> > + int this_prio;
> > + int src_prio;
> > + int prio;
> > + int this_cpu;
> > + int success;
> > + int cpu;
> > +
> > + /* Make sure we can see csd_cpu */
> > + smp_rmb();
>
> As per the above, interrupt are serializing, this is not needed.
Because entering an interrupt is a serializing point with other CPUs?
>
> > +
> > + this_cpu = rt_rq->push_csd_cpu;
> > +
> > + /* Paranoid check */
> > + BUG_ON(this_cpu != smp_processor_id());
> > +
> > + rq = cpu_rq(this_cpu);
> > +
> > + /*
> > +* If there's nothing to push here, then see if another queue
> > +* can push instead.
> > +*/
> > + if (!has_pushable_tasks(rq))
> > + goto pass_the_ipi;
> > +
> > + raw_spin_lock(>lock);
> > + success = push_rt_task(rq);
> > + raw_spin_unlock(>lock);
> > +
> > + if (success)
> > + goto done;
> > +
> > + /* Nothing was pushed, try another queue */
> > +pass_the_ipi:
> > +
> > + /*
> > +* We use the priority that determined to send to this CPU
> > +* even if the priority for this CPU changed. This is used
> > +* to determine what other CPUs to send to, to keep from
> > +* doing a ping pong from each CPU.
> > +*/
> > + this_prio = rt_rq->push_csd_prio;
> > + src_prio = rt_rq->highest_prio.curr;
>
> Should we, at this point, not check if the condition that triggered the
> pull request is still valid on our src cpu? No point in continuing our
> IPI chain if the CPU we're looking for work for is no longer interested
> in it.
But how do we know that?
I added logic here to do exactly that, but then realized I need to keep
track of too much information. The pull happens when the rq schedules a
task of lower priority. That new task can still be an RT task. To know
we do not need to do the pull, we need to keep track of what the
original priority was.
Hmm, but that said, we can add an optimization here and do this:
if (src_prio <= this_prio)
goto done;
As "this_prio" is what we saw that we could pull. Thus, if the rq that
is asking to do the pull schedules a task that is equal or higher in
priority than the highest rq it sent a pull request for, then we do not
need
Re: [PATCH 4/6] ARM: DT: STi: STiH407: Add dwc3 usb3 DT node.
On Wed, 25 Feb 2015, Peter Griffin wrote: > Hi Lee, > > On Wed, 25 Feb 2015, Lee Jones wrote: > > > > + resets = < STIH407_USB3_POWERDOWN>, > > > + < STIH407_MIPHY2_SOFTRESET>; > > > + reset-names = "powerdown", > > > + "softreset"; > > > > Nit: What's the purpose of having these on separate lines? > > The only reason was to stay aligned with the example in > Documentation/devicetree/bindings/usb/dwc3-st.txt. But didn't you author that too? :) I would change them both. No need to force a line wrap if it's not required. -- 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/
Re: [PATCH v3] mfd: arizona: Move useful defines into a dt-binding include
On Wed, 25 Feb 2015, Charles Keepax wrote:
> Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
> the dt-binding directory for use by device tree bindings. This also
> makes gpio.h redundant so remove it in the process.
>
> Signed-off-by: Charles Keepax
> Acked-by: Mark Brown
> Acked-by: Rob Herring
> ---
>
> Changes since v2:
> - Generate patch using git format-patch -M
>
> Documentation/devicetree/bindings/mfd/arizona.txt | 20 +++---
> .../arizona/gpio.h => dt-bindings/mfd/arizona.h} | 67 +--
> include/linux/mfd/arizona/pdata.h | 22 +--
> sound/soc/codecs/arizona.c |1 -
> 4 files changed, 44 insertions(+), 66 deletions(-)
> rename include/{linux/mfd/arizona/gpio.h => dt-bindings/mfd/arizona.h} (54%)
Much better, thanks.
Patch applied.
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index 7bd1273..bfef000 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -36,11 +36,11 @@ Optional properties:
>- wlf,reset : GPIO specifier for the GPIO controlling /RESET
>- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
>
> - - wlf,gpio-defaults : A list of GPIO configuration register values. If
> -absent, no configuration of these registers is performed. If any
> -entry has a value that is out of range for a 16 bit register then
> -the chip default will be used. If present exactly five values must
> -be specified.
> + - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
> +for the appropriate values can found in . If
> +absent, no configuration of these registers is performed. If any entry
> has
> +a value that is out of range for a 16 bit register then the chip default
> +will be used. If present exactly five values must be specified.
>
>- wlf,inmode : A list of INn_MODE register values, where n is the number
> of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
> @@ -73,10 +73,10 @@ codec: wm5102@1a {
> #gpio-cells = <2>;
>
> wlf,gpio-defaults = <
> - 0x /* AIF1TXLRCLK */
> - 0x
> - 0x
> - 0x
> - 0x
> + ARIZONA_GP_FN_TXLRCLK
> + ARIZONA_GP_DEFAULT
> + ARIZONA_GP_DEFAULT
> + ARIZONA_GP_DEFAULT
> + ARIZONA_GP_DEFAULT
> >;
> };
> diff --git a/include/linux/mfd/arizona/gpio.h
> b/include/dt-bindings/mfd/arizona.h
> similarity index 54%
> rename from include/linux/mfd/arizona/gpio.h
> rename to include/dt-bindings/mfd/arizona.h
> index d2146bb..c7af7c7 100644
> --- a/include/linux/mfd/arizona/gpio.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -1,7 +1,7 @@
> /*
> - * GPIO configuration for Arizona devices
> + * Device Tree defines for Arizona devices
> *
> - * Copyright 2013 Wolfson Microelectronics. PLC.
> + * Copyright 2015 Cirrus Logic Inc.
> *
> * Author: Charles Keepax
> *
> @@ -10,9 +10,10 @@
> * published by the Free Software Foundation.
> */
>
> -#ifndef _ARIZONA_GPIO_H
> -#define _ARIZONA_GPIO_H
> +#ifndef _DT_BINDINGS_MFD_ARIZONA_H
> +#define _DT_BINDINGS_MFD_ARIZONA_H
>
> +/* GPIO Function Definitions */
> #define ARIZONA_GP_FN_TXLRCLK0x00
> #define ARIZONA_GP_FN_GPIO 0x01
> #define ARIZONA_GP_FN_IRQ1 0x02
> @@ -61,36 +62,32 @@
> #define ARIZONA_GP_FN_SYSCLK_ENA_STATUS 0x4B
> #define ARIZONA_GP_FN_ASYNCCLK_ENA_STATUS0x4C
>
> -#define ARIZONA_GPN_DIR 0x8000 /* GPN_DIR */
> -#define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
> -#define ARIZONA_GPN_DIR_SHIFT15 /* GPN_DIR */
> -#define ARIZONA_GPN_DIR_WIDTH 1 /* GPN_DIR */
> -#define ARIZONA_GPN_PU 0x4000 /* GPN_PU */
> -#define ARIZONA_GPN_PU_MASK 0x4000 /* GPN_PU */
> -#define ARIZONA_GPN_PU_SHIFT 14 /* GPN_PU */
> -#define ARIZONA_GPN_PU_WIDTH 1 /* GPN_PU */
> -#define ARIZONA_GPN_PD 0x2000 /* GPN_PD */
> -#define ARIZONA_GPN_PD_MASK 0x2000 /* GPN_PD */
> -#define ARIZONA_GPN_PD_SHIFT 13 /* GPN_PD */
> -#define ARIZONA_GPN_PD_WIDTH 1 /* GPN_PD */
> -#define ARIZONA_GPN_LVL 0x0800 /* GPN_LVL */
> -#define ARIZONA_GPN_LVL_MASK 0x0800 /* GPN_LVL */
> -#define ARIZONA_GPN_LVL_SHIFT11 /* GPN_LVL */
> -#define ARIZONA_GPN_LVL_WIDTH 1 /* GPN_LVL */
> -#define ARIZONA_GPN_POL 0x0400 /* GPN_POL */
> -#define
Re: [PATCH v2 3/4] clk: Provide an always-on clock domain framework
On Wed, 25 Feb 2015, Rob Herring wrote:
> On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette
> wrote:
> > Quoting Lee Jones (2015-02-18 08:15:00)
> >> Much h/w contain clocks which if turned off would prove fatal. The
> >> only way to recover is to restart the board(s). This driver takes
> >> references to clocks which are required to be always-on in order to
> >> prevent the common clk framework from trying to turn them off during
> >> the clk_disabled_unused() procedure.
>
> [...]
>
> >> +static int ao_clock_domain_probe(struct platform_device *pdev)
> >> +{
> >> + struct device_node *np = pdev->dev.of_node;
> >> + int nclks, i;
> >> +
> >> + nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> >
> > Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
> > minutes writing that function and I need people to use it so I can get a
> > return on my investment.
> >
> > Otherwise the patch looks good. I believe that this method is targeting
> > always-on clock in a production environment, which is different from the
> > CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
> > hardware or dealing with a platform that has incomplete driver support.
>
> There is also the usecase of keep clocks on until I load a module that
> properly handles my hardware (e.g simplefb). We have a simplefb node
> with clocks and the simplefb driver jumps thru some hoops to hand-off
> clocks to the real driver. I don't really like it and don't want to
> see more examples. And there is the case of I thought I would never
> manage this clock, but kernel subsystems evolve and now I want to
> manage a clock. This should not require a DT update to do so.
>
> Neither of these may be Lee's usecase, but I want to see them covered
> by the binding.
>
> > I wonder if there is a clever way for existing clock providers
> > (expressed in DT) to use this without having to create a separate node
> > of clocks with the "always-on-clk-domain" flag. Possibly the common
> > clock binding could declare some always-on flag that is standardized?
> > Then the framework core could use this code easily. Not sure if that is
> > a good idea though...
>
> I would prefer to see the always on clocks just listed within the
> clock controller's node rather than creating made up nodes with clock
> properties.
> This should be always-on until claimed IMO, but that
> aspect is the OS's problem, not a DT problem.
I disagree with this point. There are likely to be many unclaimed,
but perfectly gateable clocks in a system, which will consume power
unnecessarily. The clk framework does the right thing by turning all
unclaimed clocks off IMHO. This only leaves a small use-case where we
need to artificially claim some which must not be gated.
The other way to do is, as you mentioned is list the clocks which must
stay on in the clock source node, but this will still require a
binding. It will also require a much more complicated framework
driver.
clkprovider@ {
always-on-clks = <1, 2, 4, 5, 7>;
};
--
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 v5 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <_alert1>;
+cooling-device = < 7 7>;
+ };
+ map1 {
+trip = <_alert2>;
+cooling-device = < 13 13>;
+ };
+ map2 {
+trip = <_alert0>;
+cooling-device = < 0 1>;
+ };
+ map3 {
+trip = <_alert1>;
+cooling-device = < 1 2>;
+ };
+ map4 {
+trip = <_alert2>;
+cooling-device = < 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
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/2] epoll: introduce EPOLLEXCLUSIVE and EPOLLROUNDROBIN
On 02/21/2015 07:24 PM, Eric Wong wrote: > Jason Baron wrote: >> On 02/18/2015 12:51 PM, Ingo Molnar wrote: >>> * Ingo Molnar wrote: >>> > [...] However, I think the userspace API change is less > clear since epoll_wait() doesn't currently have an > 'input' events argument as epoll_ctl() does. ... but the change would be a bit clearer and somewhat more flexible: LIFO or FIFO queueing, right? But having the queueing model as part of the epoll context is a legitimate approach as well. >>> Btw., there's another optimization that the networking code >>> already does when processing incoming packets: waking up a >>> thread on the local CPU, where the wakeup is running. >>> >>> Doing the same on epoll would have real scalability >>> advantages where incoming events are IRQ driven and are >>> distributed amongst multiple CPUs. >>> >>> Where events are task driven the scheduler will already try >>> to pair up waker and wakee so it might not show up in >>> measurements that markedly. >>> >> Right, so this makes me think that we may want to potentially >> support a variety of wakeup policies. Adding these to the >> generic wake up code is just going to be too messy. So, perhaps >> a better approach here would be to register a single >> wait_queue_t with the event source queue that will always >> be woken up, and then layer any epoll balancing/irq affinity >> policies on top of that. So in essence we end up with sort of >> two queues layers, but I think it provides much nicer isolation >> between layers. Also, the bulk of the changes are going to be >> isolated to the epoll code, and we avoid Andy's concern about >> missing, or starving out wakeups. >> >> So here's a stab at how this API could look: >> >> 1. ep1 = epoll_create1(EPOLL_POLICY); >> >> So EPOLL_POLICY here could the round robin policy described >> here, or the irq affinity or other ideas. The idea is to create >> an fd that is local to the process, such that other processes >> can not subsequently attach to it and affect our policy. > I'm not against defining more policies if needed. > Maybe FIFO vs LIFO is a good case for this. > > For affinity, it could probably be done transparently based on > epoll_wait retrievals + EPOLL_CTL_MOD operations. > >> 2. epoll_ctl(ep1, EPOLL_CTL_ADD, fd_source, NULL); >> >> This associates ep1 with the event source. ep1 can be >> associated with or added to at most 1 wakeup source. This call >> would largely just form the association, but not queue anything >> to the fd_source wait queue. > This would mean one extra FD for every fd_source, but that's > only a handful of FDs (listen sockets), correct? Yes, one extra epoll fd per shared wakeup source, so this should result in very few additional fds. >> 3. epoll_ctl(ep2, EPOLL_CTL_ADD, ep1, event); >> epoll_ctl(ep3, EPOLL_CTL_ADD, ep1, event); >> epoll_ctl(ep4, EPOLL_CTL_ADD, ep1, event); >> . >> . >> . >> >> Finally, we add the epoll sets to the event source (indirectly via >> ep1). So the first add would actually queue the callback to the >> fd_source. While the subsequent calls would simply queue things >> to the 'nested' wakeup queue associated with ep1. > I'm not sure I follow, wouldn't this increase the number of wakeups? I agree, my text there is confusing...I've posted this idea as v3 of this series, so hopefully that clarifies this approach. Thanks, -Jason -- 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 0/2] x86/arm64: add xenconfig
On 2015-02-10 23:32, Paul Bolle wrote: > On Tue, 2015-02-10 at 14:21 -0800, David Rientjes wrote: >> We need an update to the MAINTAINERS file if "Yann E. MORIN" >> isn't the active Kconfig maintainer anymore. > > Yes, we do. Michal, what update would you suggest? I'll revert the patch that added Yann. That is, change the contact back to me and the status to "Odd fixes". 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] thermal: intel Quark SoC X1000 DTS thermal driver
>-Original Message-
>From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>ow...@vger.kernel.org] On Behalf Of Ong, Boon Leong
>Sent: Monday, February 23, 2015 9:39 AM
>To: Kweh, Hock Leong; Zhang, Rui; edubez...@gmail.com
>Cc: linux...@vger.kernel.org; LKML; Bryan O'Donoghue
>Subject: RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver
>
>>> +static struct soc_sensor_entry *alloc_soc_dts(void)
>>> +{
>>> + struct soc_sensor_entry *aux_entry;
>>> + int err;
>>> + u32 out;
>>> + int wr_mask;
>>> +
>>> + aux_entry = kzalloc(sizeof(*aux_entry), GFP_KERNEL);
>>
>>Wondering is it possible to use the resource-managed functions (for e.g.
>>devm_kzalloc())? This could help the driver looks more neat and clean
>>where the resource-managed framework will help you take care all the
>>kfree().
>>
>>Understand that the flow here is to call the thermal_zone_device_register()
>>function after this aux_entry allocation.
>>
>>But thinking would it also working if change the flow to call
>>thermal_zone_device_register() function 1st to obtain the
>>thermal_zone_device
>>then later on perform devm_kzalloc() and assign it back to devdata.
>>
>Ok, it is worth exploring on this devm_kzalloc() for neatness.
I give it a thought again and I think that devm_kzalloc() is only useful
if the thermal driver is platform driver. So, for Quark thermal driver,
this will not be useful. So, the existing kzalloc() method is sufficient.
--
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 5/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
* Roger Quadros [150225 05:28]: > On 24/02/15 22:05, Robert ABEL wrote: > > DTS output was formatted to require additional work when copy-pasting into > > DTS. > > Nano-second timings were removed, because they were not a confidence > > interval nor > > an indication what timing values would result in the same #ticks > > If they were not is it possible to dump min,max timings that will result in > the same ticks? Yeah my plan was o display the nanosecond range resulting in the same tick value. That makes it a bit easier to compare the timings to the data sheet. So maybe show both tick and ns range? Ideally the timings would be from the device data sheet with the latency added for components that are on the line in addition to the device, such as level shifters and FPGA. Regards, Tony -- 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] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 16:11:27 +0100 Cornelia Huck wrote: > On Wed, 25 Feb 2015 15:36:02 +0100 > "Michael S. Tsirkin" wrote: > > > virtio balloon has this code: > > wait_event_interruptible(vb->config_change, > > (diff = towards_target(vb)) != 0 > > || vb->need_stats_update > > || kthread_should_stop() > > || freezing(current)); > > > > Which is a problem because towards_target() call might block after > > wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing > > the task_struct::state collision typical of nesting of sleeping > > primitives > > > > See also http://lwn.net/Articles/628628/ or Thomas's > > bug report > > http://article.gmane.org/gmane.linux.kernel.virtualization/24846 > > for a fuller explanation. > > > > To fix, rewrite using wait_woken. > > > > Cc: sta...@vger.kernel.org > > Reported-by: Thomas Huth > > Signed-off-by: Michael S. Tsirkin > > --- > > > > changes from v1: > > remove wait_event_interruptible > > noticed by Cornelia Huck > > > > drivers/virtio/virtio_balloon.c | 19 ++- > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > I was able to reproduce Thomas' original problem and can confirm that > it is gone with this patch. > > Reviewed-by: Cornelia Huck Right, I just applied the patch on my system, too, and the problem is indeed gone! Thanks for the quick fix! Tested-by: Thomas Huth -- 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] arm: asm/cmpxchg.h: Add support half-word xchg()
This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
instructions. It also fixes an asm comment for __cmpxchg2.
Currently using a half-word xchg() results in the following splat on an ARMv7
machine.
[ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
Signed-off-by: Pranith Kumar
---
arch/arm/include/asm/cmpxchg.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index abb2c37..9505cca 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x, volatile
void *ptr, int size
: "r" (x), "r" (ptr)
: "memory", "cc");
break;
+ case 2:
+ asm volatile("@ __xchg2\n"
+ "1: ldrexh %0, [%3]\n"
+ " strexh %1, %2, [%3]\n"
+ " teq %1, #0\n"
+ " bne 1b"
+ : "=" (ret), "=" (tmp)
+ : "r" (x), "r" (ptr)
+ : "memory", "cc");
+ break;
case 4:
asm volatile("@ __xchg4\n"
"1: ldrex %0, [%3]\n"
@@ -93,6 +103,12 @@ static inline unsigned long __xchg(unsigned long x,
volatile void *ptr, int size
: "memory", "cc");
break;
#endif
+ case 2:
+ raw_local_irq_save(flags);
+ ret = *(volatile uint16_t *)ptr;
+ *(volatile uint16_t *)ptr = x;
+ raw_local_irq_restore(flags);
+ break;
default:
__bad_xchg(ptr, size), ret = 0;
break;
@@ -158,7 +174,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
break;
case 2:
do {
- asm volatile("@ __cmpxchg1\n"
+ asm volatile("@ __cmpxchg2\n"
" ldrexh %1, [%2]\n"
" mov %0, #0\n"
" teq %1, %3\n"
--
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] perf, tools, record: Support recording running/enabled time
Em Wed, Feb 25, 2015 at 04:13:06PM +0100, Jiri Olsa escreveu: > On Tue, Feb 24, 2015 at 03:13:40PM -0800, Andi Kleen wrote: > > From: Andi Kleen > > > > Add an option to perf record to record running/enabled time > > for read events, similar to what stat does. > > > > This is useful to understand multiplexing problems. > > > > Right now the report support is not great, but at least > > report -D already supports it. > > yep, report -D displays it nicely > > Acked-by: Jiri Olsa Thanks, applied. - Arnaldo -- 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/4] x86: entry.S: tidy up several suboptimal insns
On Wed, Feb 25, 2015 at 3:43 PM, Steven Rostedt wrote: > On Wed, 25 Feb 2015 10:20:43 +0100 Ingo Molnar wrote: >> But, if we do that, we can do even better, and also do an >> optimization of the 64-bit entry path as well: we could >> simply mask RAX with 0x3ff and not do a compare. Pad the >> syscall table up to 0x400 (1024) entries and fill in the >> table with sys_ni syscall entries. >> >> This is valid on 64-bit and 32-bit kernels as well, and it >> allows the removal of a compare from the syscall entry >> path, at the cost of a couple of kilobytes of unused >> syscall table. >> >> The downside would be that if we ever grow past 1024 >> syscall entries we'll be in trouble if new userspace calls >> syscall 513 on an old kernel and gets syscall 1. > > What if we test against ~0x3ff and jump to sys_ni if anything is set. > This would still work with new userspace calls on older kernels. That would require a branch insn. The whole idea of masking was merely to avoid that branch. If you need a branch, then you can as well just retain current code. -- 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] mfd: arizona: Move useful defines into a dt-binding include
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax
Acked-by: Mark Brown
Acked-by: Rob Herring
---
Changes since v2:
- Generate patch using git format-patch -M
Documentation/devicetree/bindings/mfd/arizona.txt | 20 +++---
.../arizona/gpio.h => dt-bindings/mfd/arizona.h} | 67 +--
include/linux/mfd/arizona/pdata.h | 22 +--
sound/soc/codecs/arizona.c |1 -
4 files changed, 44 insertions(+), 66 deletions(-)
rename include/{linux/mfd/arizona/gpio.h => dt-bindings/mfd/arizona.h} (54%)
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in . If
+absent, no configuration of these registers is performed. If any entry has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = <2>;
wlf,gpio-defaults = <
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
>;
};
diff --git a/include/linux/mfd/arizona/gpio.h
b/include/dt-bindings/mfd/arizona.h
similarity index 54%
rename from include/linux/mfd/arizona/gpio.h
rename to include/dt-bindings/mfd/arizona.h
index d2146bb..c7af7c7 100644
--- a/include/linux/mfd/arizona/gpio.h
+++ b/include/dt-bindings/mfd/arizona.h
@@ -1,7 +1,7 @@
/*
- * GPIO configuration for Arizona devices
+ * Device Tree defines for Arizona devices
*
- * Copyright 2013 Wolfson Microelectronics. PLC.
+ * Copyright 2015 Cirrus Logic Inc.
*
* Author: Charles Keepax
*
@@ -10,9 +10,10 @@
* published by the Free Software Foundation.
*/
-#ifndef _ARIZONA_GPIO_H
-#define _ARIZONA_GPIO_H
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+/* GPIO Function Definitions */
#define ARIZONA_GP_FN_TXLRCLK0x00
#define ARIZONA_GP_FN_GPIO 0x01
#define ARIZONA_GP_FN_IRQ1 0x02
@@ -61,36 +62,32 @@
#define ARIZONA_GP_FN_SYSCLK_ENA_STATUS 0x4B
#define ARIZONA_GP_FN_ASYNCCLK_ENA_STATUS0x4C
-#define ARIZONA_GPN_DIR 0x8000 /* GPN_DIR */
-#define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
-#define ARIZONA_GPN_DIR_SHIFT15 /* GPN_DIR */
-#define ARIZONA_GPN_DIR_WIDTH 1 /* GPN_DIR */
-#define ARIZONA_GPN_PU 0x4000 /* GPN_PU */
-#define ARIZONA_GPN_PU_MASK 0x4000 /* GPN_PU */
-#define ARIZONA_GPN_PU_SHIFT 14 /* GPN_PU */
-#define ARIZONA_GPN_PU_WIDTH 1 /* GPN_PU */
-#define ARIZONA_GPN_PD 0x2000 /* GPN_PD */
-#define ARIZONA_GPN_PD_MASK 0x2000 /* GPN_PD */
-#define ARIZONA_GPN_PD_SHIFT 13 /* GPN_PD */
-#define ARIZONA_GPN_PD_WIDTH 1 /* GPN_PD */
-#define ARIZONA_GPN_LVL 0x0800 /* GPN_LVL */
-#define ARIZONA_GPN_LVL_MASK 0x0800 /* GPN_LVL */
-#define ARIZONA_GPN_LVL_SHIFT11 /* GPN_LVL */
-#define ARIZONA_GPN_LVL_WIDTH 1 /* GPN_LVL */
-#define ARIZONA_GPN_POL 0x0400 /* GPN_POL */
-#define ARIZONA_GPN_POL_MASK 0x0400 /* GPN_POL */
-#define ARIZONA_GPN_POL_SHIFT10 /* GPN_POL */
-#define ARIZONA_GPN_POL_WIDTH 1 /* GPN_POL */
-#define ARIZONA_GPN_OP_CFG 0x0200 /*
Re: [PATCH] phy: armada375-usb2: Set drvdata for phy and use it
On Tuesday 24 February 2015 07:42 PM, Axel Lin wrote: Signed-off-by: Axel Lin need a commit msg pls. -Kishon --- drivers/phy/phy-armada375-usb2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/phy/phy-armada375-usb2.c b/drivers/phy/phy-armada375-usb2.c index 7c99ca2..8ccc395 100644 --- a/drivers/phy/phy-armada375-usb2.c +++ b/drivers/phy/phy-armada375-usb2.c @@ -37,7 +37,7 @@ static int armada375_usb_phy_init(struct phy *phy) struct armada375_cluster_phy *cluster_phy; u32 reg; - cluster_phy = dev_get_drvdata(phy->dev.parent); + cluster_phy = phy_get_drvdata(phy); if (!cluster_phy) return -ENODEV; @@ -131,6 +131,7 @@ static int armada375_usb_phy_probe(struct platform_device *pdev) cluster_phy->reg = usb_cluster_base; dev_set_drvdata(dev, cluster_phy); + phy_set_drvdata(phy, cluster_phy); phy_provider = devm_of_phy_provider_register(>dev, armada375_usb_phy_xlate); -- 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: doubt about sm7xxfb
On Wed, Feb 25, 2015 at 06:00:02PM +0530, Sudip Mukherjee wrote: > On Wed, Feb 11, 2015 at 02:33:51PM +0800, Greg Kroah-Hartman wrote: > > On Wed, Feb 11, 2015 at 11:58:18AM +0530, Sudip Mukherjee wrote: > > > > Ok, that makes sense, I was thinking this was a "new" driver, instead of > > a vendor driver crud. > Hi Greg, > The SM750 driver is almost ready for staging, it now compiles without > any error with today's linux-next and is working properly , ok, there > are lots of warning when compiling and checkpatch will give lots of > complaints. > But in total it is creating 34 files and the size of the patch is > 360K. So should i send it with mail, just the way we send other > patches or should i send you a git pull request? through email, like all other patches get sent please. thanks, greg k-h -- 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 v5 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, ) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(>lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(>lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, ) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
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 v5 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
---
drivers/hwmon/pwm-fan.c | 83 -
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..2c1a8f0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(>device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -145,8 +211,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +260,20 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ _fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(>dev,
+ "Failed to register pwm-fan as cooling device");
+ pwm_disable(ctx->pwm);
+ return PTR_ERR(cdev);
+ }
+ thermal_cdev_update(cdev);
+ }
+
return 0;
}
--
2.0.0.rc2
--
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 v5 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if "cooling-levels" was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when "cooling-levels" has zero elements
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, "cooling-levels", NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, "cooling-levels");
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(>dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
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 v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 25 +-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..645251b 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
status = "okay";
pwms = < 0 1 0>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = <_alert1>;
+cooling-device = < 0 1>;
+ };
+ };
};
--
2.0.0.rc2
--
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 v5 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski
- status = "okay"; dropped from the patch
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = < 0 1 0>;
+ };
+};
+
+ {
+ pinctrl-0 = <_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
{
--
2.0.0.rc2
--
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 v5 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc1) SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 25 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 166 +++-- 4 files changed, 220 insertions(+), 16 deletions(-) -- 2.0.0.rc2 -- 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] mfd: da9150: Constify struct regmap_config
On Tue, 24 Feb 2015, Krzysztof Kozlowski wrote:
> The regmap_config struct may be const because it is not modified by the
> driver and regmap_init() accepts pointer to const.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/mfd/da9150-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
> index 4d757b97ef9a..5549817df32e 100644
> --- a/drivers/mfd/da9150-core.c
> +++ b/drivers/mfd/da9150-core.c
> @@ -95,7 +95,7 @@ static const struct regmap_range_cfg da9150_range_cfg[] = {
> },
> };
>
> -static struct regmap_config da9150_regmap_config = {
> +static const struct regmap_config da9150_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> .ranges = da9150_range_cfg,
--
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/
