linux.kernel - 26 new messages in 15 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* drm/i2c: tda998x: don't read write-only registers - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5aa64d4bce89a610?hl=en
* drm/i2c: tda998x: fix the value of the TBG_CNTRL_1 register - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/2d405aa7d60ff5f1?hl=en
* blackfin + dmaengine: conflicting define/enum "DMA_COMPLETE" - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/df981fdd2716c680?hl=en
* drm/i2c: tda998x: use global constants - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f6aa65f6b08bd0df?hl=en
* kernfs, sysfs, driver-core: implement synchronous self-removal - 2 messages,
1 author
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
* drm/i2c: tda998x: add the active aspect in HDMI AVI frame - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/60291982116dd490?hl=en
* drm/i2c: tda998x: add DT support and other improvements - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/22adff82bba80723?hl=en
* drm/i2c: tda998x: code optimization - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0c4bda32b2bb1b2c?hl=en
* clk: support hardware-specific debugfs entries - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bf0e559d9bc3fafc?hl=en
* perf, tools: Add support for prepending LBRs to the callstack - 3 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/6f4f5573ed92a6c4?hl=en
* Staging: lustre: Use of fls to find last set bit - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/aae84f33e3c0a791?hl=en
* mm: thp: Add per-mm_struct flag to control THP - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d9fd22ac1fdbf6b3?hl=en
* ARM: s3c64xx: pm: Add always_on field to s3c64xx_pm_domain struct - 5
messages, 1 author
http://groups.google.com/group/linux.kernel/t/63098c6f35af189c?hl=en
* perf, tools: Only print base source file for srcline - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e9ad098f44690ff5?hl=en
* sysfs warnings since kernel 3.13-rc1: "WARNING: ... at fs/sysfs/group.c:214
sysfs_remove_group" - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a38fa27af05ff8f6?hl=en

==============================================================================
TOPIC: drm/i2c: tda998x: don't read write-only registers
http://groups.google.com/group/linux.kernel/t/5aa64d4bce89a610?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 10:40 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 11:59:41AM +0100, Jean-Francois Moine wrote:
> @@ -936,10 +926,22 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> /* must be last register set: */
> reg_clear(priv, REG_TBG_CNTRL_0, TBG_CNTRL_0_SYNC_ONCE);
>
> + /*
> + * Always generate sync polarity relative to input sync and
> + * revert input stage toggled sync at output stage
> + */
> + reg = TBG_CNTRL_1_DWIN_DIS | TBG_CNTRL_1_TGL_EN;
> + if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + reg |= TBG_CNTRL_1_H_TGL;
> + if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + reg |= TBG_CNTRL_1_V_TGL;
> + reg_write(priv, REG_TBG_CNTRL_1, reg);
> +

I now NAK this patch, as it messes up the register writing order. See
the comment in the context line above.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: drm/i2c: tda998x: fix the value of the TBG_CNTRL_1 register
http://groups.google.com/group/linux.kernel/t/2d405aa7d60ff5f1?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 10:40 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 12:05:43PM +0100, Jean-Francois Moine wrote:
> This patch fixes the 'toggle flag enable' bit of the TBG_CNTRL_1
> register which was set when no toggle was needed.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 192ddd2..7dbbc6b 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1080,11 +1080,11 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * Always generate sync polarity relative to input sync and
> * revert input stage toggled sync at output stage
> */
> - reg = TBG_CNTRL_1_DWIN_DIS | TBG_CNTRL_1_TGL_EN;
> + reg = TBG_CNTRL_1_DWIN_DIS;
> if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> - reg |= TBG_CNTRL_1_H_TGL;
> + reg |= TBG_CNTRL_1_H_TGL | TBG_CNTRL_1_TGL_EN;
> if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> - reg |= TBG_CNTRL_1_V_TGL;
> + reg |= TBG_CNTRL_1_V_TGL | TBG_CNTRL_1_TGL_EN;
> reg_write(priv, REG_TBG_CNTRL_1, reg);

This has me wondering whether you understand the meaning of TGL_EN here,
and what it means.

When TGL_EN is set, the inversion of the syncs is determined by the
settings of the H_TGL and V_TGL bits. When they're zero, no inversion
happens.

However, when TGL_EN is clear, the inversion is determined by the CEA
mode setting in REG_VIDFORMAT.

