linux.kernel - 26 new messages in 20 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
linux.kernel@googlegroups.com
Today's topics:
* drm/i2c: tda998x: force the page register at startup time - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/88fbf441fe4e46a9?hl=en
* drm/i2c: tda998x: check more I/O errors - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a1aab20b5d857db0?hl=en
* drm/i2c: tda998x: code cleanup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0d42ad43d9e8b569?hl=en
* drm/i2c: tda998x: set the video mode from the adjusted value - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f5bc66ab3620bd8d?hl=en
* drm/i2c: tda998x: use HDMI constants - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3bd22f17b07eb51f?hl=en
* Staging: lustre: Removal of Unnecessary white spaces - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/aae84f33e3c0a791?hl=en
* drm/i2c: tda998x: check the CEC device creation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ffc868da2c04fc90?hl=en
* drm/i2c: tda998x: free the CEC device on encoder_destroy - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c9639b3eb72d9e55?hl=en
* 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: add DT support - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cb5f0c06c9ff31cb?hl=en
* perf tools: add .gitignore for files generated for feature check - 3
messages, 1 author
http://groups.google.com/group/linux.kernel/t/41ea363a566a1a84?hl=en
* perf, tools: Add support for prepending LBRs to the callstack - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/6f4f5573ed92a6c4?hl=en
* ipc: some misc updates & optimizations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/de70251f90927dfa?hl=en
* perf tools: enable close-on-exec flag on perf file descriptor - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/303ffc0717859375?hl=en
* mtd: stm_nand_bch: Add new BCH NAND Flash driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dd7e60edae88b34e?hl=en
* drm/i2c: tda998x: use the tda998x video format when cea mode - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f227c5cf19d60dad?hl=en
* blackfin + dmaengine: conflicting define/enum "DMA_COMPLETE" - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/df981fdd2716c680?hl=en
* rcu_dereference_check_fdtable fix/cleanups - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c6ec2159d16edee2?hl=en
* drm/i2c: tda998x: get a better status of the connexion - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ef3bed1ab7910056?hl=en
* drm/i2c: tda998x: use irq for connection status and EDID read - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/bbeb5edcf598e1bd?hl=en
==============================================================================
TOPIC: drm/i2c: tda998x: force the page register at startup time
http://groups.google.com/group/linux.kernel/t/88fbf441fe4e46a9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:10 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:58:51AM +0100, Jean-Francois Moine wrote:
> This patch forces the page register to be set on the first I/O operation.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
No visible negative side effects, and nothing obviously wrong.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
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: check more I/O errors
http://groups.google.com/group/linux.kernel/t/a1aab20b5d857db0?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:10 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:57:45AM +0100, Jean-Francois Moine wrote:
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
This lacks a description detailing why this change is necessary. While
I can see the sense in preventing a subsequent write succeeding after a
failed page register write, we still continue blindly on accessing the
device after a read or write fails. For istance, how many calls to
reg_write() or reg_read() are checked for failure?
That said, the patch does not appear to create any detrimental effects,
so it gets a tested-by but *no* acked-by. Please give it a better
description justifying this change for an acked-by.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
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 cleanup
http://groups.google.com/group/linux.kernel/t/0d42ad43d9e8b569?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:10 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:58:11AM +0100, Jean-Francois Moine wrote:
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Again, this needs a proper changelog. It also needs style fixes:
WARNING: sizeof buf should be sizeof(buf)
#16: FILE: drivers/gpu/drm/i2c/tda998x_drv.c:338:
+ ret = i2c_master_send(client, buf, sizeof buf);
WARNING: sizeof buf should be sizeof(buf)
#35: FILE: drivers/gpu/drm/i2c/tda998x_drv.c:453:
+ ret = i2c_master_send(client, buf, sizeof buf);
WARNING: sizeof buf should be sizeof(buf)
#44: FILE: drivers/gpu/drm/i2c/tda998x_drv.c:469:
+ ret = i2c_master_send(client, buf, sizeof buf);
total: 0 errors, 3 warnings, 49 lines checked
Your patch has style problems, please review.
Hence, it has only been tested. I'm not giving an acked-by until the
above issues are addressed.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 603f716..cd7ac58 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -335,7 +335,7 @@ cec_write(struct tda998x_priv *priv, uint16_t addr, uint8_t val)
> uint8_t buf[] = {addr, val};
> int ret;
>
> - ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
> + ret = i2c_master_send(client, buf, sizeof buf);
> if (ret < 0)
> dev_err(&client->dev, "Error %d writing to cec:0x%x\n", ret, addr);
> }
> @@ -372,7 +372,8 @@ set_page(struct tda998x_priv *priv, uint16_t reg)
> };
> int ret = i2c_master_send(client, buf, sizeof(buf));
> if (ret < 0) {
> - dev_err(&client->dev, "Error %d writing to REG_CURPAGE\n", ret);
> + dev_err(&client->dev, "setpage %04x err %d\n",
> + reg, ret);
> return ret;
> }
>
> @@ -449,7 +450,7 @@ reg_write(struct tda998x_priv *priv, uint16_t reg, uint8_t val)
> if (ret < 0)
> return;
>
> - ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
> + ret = i2c_master_send(client, buf, sizeof buf);
> if (ret < 0)
> dev_err(&client->dev, "Error %d writing to 0x%x\n", ret, reg);
> }
> @@ -465,7 +466,7 @@ reg_write16(struct tda998x_priv *priv, uint16_t reg, uint16_t val)
> if (ret < 0)
> return;
>
> - ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
> + ret = i2c_master_send(client, buf, sizeof buf);
> if (ret < 0)
> dev_err(&client->dev, "Error %d writing to 0x%x\n", ret, reg);
> }
> @@ -998,7 +999,7 @@ read_edid_block(struct drm_encoder *encoder, uint8_t *buf, int blk)
>
> ret = reg_read_range(priv, REG_EDID_DATA_0, buf, EDID_LENGTH);
> if (ret != EDID_LENGTH) {
> - dev_err(encoder->dev->dev, "failed to read edid block %d: %d",
> + dev_err(encoder->dev->dev, "failed to read edid block %d: %d\n",
> blk, ret);
> return ret;
> }
> @@ -1012,7 +1013,7 @@ static uint8_t *
> do_get_edid(struct drm_encoder *encoder)
> {
> struct tda998x_priv *priv = to_tda998x_priv(encoder);
> - int j = 0, valid_extensions = 0;
> + int j, valid_extensions = 0;
> uint8_t *block, *new;
> bool print_bad_edid = drm_debug & DRM_UT_KMS;
>
>
> --
> Ken ar c'henta� | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: set the video mode from the adjusted value
http://groups.google.com/group/linux.kernel/t/f5bc66ab3620bd8d?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:20 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:59:03AM +0100, Jean-Francois Moine wrote:
> This patch uses always the adjusted video mode instead of a mix of
> original and adjusted mode.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
No visible side effects here, but rather than copying the "adjusted_mode"
pointer to "mode", I'd much rather see the references to "mode" become
"adjusted_mode" instead - choose a shorter name if it's too long, maybe
"adj_mode" ?
--
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: use HDMI constants
http://groups.google.com/group/linux.kernel/t/3bd22f17b07eb51f?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:20 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:59:23AM +0100, Jean-Francois Moine wrote:
> This patch replaces hard coded values by hdmi constants.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
It should be noted that there's a bug fix in this patch as well - it
fixes an uninitialised byte in the AIF packet, and _that_ change should
be separated so that it can be backported to stable trees.
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: Staging: lustre: Removal of Unnecessary white spaces
http://groups.google.com/group/linux.kernel/t/aae84f33e3c0a791?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:30 am
From: Joe Perches
On Sat, 2014-01-11 at 17:11 +0530, Monam Agarwal wrote:
> This fixes the following checkpatch.pl warning in
> lustre/ldlm/ldlm_extent.c
> WARNING: unnecessary whitespace before a quoted newline
I rather doubt this was the checkpatch message here.
Please make sure your commit message and subject match.
[]
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
[]
> @@ -153,7 +153,7 @@ static inline int lock_mode_to_index(ldlm_mode_t mode)
>
> LASSERT(mode != 0);
> LASSERT(IS_PO2(mode));
> - for (index = -1; mode; index++, mode >>= 1) ;
> + for (index = -1; mode; index++, mode >>= 1);
Try using fls instead of this.
--
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: check the CEC device creation
http://groups.google.com/group/linux.kernel/t/ffc868da2c04fc90?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:30 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:00:07PM +0100, Jean-Francois Moine wrote:
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Check the device creation for what? Better description please.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
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: free the CEC device on encoder_destroy
http://groups.google.com/group/linux.kernel/t/c9639b3eb72d9e55?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 9:30 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:59:56AM +0100, Jean-Francois Moine wrote:
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Simple enough two-liner, but a little more description is normally
desirable.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
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: 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 9:30 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:59:41AM +0100, Jean-Francois Moine wrote:
> This patch takes care of the write-only registers of the tda998x.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
It would be worth commenting that where bit settings are unknown, they
are taken from the default values in the available public data. I
refer to (for example) the addition of MAT_CONTRL_MAT_SC(1) to the
REG_MAT_CONTRL register in this patch.
The other register ordering changes should also be documented.
However, in my brief test, I haven't noticed any visible detrimental
effects.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
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: add DT support
http://groups.google.com/group/linux.kernel/t/cb5f0c06c9ff31cb?hl=en
==============================================================================
== 1 of 3 ==
Date: Sat, Jan 11 2014 9:40 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:03:24PM +0100, Jean-Francois Moine wrote:
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> new file mode 100644
> index 0000000..f07339e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -0,0 +1,16 @@
> +Device-Tree bindings for the NXP TDA998x HDMI transmitter
> +
> +Required properties;
> + - compatible: must be "nxp,tda998x"
> +
> +Optional properties:
> + - video-ports: 24 bits value - default: <0x230145>
> +
> +Example:
> +
> + tda998x: hdmi-encoder {
> + compatible = "nxp,tda998x";
> + reg = <0x70>;
> + pinctrl-0 = <&pmx_camera>;
> + pinctrl-names = "default";
This example seems to be meaningless. What SoC pinctrl settings are there
on this device? What has a HDMI encoder got to do with a camera?
--
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/
== 2 of 3 ==
Date: Sat, Jan 11 2014 9:40 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:03:24PM +0100, Jean-Francois Moine wrote:
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 2ba0355..b87802f 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -28,17 +28,22 @@
>
> #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>
> +#define AUDIO_SAMPLE 48 /* 48 kHz */
Horrid definition. It says nothing about it's units, and given that
things like 44.1kHz are common place, should _not_ be kHz.
> +
> struct tda998x_priv {
> struct i2c_client *cec;
> struct i2c_client *hdmi;
> uint16_t rev;
> uint8_t current_page;
> - int dpms;
> + u8 dpms;
A 'dpms' is defined in the DRM interfaces as an 'int' and should remain
as such.
> @@ -586,17 +591,17 @@ static void tda998x_audio_mute(struct tda998x_priv *priv, bool on)
>
> static void
> tda998x_configure_audio(struct tda998x_priv *priv,
> - struct drm_display_mode *mode, struct tda998x_encoder_params *p)
> + struct drm_display_mode *mode)
> {
> uint8_t buf[6], clksel_aip, clksel_fs, ca_i2s, cts_n, adiv;
> uint32_t n;
>
> /* Enable audio ports */
> - reg_write(priv, REG_ENA_AP, p->audio_cfg);
> - reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);
> + reg_write(priv, REG_ENA_AP, priv->audio_port);
> + reg_write(priv, REG_ENA_ACLK, 0x01); /* enable clock */
This is a change of configuration for SPDIF. SPDIF _can_ have an external
clock, or the TDA998x can recover the clock itself. Enabling the clock
unconditionally is probably the wrong thing to do.
>
> /* Set audio input source */
> - switch (p->audio_format) {
> + switch (priv->audio_type) {
> case AFMT_SPDIF:
> reg_write(priv, REG_MUX_AP, 0x40);
> clksel_aip = AIP_CLKSEL_AIP(0);
> @@ -644,7 +649,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> * This is the approximate value of N, which happens to be
> * the recommended values for non-coherent clocks.
> */
> - n = 128 * p->audio_sample_rate / 1000;
> + n = 128 * AUDIO_SAMPLE; /* acr_n = 128 * sample_rate / 1000 */
If you keep the sample rate in Hz, you don't need the comment.
>
> /* Write the CTS and N values */
> buf[0] = 0x44;
> @@ -674,7 +679,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> tda998x_audio_mute(priv, false);
>
> /* Write the audio information packet */
> - tda998x_write_aif(priv, p);
> + tda998x_write_aif(priv);
> }
>
> /* DRM encoder functions */
> @@ -698,7 +703,13 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
> VIP_CNTRL_2_SWAP_F(p->swap_f) |
> (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
>
> - priv->params = *p;
> + memcpy(priv->audio_frame, p->audio_frame,
> + sizeof priv->audio_frame);
> +
> + if (p->audio_cfg) {
> + priv->audio_port = p->audio_cfg;
> + priv->audio_type = p->audio_format;
> + }
Does this really make things better?
> @@ -1157,6 +1168,8 @@ tda998x_encoder_init(struct i2c_client *client,
> struct drm_encoder_slave *encoder_slave)
> {
> struct tda998x_priv *priv;
> + struct device_node *np = client->dev.of_node;
> + u32 video;
> int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> @@ -1166,6 +1179,7 @@ tda998x_encoder_init(struct i2c_client *client,
> priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
> priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
> priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
> + priv->audio_frame[1] = 1; /* channels - 1 */
>
> priv->current_page = 0xff;
> priv->hdmi = client;
> @@ -1225,6 +1239,17 @@ tda998x_encoder_init(struct i2c_client *client,
> cec_write(priv, REG_CEC_FRO_IM_CLK_CTRL,
> CEC_FRO_IM_CLK_CTRL_GHOST_DIS | CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
>
> + if (!np)
> + return 0; /* non-DT */
> +
> + /* get the optional video properties */
> + ret = of_property_read_u32(np, "video-ports", &video);
> + if (ret == 0) {
> + priv->vip_cntrl_0 = video >> 16;
> + priv->vip_cntrl_1 = video >> 8;
> + priv->vip_cntrl_2 = video;
> + }
The creation of new DT bindings requires that the bindings are documented
in Documentation/devicetree/bindings, and this is done as a separate patch
to be submitted to the device tree maintainers for review, and this must
be reviewed before the corresponding DT code can be accepted into the
kernel. Please create such a patch and submit it for their review.
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/
== 3 of 3 ==
Date: Sat, Jan 11 2014 10:10 am
From: Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:03:24PM +0100, Jean-Francois Moine wrote:
> This patch adds DT support to the tda998x.
>
> As a side effect, now, the audio sample rate is always 48kHz and the
> audio clock is always set.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
This patch breaks audio through the renaming of variable names. When you
do such changes, *never* change all three together. Do them one at a time,
replacing all instances of one variable before moving on to the next one.
This avoids getting the names muddled up.
> - struct tda998x_encoder_params params;
> +
> + u8 audio_type; /* audio type */
> + u8 audio_frame[6];
> + u32 audio_port;
"audio type" is a pointless comment for a variable called "audio_type".
Explain what it is. It's the input format, which may be SPDIF or I2S.
> /* Set audio input source */
> - switch (p->audio_format) {
> + switch (priv->audio_type) {
So, "audio_format" has become "audio_type" here.
> @@ -698,7 +703,13 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
> VIP_CNTRL_2_SWAP_F(p->swap_f) |
> (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
>
> - priv->params = *p;
> + memcpy(priv->audio_frame, p->audio_frame,
> + sizeof priv->audio_frame);
> +
> + if (p->audio_cfg) {
> + priv->audio_port = p->audio_cfg;
> + priv->audio_type = p->audio_format;
> + }
Here, audio_port and audio_type are only written to if audio_cfg is
non-zero, which is not quite what is intended here. If you want DT
to override this, then make that explicit.
Moreover, we can see that this confirms that "audio_format" becomes
"audio_type", and "audio_cfg" becomes "audio_port".
> @@ -947,8 +958,8 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
>
> tda998x_write_avi(priv, mode);
>
> - if (priv->params.audio_cfg)
> - tda998x_configure_audio(priv, mode, &priv->params);
> + if (priv->audio_type)
> + tda998x_configure_audio(priv, mode);
And here we have the real bug. "audio_cfg" has become "audio_type",
which in the case of SPDIF, is zero. Hence, with a SPDIF source,
tda998x_configure_audio() is no longer called.
--
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: perf tools: add .gitignore for files generated for feature check
http://groups.google.com/group/linux.kernel/t/41ea363a566a1a84?hl=en
==============================================================================
== 1 of 3 ==
Date: Sat, Jan 11 2014 9:50 am
From: Yann Droneaud
As part of system features auto-detection, some dependency files are
generated and some programs are built.
These files should not be considered by git, so this patch adds
a dedicated .gitignore in tools/perf/config/ sub-directory to
ignore the files.
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
tools/perf/config/feature-checks/.gitignore | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 tools/perf/config/feature-checks/.gitignore
diff --git a/tools/perf/config/feature-checks/.gitignore b/tools/perf/config/feature-checks/.gitignore
new file mode 100644
index 000000000000..53b84b102c78
--- /dev/null
+++ b/tools/perf/config/feature-checks/.gitignore
@@ -0,0 +1,28 @@
+*.d
+test-all
+test-backtrace
+test-bionic
+test-cplus-demangle
+test-dwarf
+test-fortify-source
+test-glibc
+test-gtk2
+test-gtk2-infobar
+test-hello
+test-libaudit
+test-libbfd
+test-libelf
+test-libelf-getphdrnum
+test-libelf-mmap
+test-liberty
+test-liberty-z
+test-libnuma
+test-libperl
+test-libpython
+test-libpython-version
+test-libslang
+test-libunwind
+test-libunwind-debug-frame
+test-on-exit
+test-stackprotector-all
+test-timerfd
--
1.8.4.2
--
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 9:50 am
From: Yann Droneaud
Hi,
Please find 2 little patches to remove an unused file
and to ignore files generated as part of the feature
auto-detection.
Regards.
Yann Droneaud (2):
perf tools: remove unused test-volatile-register-var.c
perf tools: add .gitignore for files generated for feature check
tools/perf/config/feature-checks/.gitignore | 28 ++++++++++++++++++++++
.../feature-checks/test-volatile-register-var.c | 6 -----
2 files changed, 28 insertions(+), 6 deletions(-)
create mode 100644 tools/perf/config/feature-checks/.gitignore
delete mode 100644 tools/perf/config/feature-checks/test-volatile-register-var.c
--
1.8.4.2
--
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 9:50 am
From: Yann Droneaud
Since commit 01287e2cb7ad, test-volatile-register-var.c
is no more built as part of the automatic feature check.
This patch remove the unneeded file.
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
tools/perf/config/feature-checks/test-volatile-register-var.c | 6 ------
1 file changed, 6 deletions(-)
delete mode 100644 tools/perf/config/feature-checks/test-volatile-register-var.c
diff --git a/tools/perf/config/feature-checks/test-volatile-register-var.c b/tools/perf/config/feature-checks/test-volatile-register-var.c
deleted file mode 100644
index c9f398d87868..000000000000
--- a/tools/perf/config/feature-checks/test-volatile-register-var.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include <stdio.h>
-
-int main(void)
-{
- return puts("hi");
-}
--
1.8.4.2
--
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 1 ==
Date: Sat, Jan 11 2014 10:00 am
From: Andi Kleen
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?
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/
==============================================================================
TOPIC: ipc: some misc updates & optimizations
http://groups.google.com/group/linux.kernel/t/de70251f90927dfa?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 10:00 am
From: Davidlohr Bueso
On Sat, 2014-01-11 at 10:02 +0100, Manfred Spraul wrote:
> Hi David,
>
> On 01/10/2014 07:48 PM, Davidlohr Bueso wrote:
> > A few updates to the ipc code, mostly some very needed cleanups (yes, we still
> > have loads more to do, but it's a start). Nothing particularly interesting,
> > except perhaps for the last two patches, which include a locking optimization
> > and barrier documentation for message queues. Absolutely no functional changes.
> >
> > Applies on top of linux-next + Manfred's 'whitespace cleanup' patch. Tested
> > with LTP.
> Now you confuse me.
> In your other mail, you write that my patch doesn't apply to linux-next:
Just ignore that email, Andrew then applied (and fixed the merge
conflict) your whitespace cleanup patch and was already in linux-next by
the time I sent this patchset, so no need to worry/coordinate.
>
> On 01/07/2014 06:12 PM, Davidlohr Bueso wrote:
> > This patch doesn't apply on top of linux-next (which now includes
> > Rafael's changes), could you please resend? I'm planning some more
> > cleanups on top of this so, if Andrew agrees, I can include these
> > changes to my patchset. Thanks, Davidlohr
>
> Perhaps: Could you include (and update, if required) my patch into your
> patchset?
> It's probably simpler if we have only one set of ipc cleanups around.
>
> > Thanks!
> >
> > Davidlohr Bueso (7):
> > ipc: standardize code comments
> > ipc: remove braces for single statements
> > ipc: remove useless return statement
> > ipc: simplify sysvipc_proc_open return
> > ipc: delete seq_max field in struct ipc_ids
> Acked-by: Manfred Spraul <manfred@colorfullife.com>
> > ipc: share ids rwsem when possible in ipcget_public
> This patch is a real change. Could you at least make it the last one in
> the series?
> I will try to review it, but I don't know yet when I will find the time.
Thanks, I definitely want your ack/review for this one.
>
> > ipc,msg: document barriers
> Acked-by: Manfred Spraul <manfred@colorfullife.com>
>
> --
> Manfred
--
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: enable close-on-exec flag on perf file descriptor
http://groups.google.com/group/linux.kernel/t/303ffc0717859375?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 11 2014 10:10 am
From: Yann Droneaud
In a previous patch [1], flag PERF_FLAG_FD_CLOEXEC was
added to perf_event_open(2) syscall to allows userspace
to enable close-on-exec behavor atomically when creating
the file descriptor.
This patch makes perf tool use the new flag if supported
by the kernel, so that the event file descriptors got automatically
closed if perf tool exec a sub-command.
Changes from v0 [2]:
- add probing for PERF_FLAG_FD_CLOEXEC flag allowing
perf to run on older kernel:
* use "missing feature" pattern in evsel to disable
PERF_FLAG_FD_CLOEXEC in perf_evsel__open() if not
supported by kernel;
* add a dedicated function to probe for
PERF_FLAG_FD_CLOEXEC support in the current kernel.
This function is to be used by other functions
calling sys_perf_event_open() directly.
- remove PERF_FLAG_FD_CLOEXEC from PowerPC selftest
as it's not related to perf tool: it should be part
of a separate patch.
[1] http://lkml.kernel.org/r/8c03f54e1598b1727c19706f3af03f98685d9fe6.1388952061.git.ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3434971/
[2] http://lkml.kernel.org/r/1389005485-12778-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3437111/
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://lkml.kernel.org/r/cover.1388952061.git.ydroneaud@opteya.com
---
tools/perf/Makefile.perf | 1 +
tools/perf/bench/mem-memcpy.c | 4 ++-
tools/perf/bench/mem-memset.c | 4 ++-
tools/perf/builtin-sched.c | 4 ++-
tools/perf/tests/bp_signal.c | 4 ++-
tools/perf/tests/bp_signal_overflow.c | 4 ++-
tools/perf/tests/rdpmc.c | 4 ++-
tools/perf/util/cloexec.c | 54 +++++++++++++++++++++++++++++++++++
tools/perf/util/cloexec.h | 6 ++++
tools/perf/util/evsel.c | 12 ++++++--
tools/perf/util/record.c | 10 +++++--
11 files changed, 95 insertions(+), 12 deletions(-)
create mode 100644 tools/perf/util/cloexec.c
create mode 100644 tools/perf/util/cloexec.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 97a2145e4cc6..0428b11402b8 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -372,6 +372,7 @@ LIB_OBJS += $(OUTPUT)util/stat.o
LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/cloexec.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c
index 5ce71d3b72cf..bf5a21b848a9 100644
--- a/tools/perf/bench/mem-memcpy.c
+++ b/tools/perf/bench/mem-memcpy.c
@@ -10,6 +10,7 @@
#include "../util/util.h"
#include "../util/parse-options.h"
#include "../util/header.h"
+#include "../util/cloexec.h"
#include "bench.h"
#include "mem-memcpy-arch.h"
@@ -83,7 +84,8 @@ static struct perf_event_attr cycle_attr = {
static void init_cycle(void)
{
- cycle_fd = sys_perf_event_open(&cycle_attr, getpid(), -1, -1, 0);
+ cycle_fd = sys_perf_event_open(&cycle_attr, getpid(), -1, -1,
+ perf_event_open_cloexec_flag());
if (cycle_fd < 0 && errno == ENOSYS)
die("No CONFIG_PERF_EVENTS=y kernel support configured?\n");
diff --git a/tools/perf/bench/mem-memset.c b/tools/perf/bench/mem-memset.c
index 9af79d2b18e5..260747ea1e0e 100644
--- a/tools/perf/bench/mem-memset.c
+++ b/tools/perf/bench/mem-memset.c
@@ -10,6 +10,7 @@
#include "../util/util.h"
#include "../util/parse-options.h"
#include "../util/header.h"
+#include "../util/cloexec.h"
#include "bench.h"
#include "mem-memset-arch.h"
@@ -83,7 +84,8 @@ static struct perf_event_attr cycle_attr = {
static void init_cycle(void)
{
- cycle_fd = sys_perf_event_open(&cycle_attr, getpid(), -1, -1, 0);
+ cycle_fd = sys_perf_event_open(&cycle_attr, getpid(), -1, -1,
+ perf_event_open_cloexec_flag());
if (cycle_fd < 0 && errno == ENOSYS)
die("No CONFIG_PERF_EVENTS=y kernel support configured?\n");
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0f3c65518a2c..bce5d4efea9c 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -10,6 +10,7 @@
#include "util/header.h"
#include "util/session.h"
#include "util/tool.h"
+#include "util/cloexec.h"
#include "util/parse-options.h"
#include "util/trace-event.h"
@@ -435,7 +436,8 @@ static int self_open_counters(void)
attr.type = PERF_TYPE_SOFTWARE;
attr.config = PERF_COUNT_SW_TASK_CLOCK;
- fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
+ fd = sys_perf_event_open(&attr, 0, -1, -1,
+ perf_event_open_cloexec_flag());
if (fd < 0)
pr_err("Error: sys_perf_event_open() syscall returned "
diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
index aba095489193..fdc0d3e185f9 100644
--- a/tools/perf/tests/bp_signal.c
+++ b/tools/perf/tests/bp_signal.c
@@ -25,6 +25,7 @@
#include "tests.h"
#include "debug.h"
#include "perf.h"
+#include "../util/cloexec.h"
static int fd1;
static int fd2;
@@ -78,7 +79,8 @@ static int bp_event(void *fn, int setup_signal)
pe.exclude_kernel = 1;
pe.exclude_hv = 1;
- fd = sys_perf_event_open(&pe, 0, -1, -1, 0);
+ fd = sys_perf_event_open(&pe, 0, -1, -1,
+ perf_event_open_cloexec_flag());
if (fd < 0) {
pr_debug("failed opening event %llx\n", pe.config);
return TEST_FAIL;
diff --git a/tools/perf/tests/bp_signal_overflow.c b/tools/perf/tests/bp_signal_overflow.c
index 44ac82179708..b0b17415f18c 100644
--- a/tools/perf/tests/bp_signal_overflow.c
+++ b/tools/perf/tests/bp_signal_overflow.c
@@ -24,6 +24,7 @@
#include "tests.h"
#include "debug.h"
#include "perf.h"
+#include "../util/cloexec.h"
static int overflows;
@@ -91,7 +92,8 @@ int test__bp_signal_overflow(void)
pe.exclude_kernel = 1;
pe.exclude_hv = 1;
- fd = sys_perf_event_open(&pe, 0, -1, -1, 0);
+ fd = sys_perf_event_open(&pe, 0, -1, -1,
+ perf_event_open_cloexec_flag());
if (fd < 0) {
pr_debug("failed opening event %llx\n", pe.config);
return TEST_FAIL;
diff --git a/tools/perf/tests/rdpmc.c b/tools/perf/tests/rdpmc.c
index 46649c25fa5e..c1e55ff18774 100644
--- a/tools/perf/tests/rdpmc.c
+++ b/tools/perf/tests/rdpmc.c
@@ -6,6 +6,7 @@
#include "perf.h"
#include "debug.h"
#include "tests.h"
+#include "../util/cloexec.h"
#if defined(__x86_64__) || defined(__i386__)
@@ -104,7 +105,8 @@ static int __test__rdpmc(void)
sa.sa_sigaction = segfault_handler;
sigaction(SIGSEGV, &sa, NULL);
- fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
+ fd = sys_perf_event_open(&attr, 0, -1, -1,
+ perf_event_open_cloexec_flag());
if (fd < 0) {
pr_err("Error: sys_perf_event_open() syscall returned "
"with %d (%s)\n", fd, strerror(errno));
diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
new file mode 100644
index 000000000000..3889a7b9e2d6
--- /dev/null
+++ b/tools/perf/util/cloexec.c
@@ -0,0 +1,54 @@
+#include "util.h"
+#include "../perf.h"
+#include "cloexec.h"
+
+static unsigned long flag = PERF_FLAG_FD_CLOEXEC;
+
+static int perf_flag_probe(void)
+{
+ struct perf_event_attr attr;
+ int fd;
+ int err;
+
+ /* check cloexec flag */
+ memset(&attr, 0, sizeof(attr));
+ fd = sys_perf_event_open(&attr, 0, -1, -1,
+ PERF_FLAG_FD_CLOEXEC);
+ if (fd >= 0) {
+ close(fd);
+ return 1;
+ }
+
+ if (errno != EINVAL) {
+ err = errno;
+ pr_warning("sys_perf_event_open() syscall returned "
+ "%d (%d: %s)\n", fd, err, strerror(err));
+ }
+
+ /* not supported, confirm error related to PERF_FLAG_FD_CLOEXEC */
+ memset(&attr, 0, sizeof(attr));
+ fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
+ if (fd >= 0) {
+ close(fd);
+ return 0;
+ }
+
+ err = errno;
+ die("sys_perf_event_open() syscall returned "
+ "%d (%d: %s)\n", fd, err, strerror(err));
+
+ return -1;
+}
+
+unsigned long perf_event_open_cloexec_flag(void)
+{
+ static int probed;
+
+ if (!probed) {
+ if (perf_flag_probe() <= 0) {
+ flag = 0;
+ }
+ }
+
+ return flag;
+}
diff --git a/tools/perf/util/cloexec.h b/tools/perf/util/cloexec.h
new file mode 100644
index 000000000000..94a5a7d829d5
--- /dev/null
+++ b/tools/perf/util/cloexec.h
@@ -0,0 +1,6 @@
+#ifndef __PERF_CLOEXEC_H
+#define __PERF_CLOEXEC_H
+
+unsigned long perf_event_open_cloexec_flag(void);
+
+
posted by twitter @ 12:13 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home