What your code above means is that if a mode setting valuates as matching
a CEA mode, but has different syncs (eg, no inversion required) then we
don't set the enable bit, and we fall back to whatever is in the TDA998x
device's internal tables for the CEA mode. This is wrong behaviour.

If we want to do this, then the right way would be to detect whether a
sync polarity has been specified (iow, whether any [NP][HV]SYNC flags
have been set) and set the TGL_EN if they have. Otherwise, the TGL_EN
flag can be cleared.

I'm not saying that this will ever result in the TGL_EN flag being
cleared, but to me, your change above is incorrect.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: blackfin + dmaengine: conflicting define/enum "DMA_COMPLETE"
http://groups.google.com/group/linux.kernel/t/df981fdd2716c680?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 11 2014 10:40 am
From: Randy Dunlap


On 01/11/2014 10:09 AM, Marc Kleine-Budde wrote:
> Hello,
>
> in current linux-next (and net-next) the compilation of the CAN
> drivers[1] with ARCH=blackfin fails with:
>
>> CC [M] drivers/net/can/c_can/c_can.o
>> In file included from linux/include/linux/netdevice.h:38:0,
>> from linux/drivers/net/can/c_can/c_can.c:32:
>> linux/include/linux/dmaengine.h:55:2: error: expected identifier before numeric constant
>> linux/include/linux/dmaengine.h: In function 'dma_async_is_complete':
>> linux/include/linux/dmaengine.h:1023:9: error: 'DMA_IN_PROGRESS' undeclared (first use in this function)
>> linux/include/linux/dmaengine.h:1023:9: note: each undeclared identifier is reported only once for each function it appears in
>
> There are two locations where DMA_COMPLETE is defined:
>
>> arch/blackfin/mach-bf548/include/mach/defBF547.h:602:#define DMA_COMPLETE 0x8 /* DMA Complete */
>> arch/blackfin/mach-bf548/include/mach/defBF544.h:622:#define DMA_COMPLETE 0x8 /* DMA Complete */
>
> and
>
>> include/linux/dmaengine.h-enum dma_status {
>> include/linux/dmaengine.h: DMA_COMPLETE,
>> include/linux/dmaengine.h- DMA_IN_PROGRESS,
>> include/linux/dmaengine.h- DMA_PAUSED,
>> include/linux/dmaengine.h- DMA_ERROR,
>> include/linux/dmaengine.h-};
>
> What's the appropriate fix for the problem?

arch/blackfin/mach-bf548/ needs a less generic name for its macro.

> Marc
>
> [1] Yes, c_can isn't a blackfin driver, but it's the first one in my
> compile tests and it fails.
>


--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Sat, Jan 11 2014 11:00 am
From: Marc Kleine-Budde


On 01/11/2014 07:31 PM, Randy Dunlap wrote:
> On 01/11/2014 10:09 AM, Marc Kleine-Budde wrote:
>> Hello,
>>
>> in current linux-next (and net-next) the compilation of the CAN
>> drivers[1] with ARCH=blackfin fails with:
>>
>>> CC [M] drivers/net/can/c_can/c_can.o
>>> In file included from linux/include/linux/netdevice.h:38:0,
>>> from linux/drivers/net/can/c_can/c_can.c:32:
>>> linux/include/linux/dmaengine.h:55:2: error: expected identifier before numeric constant
>>> linux/include/linux/dmaengine.h: In function 'dma_async_is_complete':
>>> linux/include/linux/dmaengine.h:1023:9: error: 'DMA_IN_PROGRESS' undeclared (first use in this function)
>>> linux/include/linux/dmaengine.h:1023:9: note: each undeclared identifier is reported only once for each function it appears in
>>
>> There are two locations where DMA_COMPLETE is defined:
>>
>>> arch/blackfin/mach-bf548/include/mach/defBF547.h:602:#define DMA_COMPLETE 0x8 /* DMA Complete */
>>> arch/blackfin/mach-bf548/include/mach/defBF544.h:622:#define DMA_COMPLETE 0x8 /* DMA Complete */
>>
>> and
>>
>>> include/linux/dmaengine.h-enum dma_status {
>>> include/linux/dmaengine.h: DMA_COMPLETE,
>>> include/linux/dmaengine.h- DMA_IN_PROGRESS,
>>> include/linux/dmaengine.h- DMA_PAUSED,
>>> include/linux/dmaengine.h- DMA_ERROR,
>>> include/linux/dmaengine.h-};
>>
>> What's the appropriate fix for the problem?
>
> arch/blackfin/mach-bf548/ needs a less generic name for its macro.

Mike, is there a in tree user of blacksfin's DMA_COMPLETE? I cannot find
anyone.

Marc

--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |






==============================================================================
TOPIC: drm/i2c: tda998x: use global constants
http://groups.google.com/group/linux.kernel/t/f6aa65f6b08bd0df?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 10:50 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 12:06:18PM +0100, Jean-Francois Moine wrote:
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 23 +++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 864b9f5..efd29d1 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -132,6 +132,8 @@ struct tda998x_priv {
> # define VIP_CNTRL_5_CKCASE (1 << 0)
> # define VIP_CNTRL_5_SP_CNT(x) (((x) & 3) << 1)
> #define REG_MUX_AP REG(0x00, 0x26) /* read/write */
> +# define MUX_AP_SELECT_I2S 0x64
> +# define MUX_AP_SELECT_SPDIF 0x40
> #define REG_MUX_VP_VIP_OUT REG(0x00, 0x27) /* read/write */
> #define REG_MAT_CONTRL REG(0x00, 0x80) /* write */
> # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
> @@ -212,7 +214,12 @@ struct tda998x_priv {
> # define AIP_CLKSEL_FS(x) (((x) & 3) << 0)
> # define AIP_CLKSEL_CLK_POL(x) (((x) & 1) << 2)
> # define AIP_CLKSEL_AIP(x) (((x) & 7) << 3)
> -
> +#define SEL_AIP_SPDIF 0
> +#define SEL_AIP_I2S 1

I'd much rather these became:

# define AIP_CLKSEL_AIP_SPDIF (0 << 3)
# define AIP_CLKSEL_AIP_I2S (1 << 3)

and kill AIP_CLKSEL_AIP().

> +#define CLKPOLDSD_ACLK 0 /* same pol as ACLK */
> +#define CLKPOLDSD_NACLK 1 /* inverted */

If this is for AIP_CLKSEL_CLK_POL, this is labelled up in the data I
have as "for internal use" - we should probably remove AIP_CLKSEL_CLK_POL()
from the above definitions.

> +#define CTSREF_ACLK 0 /* I2S */
> +#define CTSREF_FS64SPDIF 2 /* spdif */

Again, better to define these as:

# define AIP_CLKSEL_FS_ACLK (0 << 0)
# define AIP_CLKSEL_FS_MCLK (1 << 0)
# define AIP_CLKSEL_FS_FS64SPDIF (2 << 0)

and kill AIP_CLKSEL_FS().

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: kernfs, sysfs, driver-core: implement synchronous self-removal
http://groups.google.com/group/linux.kernel/t/b72ccc5edcdfb313?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 11 2014 10:50 am
From: Tejun Heo


Hey, Greg.

On Fri, Jan 10, 2014 at 04:19:53PM -0800, Greg KH wrote:
> > It's really late in the -rc cycle for me to take this for 3.14, but I
> > see patch 1 is a good one to have, so I'll take that now, and queue the
> > rest up for after 3.14-rc1 is out for 3.15. Is that ok with you, or do
> > you have patches that depend on this series for 3.14?
>
> Oh nevermind, these are all good, now applied :)

I don't have anything depending on the series for the up coming merge
window so 3.15 merge window would have been fine but 3.14 merge
windows wokrs too. :)

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Sat, Jan 11 2014 11:00 am
From: Tejun Heo


Hey, Alan.

On Fri, Jan 10, 2014 at 10:46:10AM -0500, Alan Stern wrote:
> The SUBJECT lines in your patch emails don't mention the version
> number. That is, they just say "[PATCH]", not "[PATCH v2]" or "[PATCH
> v3]". This makes it very difficult for me to tell which messages to
> read.

Hmm... they're all threaded. I add version tags when posting
incremental patches but usually don't bother with it when posting a
new version of the whole series. After all, some patches are get
updated without explicitly given a new version for refrehses and stuff
so it's not like you can determine everything based on subjects only.

> (Reading them in order doesn't work, because my computer mixes up the
> order of messages when it downloads a large bunch from the email
> server. It's kind of annoying...)

And they aren't threaded?

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: drm/i2c: tda998x: add the active aspect in HDMI AVI frame
http://groups.google.com/group/linux.kernel/t/60291982116dd490?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:00 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 12:06:39PM +0100, Jean-Francois Moine wrote:
> This patch adds the active aspect as 'picture' in the HDMI AVI frame
> and also some comments about this frame.

Yes, this should've been set. It's probably a stable tree candidate,
but first it needs testing.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: drm/i2c: tda998x: add DT support and other improvements
http://groups.google.com/group/linux.kernel/t/22adff82bba80723?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:00 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 11:56:51AM +0100, Jean-Francois Moine wrote:
> This patch set contains various extensions to the tda998x driver:
>
> - simplify the i2c read/write
> - code cleanup and fix some small errors
> - use HDMI constants
> - don't read write-only registers
> - add DT support
> - use irq for connection status and EDID read
> - get a better status of the HDMI connector
> - use the tda998x video format when cea mode
> - add tda998x codec interface
>
> - v2
> - decompose patches with different topics
> - fix some bad i2c register values
> - add audio codec interface
>

Next time you post patches, please ensure that each patch is a reply
to your series covering message, so that they can be easily threaded
together. It's a pain to have to search around for all the individual
patches amongst other people's traffic.

Thanks.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: drm/i2c: tda998x: code optimization
http://groups.google.com/group/linux.kernel/t/0c4bda32b2bb1b2c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:00 am
From: Russell King - ARM Linux


On Thu, Jan 09, 2014 at 12:07:25PM +0100, Jean-Francois Moine wrote:
> This patch reduces the number of I2C exchanges by setting many bits in
> one write and removing a useless write.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 6b4f6d2..d3b3f3a 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -751,10 +751,10 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> }
>
> reg_write(priv, REG_AIP_CLKSEL, clksel_aip);
> - reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT);
> + reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT |

This patch clearly hasn't even been build tested, so I doubt there's
much point reviewing this or the following patches. From a quick scan
of the following patches, this never got fixed so the following patches
can't have been build tested either.

Thanks.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: clk: support hardware-specific debugfs entries
http://groups.google.com/group/linux.kernel/t/bf0e559d9bc3fafc?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:20 am
From: Alex Elder


Add a new clk_ops->debug_init method to allow a clock hardware
driver to populate the clock's debugfs directory with entries
beyond those common for every clock.

Signed-off-by: Alex Elder <elder@linaro.org>
---
v2: - Define debug_init unconditionally (suggested by Gerhard Sittig).

drivers/clk/clk.c | 4 ++++
include/linux/clk-provider.h | 8 ++++++++
2 files changed, 12 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e3e0327..8769b01 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -277,6 +277,10 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
if (!d)
goto err_out;

+ if (clk->ops->debug_init)
+ if (clk->ops->debug_init(clk->hw, clk->dentry))
+ goto err_out;
+
ret = 0;
goto out;

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5429f5d..b91674d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -32,6 +32,7 @@
#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */

struct clk_hw;
+struct dentry;

/**
* struct clk_ops - Callback operations for hardware clocks; these are to
@@ -116,6 +117,12 @@ struct clk_hw;
* set then clock accuracy will be initialized to parent accuracy
* or 0 (perfect clock) if clock has no parent.
*
+ * @debug_init: Set up type-specific debugfs entries for this clock. This
+ * is called once, after the debugfs directory entry for this
+ * clock has been created. The dentry pointer representing that
+ * directory is provided as an argument. Called with
+ * prepare_lock held. Returns 0 on success, -EERROR otherwise.
+ *
* The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
* implementations to split any work between atomic (enable) and sleepable
* (prepare) contexts. If enabling a clock requires code that might sleep,
@@ -150,6 +157,7 @@ struct clk_ops {
unsigned long (*recalc_accuracy)(struct clk_hw *hw,
unsigned long parent_accuracy);
void (*init)(struct clk_hw *hw);
+ int (*debug_init)(struct clk_hw *hw, struct dentry *dentry);
};

/**
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: perf, tools: Add support for prepending LBRs to the callstack
http://groups.google.com/group/linux.kernel/t/6f4f5573ed92a6c4?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Jan 11 2014 11:20 am
From: Arnaldo Carvalho de Melo


Em Sat, Jan 11, 2014 at 04:16:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jan 11, 2014 at 06:58:16PM +0100, Andi Kleen escreveu:
> > On Sat, Jan 11, 2014 at 04:36:14PM +0100, Jiri Olsa wrote:
> > > On Fri, Jan 10, 2014 at 04:32:03AM -0800, Andi Kleen wrote:
> > > > From: Andi Kleen <ak@linux.intel.com>
> > > >
> > > > I never found the default LBR display mode which generates histograms
> > > > of individual branches particularly useful.
> > > >
> > > > This implements an alternative mode that creates histograms over complete
> > > > branch traces, instead of individual branches, similar to how normal
> > > > callgraphs are handled. This is done by putting it in
> > > > front of the normal callgraph and then using the normal callgraph
> > > > histogram infrastructure to unify them.
> > > >
> > > > This way in complex functions we can understand the control flow
> > > > that lead to a particular sample.
> > > >
> > > > The default output is unchanged.
> > > >
> > > > This is only implemented in perf report, no change to record
> > > > or anywhere else.
> > > >
> > > > This adds the basic code to report:
> > > > - add a new "branch" option to the -g option parser to enable this mode
> > > > - when the flag is set include the LBR into the callstack in machine.c.
> > > > The rest of the history code is unchanged and doesn't know the difference
> > > > between LBR entry and normal call entry.
> > >
> > > sounds like nice idea, but I could not get the patchset applied
> > > on acme's perf/core
> >
> > It was on Linus master.
> >
> > I tried to rebase on perf/core, but it seems to be totally broken by
> > itself. All the config tests fail on my opensuse system.
> >
> > Arnaldo?
>
> Oops, checking on some systems...

What was your build command line?

Here, on a f18 system it works with these:

$ make -C tools/perf O=/tmp/build/perf install

$ cd tools/perf ; make

Trying on another system...

- Arnaldo

> > Auto-detecting system features:
> > ... backtrace: [ OFF ]
> > ... dwarf: [ OFF ]
> > ... fortify-source: [ OFF ]
> > ... glibc: [ OFF ]
> > ... gtk2: [ OFF ]
> > ... gtk2-infobar: [ OFF ]
> > ... libaudit: [ OFF ]
> > ... libbfd: [ OFF ]
> > ... libelf: [ OFF ]
> > ... libelf-getphdrnum: [ OFF ]
> > ... libelf-mmap: [ OFF ]
> > ... libnuma: [ OFF ]
> > ... libperl: [ OFF ]
> > ... libpython: [ OFF ]
> > ... libpython-version: [ OFF ]
> > ... libslang: [ OFF ]
> > ... libunwind: [ OFF ]
> > ... on-exit: [ OFF ]
> > ... stackprotector-all: [ OFF ]
> > ... timerfd: [ OFF ]
> >
> > config/Makefile:282: *** No gnu/libc-version.h found, please install
> > glibc-dev[el]/glibc-static. Stop.
> > make: *** [all] Error 2
> >
> > -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 3 ==
Date: Sat, Jan 11 2014 11:30 am
From: Arnaldo Carvalho de Melo


Em Sat, Jan 11, 2014 at 06:58:16PM +0100, Andi Kleen escreveu:
> On Sat, Jan 11, 2014 at 04:36:14PM +0100, Jiri Olsa wrote:
> > On Fri, Jan 10, 2014 at 04:32:03AM -0800, Andi Kleen wrote:
> > > From: Andi Kleen <ak@linux.intel.com>
> > >
> > > I never found the default LBR display mode which generates histograms
> > > of individual branches particularly useful.
> > >
> > > This implements an alternative mode that creates histograms over complete
> > > branch traces, instead of individual branches, similar to how normal
> > > callgraphs are handled. This is done by putting it in
> > > front of the normal callgraph and then using the normal callgraph
> > > histogram infrastructure to unify them.
> > >
> > > This way in complex functions we can understand the control flow
> > > that lead to a particular sample.
> > >
> > > The default output is unchanged.
> > >
> > > This is only implemented in perf report, no change to record
> > > or anywhere else.
> > >
> > > This adds the basic code to report:
> > > - add a new "branch" option to the -g option parser to enable this mode
> > > - when the flag is set include the LBR into the callstack in machine.c.
> > > The rest of the history code is unchanged and doesn't know the difference
> > > between LBR entry and normal call entry.
> >
> > sounds like nice idea, but I could not get the patchset applied
> > on acme's perf/core
>
> It was on Linus master.
>
> I tried to rebase on perf/core, but it seems to be totally broken by
> itself. All the config tests fail on my opensuse system.
>
> Arnaldo?

Oops, checking on some systems...

> Auto-detecting system features:
> ... backtrace: [ OFF ]
> ... dwarf: [ OFF ]
> ... fortify-source: [ OFF ]
> ... glibc: [ OFF ]
> ... gtk2: [ OFF ]
> ... gtk2-infobar: [ OFF ]
> ... libaudit: [ OFF ]
> ... libbfd: [ OFF ]
> ... libelf: [ OFF ]
> ... libelf-getphdrnum: [ OFF ]
> ... libelf-mmap: [ OFF ]
> ... libnuma: [ OFF ]
> ... libperl: [ OFF ]
> ... libpython: [ OFF ]
> ... libpython-version: [ OFF ]
> ... libslang: [ OFF ]
> ... libunwind: [ OFF ]
> ... on-exit: [ OFF ]
> ... stackprotector-all: [ OFF ]
> ... timerfd: [ OFF ]
>
> config/Makefile:282: *** No gnu/libc-version.h found, please install
> glibc-dev[el]/glibc-static. Stop.
> make: *** [all] Error 2
>
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 3 ==
Date: Sat, Jan 11 2014 11:40 am
From: Andi Kleen


> What was your build command line?
>
> Here, on a f18 system it works with these:
>
> $ make -C tools/perf O=/tmp/build/perf install
>
> $ cd tools/perf ; make
>
> Trying on another system...

Sorry for the false alarm. It looks like it was a problem on my side.
Works now.

-andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Staging: lustre: Use of fls to find last set bit
http://groups.google.com/group/linux.kernel/t/aae84f33e3c0a791?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:40 am
From: Monam Agarwal


This introduces fls in lustre/ldlm/ldlm_extent.c
to find the last set bit.

It also fixes the following checkpatch.pl warning in
lustre/ldlm/ldlm_extent.c
WARNING: space prohibited before semicolon.

The patch also fixes the following checkpatch.pl error in
lustre/ldlm/ldlm_extent.c
ERROR: trailing statements should be on next line


Signed-off-by: Monam Agarwal <monamagarwal123@gmail.com>
---
Changes since v1:
*Incorrect commit message
*Use of fls function

drivers/staging/lustre/lustre/ldlm/ldlm_extent.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
index ac5d66a..e6fe2cb 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
@@ -150,10 +150,12 @@ struct ldlm_interval *ldlm_interval_detach(struct ldlm_lock *l)
static inline int lock_mode_to_index(ldlm_mode_t mode)
{
int index;
+ int len;

LASSERT(mode != 0);
LASSERT(IS_PO2(mode));
- for (index = -1; mode; index++, mode >>= 1) ;
+ len = fls(mode);
+ index = len-1;
LASSERT(index < LCK_MODE_NUM);
return index;
}
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mm: thp: Add per-mm_struct flag to control THP
http://groups.google.com/group/linux.kernel/t/d9fd22ac1fdbf6b3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 11 2014 11:40 am
From: Alex Thorlton


On Sat, Jan 11, 2014 at 04:53:37PM +0100, Oleg Nesterov wrote:
> On 01/10, Alex Thorlton wrote:
> >
> > This patch adds an mm flag (MMF_THP_DISABLE) to disable transparent
> > hugepages using prctl. It is based on my original patch to add a
> > per-task_struct flag to disable THP:
>
> I leave the "whether we need this feature" to other reviewers, although
> personally I think it probably makes sense anyway.
>
> But the patch doesn't look nice imho.
>
> > @@ -373,7 +373,15 @@ extern int get_dumpable(struct mm_struct *mm);
> > #define MMF_HAS_UPROBES 19 /* has uprobes */
> > #define MMF_RECALC_UPROBES 20 /* MMF_HAS_UPROBES can be wrong */
> >
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +#define MMF_THP_DISABLE 21 /* disable THP for this mm */
> > +#define MMF_THP_DISABLE_MASK (1 << MMF_THP_DISABLE)
> > +
> > +#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK | MMF_THP_DISABLE_MASK)
> > +#else
> > #define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK)
> > +