* [PATCH V4 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
From: Christopher Covington @ 2014-01-24 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124113920.GF814@e106331-lin.cambridge.arm.com>
On 01/24/2014 06:39 AM, Mark Rutland wrote:
> On Thu, Jan 23, 2014 at 07:20:01PM +0000, Feng Kan wrote:
>> Add documentation for generic SYSCON reboot driver.
>>
>> Signed-off-by: Feng Kan <fkan@apm.com>
>> ---
>> .../bindings/power/reset/syscon-reboot.txt | 16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
>> new file mode 100644
>> index 0000000..e9eb1fe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
>> @@ -0,0 +1,16 @@
>> +Generic SYSCON mapped register reset driver
>
> Bindings should describe hardware, not drivers.
How is this different than what's done for PSCI?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
From: Christopher Covington @ 2014-01-24 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124171754.GM31040@mudshark.cambridge.arm.com>
On 01/24/2014 12:17 PM, Will Deacon wrote:
> On Fri, Jan 24, 2014 at 05:16:28PM +0000, Adrien Verg? wrote:
>> 2014/1/24 Will Deacon <will.deacon@arm.com>:
>>> Are you sure about this? The value we write is actually task_pid_nr, which I
>>> believe to be globally unique.
>>
>> You are right: the task_pid_nr is unique in the system. However when
>> using namespaces, the so called "PID" is the virtual number that
>> processes in different namespaces can share.
>>
>> This PID is the one visible by user-space tasks, in particular
>> user-space tracers and debuggers. These programs would expect to find
>> the PID of the traced process in the Context ID reg, while it is not.
>> I think it is better to remove confusion by making PID_IN_CONTEXTIDR
>> and PID_NS incompatible.
>>
>> What do you think?
>
> I think I'd rather have the global ID than disable a potentially useful
> feature, especially since this is likely to be consumed by external trace
> tools as opposed to user-space tasks.
We've discussed before that the ARM architecture doesn't say what should be
written to the CONTEXTIDR, so it's up to us to decide. Will has a use case
where the global PID is useful. Adrien's patches present a use case where I
think the virtual PID would be useful. I've done work in the past where
writing the process group ID was useful. Would it be reasonable to make what's
written to the CONTEXTIDR run-time configurable? If so, what would be the best
interface for configuring it?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH v3 15/24] drm/i2c: tda998x: use irq for connection status and EDID read
From: Russell King - ARM Linux @ 2014-01-24 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E2A2E8.50806@gmail.com>
On Fri, Jan 24, 2014 at 06:29:12PM +0100, Sebastian Hesselbarth wrote:
> On 01/22/14 23:27, Russell King - ARM Linux wrote:
>> On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
>>> This patch adds the optional treatment of the tda998x IRQ.
>>>
>>> The interrupt function is used to know the display connection status
>>> without polling and to speedup reading the EDID.
>>>
>>> The interrupt number may be defined either in the DT or at encoder set
>>> config time for non-DT boards.
>>>
>>> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
>>> ---
> [...]
>>> @@ -720,6 +787,10 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
>>> priv->audio_port = p->audio_cfg;
>>> priv->audio_format = p->audio_format;
>>> }
>>> +
>>> + priv->irq = p->irq;
>>> + if (p->irq)
>>> + tda_irq_init(priv);
>>
>> If we're going to do it this way, this should probably release the IRQ if
>> there was one before re-claiming it, just in case this function gets called
>> more than once by some driver using it.
>>
>> The alternative is, as I said before, to use the infrastructure which is
>> already there, namely setting the interrupt via struct i2c_client's
>> irq member. Yes, that doesn't satisfy Sebastian's comment about using
>> a GPIO, but there's no sign of GPIO usage in here at the moment anyway.
>> So we might as well use what's already provided.
>
> Russell,
>
> I am fine with using an irq instead of gpio here. I remember you telling
> me on a similar patch, that from the gpio you can derive the irq but
> not the other way round. Anyway, I also remember reading discussions
> about DT gpios vs interrupts, and IIRC the outcome was that passing
> interrupts is fine, too.
Sebastian,
You can derive the irq from a gpio (using gpio_to_irq()), but you can't
derive a gpio from an irq.
It's annoying that i2c_client and the i2c board data do not allow a GPIO
to be specified, but only an IRQ, but that's a separate problem which when
solved will also get solved here. So, I'm not too worried about the
"should this be an IRQ or should it be a GPIO" question here.
For us on ARM, it's less of a problem because we can just deal with GPIOs
or IRQs at the DT level, and so we don't care what's in i2c_client.
--
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".
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Grant Likely @ 2014-01-24 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjrLs9eEPurjUpOfgyexnc__FJkRYmAR84_f7C15HH07Q@mail.gmail.com>
On Mon, 20 Jan 2014 17:03:23 -0800, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely@linaro.org> wrote:
> > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> >> >
> >> > Another, more invasive option would be extend the dts syntax and teach
> >> > dtc to handle property appending. Then the soc dts could stay as it is,
> >> > and the board dts could have something like:
> >> >
> >> > /append-property/ interrupts = <&intc1 6 1>;
> >> > /append-property/ interrupt-names = "board-specific-irq";
> >> >
> >> > Both these options solve the issue at the source, are general to other
> >> > properties, and allow more than one level of hierarchy (the proposed
> >> > interrupts-extended-2 only allows one level).
> >>
> >> I've just had a go at implementing the append-property mechanism above
> >> in dtc, and it was far easier than I expected (patch below).
> >>
> >> Does anyone have any issues with the /append-property/ idea?
> >
> > I think that is reasonable.
>
>
> The main problem with this (same for clocks) is if you need to append
> something with a name when the original didn't have any.
>
> Reordering entries might not work for interrupts, since the bindings
> might have requirements on order.
Hmmm, yes. to handle that case would need a higher level construct that
keeps the name and interrupt value together. Maybe something like this?
device {
add-interrupt(27);
add-interrupt(29, 5, controller=&intc1);
add-interrupt(2, 4, name="error");
};
I'm using python-like syntax here where controller and name are optional
arguments.
We could get DTC to generate the appropriate interrupt-parent,
interrupts, interrupts-extended and interrupt-names properties as
needed. Of course the shared context would be lost when the tree is
compiled, but it would be useful for building up parsing data. It would
also work for gpio, clocks and similar bindings. Kind of like an
intelligent macro.
g.
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Fabio Estevam @ 2014-01-24 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120164859.GF15937@n2100.arm.linux.org.uk>
On Mon, Jan 20, 2014 at 2:48 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> So far so good. Now, what about this external oscillator which has its
> own separate power control. My immediate thought is that this can be
> specified via card_ext_clock - I would simply need to declare a fixed-rate
> clock with either a regulator (power switch) controlled via a gpio (which
> would probably be closer to the hardware) or a gpio as an enable... ah,
> that requires me to write a common clock driver for that bit since this
> is currently not modelled by CCF...
Jiry Sarha posted a gpio controlled clock proposal:
http://www.spinics.net/lists/devicetree/msg16651.html
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v3 15/24] drm/i2c: tda998x: use irq for connection status and EDID read
From: Sebastian Hesselbarth @ 2014-01-24 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122222705.GL15937@n2100.arm.linux.org.uk>
On 01/22/14 23:27, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
>> This patch adds the optional treatment of the tda998x IRQ.
>>
>> The interrupt function is used to know the display connection status
>> without polling and to speedup reading the EDID.
>>
>> The interrupt number may be defined either in the DT or at encoder set
>> config time for non-DT boards.
>>
>> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
>> ---
[...]
>> @@ -720,6 +787,10 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
>> priv->audio_port = p->audio_cfg;
>> priv->audio_format = p->audio_format;
>> }
>> +
>> + priv->irq = p->irq;
>> + if (p->irq)
>> + tda_irq_init(priv);
>
> If we're going to do it this way, this should probably release the IRQ if
> there was one before re-claiming it, just in case this function gets called
> more than once by some driver using it.
>
> The alternative is, as I said before, to use the infrastructure which is
> already there, namely setting the interrupt via struct i2c_client's
> irq member. Yes, that doesn't satisfy Sebastian's comment about using
> a GPIO, but there's no sign of GPIO usage in here at the moment anyway.
> So we might as well use what's already provided.
Russell,
I am fine with using an irq instead of gpio here. I remember you telling
me on a similar patch, that from the gpio you can derive the irq but
not the other way round. Anyway, I also remember reading discussions
about DT gpios vs interrupts, and IIRC the outcome was that passing
interrupts is fine, too.
We usually have both interrupt-controller; and gpio-controller; set on
DT gpio controllers, so let's stick with irq.
And: Thanks for reviewing this again, I am still too busy to keep up
with it.
Sebastian
^ permalink raw reply
* [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
From: Will Deacon @ 2014-01-24 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANsc=4UgWrFis6hi-0mXZAfery7YGDJ2F+NdZBzq6afwx_i58A@mail.gmail.com>
On Fri, Jan 24, 2014 at 05:16:28PM +0000, Adrien Verg? wrote:
> 2014/1/24 Will Deacon <will.deacon@arm.com>:
> > Are you sure about this? The value we write is actually task_pid_nr, which I
> > believe to be globally unique.
>
> You are right: the task_pid_nr is unique in the system. However when
> using namespaces, the so called "PID" is the virtual number that
> processes in different namespaces can share.
>
> This PID is the one visible by user-space tasks, in particular
> user-space tracers and debuggers. These programs would expect to find
> the PID of the traced process in the Context ID reg, while it is not.
> I think it is better to remove confusion by making PID_IN_CONTEXTIDR
> and PID_NS incompatible.
>
> What do you think?
I think I'd rather have the global ID than disable a potentially useful
feature, especially since this is likely to be consumed by external trace
tools as opposed to user-space tasks.
Will
^ permalink raw reply
* [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
From: Adrien Vergé @ 2014-01-24 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124164343.GJ31040@mudshark.cambridge.arm.com>
2014/1/24 Will Deacon <will.deacon@arm.com>:
> Are you sure about this? The value we write is actually task_pid_nr, which I
> believe to be globally unique.
You are right: the task_pid_nr is unique in the system. However when
using namespaces, the so called "PID" is the virtual number that
processes in different namespaces can share.
This PID is the one visible by user-space tasks, in particular
user-space tracers and debuggers. These programs would expect to find
the PID of the traced process in the Context ID reg, while it is not.
I think it is better to remove confusion by making PID_IN_CONTEXTIDR
and PID_NS incompatible.
What do you think?
^ permalink raw reply
* [PATCH v4 5/8] mmc: sdhci-bcm-kona: Add basic use of clocks
From: Tim Kryger @ 2014-01-24 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAYSxhoCrveHd5Wkc7Z0qzpGr41qG6-neYSSsuHQuC7AcuJmZQ@mail.gmail.com>
On Tue, Jan 7, 2014 at 11:37 AM, Tim Kryger <tim.kryger@linaro.org> wrote:
> On Sat, Dec 14, 2013 at 12:14 AM, Christian Daudt <bcm@fixthebug.org> wrote:
>> On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger <tim.kryger@linaro.org> wrote:
>>> Enable the external clock needed by the host controller during the
>>> probe and disable it during the remove.
>>>
>>> Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
>>> Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
>>> Reviewed-by: Matt Porter <matt.porter@linaro.org>
>>
>> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
>>
>> Chris,
>> Are you ok with me pulling this patch along with the rest of the
>> patchset into the bcm tree?
>>
>> Thanks,
>> csd
>
> Chris,
>
> Can you please provide an answer to csd?
>
> Thanks,
> Tim Kryger
Chris,
I haven't heard back so this patch has been dropped for 3.14 to allow
the remaining patches in the series to move forward. As such, I will
be re-posting this patch for 3.15. It is essential for the
bcm28155_ap board to transition away from fake fixed clocks to the
real clock driver. This is because the bcm281xx clock driver does not
set the CLK_IGNORE_UNUSED flag for the SDHCI peripheral clocks and the
common clock code will shut them off in late init unless the SDHCI
driver has asked for them to be enabled.
Thanks,
Tim
^ permalink raw reply
* [PATCH 2/5] arm64: dts: APM X-Gene SoC Ethernet device tree nodes
From: Mark Salter @ 2014-01-24 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387597376-29303-3-git-send-email-isubramanian@apm.com>
On Fri, 2013-12-20 at 19:42 -0800, Iyappan Subramanian wrote:
> Device tree files for APM X-Gene SoC Ethernet.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Ravi Patel <rapatel@apm.com>
> Signed-off-by: Keyur Chudgar <kchudgar@apm.com>
> ---
> arch/arm64/boot/dts/apm-mustang.dts | 8 ++++++++
> arch/arm64/boot/dts/apm-storm.dtsi | 19 +++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
> index 1247ca1..ccb2771 100644
> --- a/arch/arm64/boot/dts/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm-mustang.dts
> @@ -17,6 +17,10 @@
> model = "APM X-Gene Mustang board";
> compatible = "apm,mustang", "apm,xgene-storm";
>
> + aliases {
> + ethernet0 = &menet;
> + };
> +
> chosen { };
>
> memory {
> @@ -24,3 +28,7 @@
> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> };
> };
> +
> +&menet {
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
> index f64f946..9c7b8cd 100644
> --- a/arch/arm64/boot/dts/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -204,5 +204,24 @@
> #clock-cells = <1>;
> clocks = <&qmlclk 0>;
> };
> +
> + menet: ethernet at 17020000 {
> + compatible = "apm,xgene-enet";
> + status = "disabled";
> + reg = <0x0 0x17020000 0x0 0x30>,
> + <0x0 0x17020000 0x0 0x10000>,
> + <0x0 0x17020000 0x0 0x20>;
> + slave-name = "RGMII";
> + interrupts = <0x0 0x38 0x4>,
> + <0x0 0x39 0x4>,
> + <0x0 0x3a 0x4>;
> + #clock-cells = <1>;
> + clocks = <ð8clk 0>;
> + local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
Shouldn't this be a byte string?:
local-mac-address = [ 00 11 3a 8a 5a 78 ];
> + max-frame-size = <0x233a>;
> + devid = <8>;
> + phyid = <3>;
> + phy-mode = "rgmii";
> + };
> };
> };
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-24 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E26325.4040203@ti.com>
On Fri, 24 Jan 2014 14:57:09 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> Could you give me a link to a git repo with your tda998x codec code so I
> could prepare to use that too?
I have no git repo. Instead, here is the source.
It goes into sound/soc/codecs and is selected with CONFIG_OF and
CONFIG_DRM_I2C_NXP_TDA998X.
It needs 2 exported functions of the tda998x driver: the first one to
select the audio port (tda998x_audio_update) and the other one to get
the ELD (tda998x_audio_get_eld).
For these functions to receive the correct i2c_client, the codec
searches the tda998x driver in the DT by its compatible "nxp,tda998x".
If the tda998x is loaded by drm_i2c_encoder_init(), it should not be
declared in the DT, so, this raises a problem. I don't know what must
be done in this case.
The codec is used with the simple card as the sound card. For you, the
DT could be:
hdmi_codec: hdmi-codec {
compatible = "nxp,tda998x-codec";
#sound-dai-cells = <1>;
audio-ports = <0x03>, <0x04>; /* i2s - s/pdif */
};
sound {
compatible = "simple-audio-card";
simple-audio-card,cpu {
sound-dai = <&audio1 1>;
format = "i2s";
};
simple-audio-card,codec {
sound-dai = <&hdmi_codec 0>; /* i2s */
};
};
('audio1' is the audio controller)
-------------------8<---------------- source sound/soc/codecs/tda998x.c
/*
* ALSA SoC TDA998X driver
*
* This driver is used by the NXP TDA998x HDMI transmitter.
*
* Copyright (C) 2014 Jean-Francois Moine
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/module.h>
#include <sound/soc.h>
#include <sound/pcm.h>
#include <linux/of.h>
#include <linux/i2c.h>
#include <drm/drm_encoder_slave.h>
#include <drm/i2c/tda998x.h>
#define TDA998X_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S32_LE)
struct tda_priv {
struct i2c_client *i2c_client;
struct snd_soc_codec *codec;
u32 ports[2];
int dai_id;
u8 *eld;
};
static void tda_get_encoder(struct tda_priv *priv)
{
struct snd_soc_codec *codec = priv->codec;
struct device_node *np;
struct i2c_client *i2c_client;
static const struct of_device_id tda_dt[] = {
{ .compatible = "nxp,tda998x" },
{ },
};
/* search the tda998x device (only one!) */
np = of_find_matching_node_and_match(NULL, tda_dt, NULL);
if (!np || !of_device_is_available(np)) {
dev_err(codec->dev, "No tda998x in DT\n");
return;
}
i2c_client = of_find_i2c_device_by_node(np);
of_node_put(np);
if (!i2c_client) {
dev_err(codec->dev, "no tda998x i2c client\n");
return;
}
if (!i2c_get_clientdata(i2c_client)) {
dev_err(codec->dev, "tda998x not initialized\n");
return;
}
priv->i2c_client = i2c_client;
}
static int tda_start_stop(struct tda_priv *priv,
int start)
{
int format;
u32 port;
if (!priv->i2c_client) {
tda_get_encoder(priv);
if (!priv->i2c_client)
return -EINVAL;
}
/* give the audio input type and ports to the HDMI encoder */
format = start ? priv->dai_id : 0;
switch (format) {
case AFMT_I2S:
port = priv->ports[0];
break;
default:
case AFMT_SPDIF:
port = priv->ports[1];
break;
}
tda998x_audio_update(priv->i2c_client, format, port);
return 0;
}
static int tda_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct tda_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
u8 *eld = NULL;
static unsigned rates_mask[] = {
SNDRV_PCM_RATE_32000,
SNDRV_PCM_RATE_44100,
SNDRV_PCM_RATE_48000,
SNDRV_PCM_RATE_88200,
SNDRV_PCM_RATE_96000,
SNDRV_PCM_RATE_176400,
SNDRV_PCM_RATE_192000,
};
/* memorize the used DAI */
priv->dai_id = dai->id;
/* get the ELD from the tda998x driver */
if (!priv->i2c_client)
tda_get_encoder(priv);
if (priv->i2c_client)
eld = tda998x_audio_get_eld(priv->i2c_client);
/* limit the hw params from the ELD (EDID) */
if (eld) {
struct snd_soc_dai_driver *dai_drv = dai->driver;
struct snd_soc_pcm_stream *stream = &dai_drv->playback;
u8 *sad;
int sad_count;
unsigned eld_ver, mnl, rates, rate_mask, i;
unsigned max_channels;
eld_ver = eld[0] >> 3;
if (eld_ver != 2 && eld_ver != 31)
return 0;
mnl = eld[4] & 0x1f;
if (mnl > 16)
return 0;
sad_count = eld[5] >> 4;
sad = eld + 20 + mnl;
/* Start from the basic audio settings */
max_channels = 2;
rates = 0;
while (sad_count--) {
switch (sad[0] & 0x78) {
case 0x08: /* PCM */
max_channels = max(max_channels, (sad[0] & 7) + 1u);
rates |= sad[1];
break;
}
sad += 3;
}
for (rate_mask = i = 0; i < ARRAY_SIZE(rates_mask); i++)
if (rates & 1 << i)
rate_mask |= rates_mask[i];
/* change the snd_soc_pcm_stream values of the driver */
stream->rates = rate_mask;
stream->channels_max = max_channels;
}
/* start the TDA998x audio */
return tda_start_stop(priv, 1);
}
static void tda_shutdown(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct tda_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
priv->dai_id = 0;
tda_start_stop(priv, 0);
}
static const struct snd_soc_dai_ops tda_ops = {
.startup = tda_startup,
.shutdown = tda_shutdown,
};
static const struct snd_soc_dai_driver tda998x_dai[] = {
{
.name = "i2s-hifi",
.id = AFMT_I2S,
.playback = {
.stream_name = "HDMI I2S Playback",
.channels_min = 1,
.channels_max = 8,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 5512,
.rate_max = 192000,
.formats = TDA998X_FORMATS,
},
.ops = &tda_ops,
},
{
.name = "spdif-hifi",
.id = AFMT_SPDIF,
.playback = {
.stream_name = "HDMI SPDIF Playback",
.channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 22050,
.rate_max = 192000,
.formats = TDA998X_FORMATS,
},
.ops = &tda_ops,
},
};
static const struct snd_soc_dapm_widget tda_widgets[] = {
SND_SOC_DAPM_OUTPUT("hdmi-out"),
};
static const struct snd_soc_dapm_route tda_routes[] = {
{ "hdmi-out", NULL, "HDMI I2S Playback" },
{ "hdmi-out", NULL, "HDMI SPDIF Playback" },
};
static int tda_probe(struct snd_soc_codec *codec)
{
struct tda_priv *priv;
struct device_node *np;
int i, ret;
priv = devm_kzalloc(codec->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
snd_soc_codec_set_drvdata(codec, priv);
priv->codec = codec;
/* get the audio input ports (I2s and S/PDIF) */
np = codec->dev->of_node;
for (i = 0; i < 2; i++) {
ret = of_property_read_u32_index(np, "audio-ports", i,
&priv->ports[i]);
if (ret) {
if (i == 0)
dev_err(codec->dev,
"bad or missing audio-ports\n");
break;
}
}
return 0;
}
static const struct snd_soc_codec_driver soc_codec_tda998x = {
.probe = tda_probe,
.dapm_widgets = tda_widgets,
.num_dapm_widgets = ARRAY_SIZE(tda_widgets),
.dapm_routes = tda_routes,
.num_dapm_routes = ARRAY_SIZE(tda_routes),
};
static int tda998x_dev_probe(struct platform_device *pdev)
{
struct snd_soc_dai_driver *dai_drv;
/* copy the DAI driver to a writable area */
dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
if (!dai_drv)
return -ENOMEM;
memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
return snd_soc_register_codec(&pdev->dev,
&soc_codec_tda998x,
dai_drv, ARRAY_SIZE(tda998x_dai));
}
static int tda998x_dev_remove(struct platform_device *pdev)
{
snd_soc_unregister_codec(&pdev->dev);
return 0;
}
static const struct of_device_id tda998x_codec_ids[] = {
{ .compatible = "nxp,tda998x-codec", },
{ }
};
MODULE_DEVICE_TABLE(of, tda998x_codec_ids);
static struct platform_driver tda998x_driver = {
.probe = tda998x_dev_probe,
.remove = tda998x_dev_remove,
.driver = {
.name = "tda998x-codec",
.owner = THIS_MODULE,
.of_match_table = tda998x_codec_ids,
},
};
module_platform_driver(tda998x_driver);
MODULE_AUTHOR("Jean-Francois Moine");
MODULE_DESCRIPTION("TDA998x codec driver");
MODULE_LICENSE("GPL");
-------------------8<----------------
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH/RFC] dmaengine: omap-dma: split header file
From: Balaji T K @ 2014-01-24 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390582316-4765-1-git-send-email-balajitk@ti.com>
On Friday 24 January 2014 10:21 PM, Balaji T K wrote:
> To Resolve build failure seen with sh-allmodconfig:
> include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
> make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
> due to CCR redefinition, move dmaengine consumer specific function to omap-dmaengine.h
>
> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
s/Tested-by/Reported-by
> Signed-off-by: Balaji T K <balajitk@ti.com>
> ---
> drivers/mmc/host/omap_hsmmc.c | 2 +-
> include/linux/omap-dma.h | 19 +------------------
> include/linux/omap-dmaengine.h | 21 +++++++++++++++++++++
> 3 files changed, 23 insertions(+), 19 deletions(-)
> create mode 100644 include/linux/omap-dmaengine.h
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index dbd32ad..2f57e36 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -31,7 +31,7 @@
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> #include <linux/of_device.h>
> -#include <linux/omap-dma.h>
> +#include <linux/omap-dmaengine.h>
> #include <linux/mmc/host.h>
> #include <linux/mmc/core.h>
> #include <linux/mmc/mmc.h>
> diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> index 7af25a9..6aa97e5 100644
> --- a/include/linux/omap-dma.h
> +++ b/include/linux/omap-dma.h
> @@ -1,23 +1,6 @@
> -/*
> - * OMAP DMA Engine support
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> #ifndef __LINUX_OMAP_DMA_H
> #define __LINUX_OMAP_DMA_H
> -
> -struct dma_chan;
> -
> -#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
> -bool omap_dma_filter_fn(struct dma_chan *, void *);
> -#else
> -static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
> -{
> - return false;
> -}
> -#endif
> +#include <linux/omap-dmaengine.h>
>
> /*
> * Legacy OMAP DMA handling defines and functions
> diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
> new file mode 100644
> index 0000000..2b0b6aa
> --- /dev/null
> +++ b/include/linux/omap-dmaengine.h
> @@ -0,0 +1,21 @@
> +/*
> + * OMAP DMA Engine support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_OMAP_DMAENGINE_H
> +#define __LINUX_OMAP_DMAENGINE_H
> +
> +struct dma_chan;
> +
> +#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
> +bool omap_dma_filter_fn(struct dma_chan *, void *);
> +#else
> +static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
> +{
> + return false;
> +}
> +#endif
> +#endif /* __LINUX_OMAP_DMAENGINE_H */
>
^ permalink raw reply
* [PATCH/RFC] dmaengine: omap-dma: split header file
From: Balaji T K @ 2014-01-24 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119100235.GN27282@n2100.arm.linux.org.uk>
To Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine consumer specific function to omap-dmaengine.h
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Balaji T K <balajitk@ti.com>
---
drivers/mmc/host/omap_hsmmc.c | 2 +-
include/linux/omap-dma.h | 19 +------------------
include/linux/omap-dmaengine.h | 21 +++++++++++++++++++++
3 files changed, 23 insertions(+), 19 deletions(-)
create mode 100644 include/linux/omap-dmaengine.h
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..2f57e36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/of_device.h>
-#include <linux/omap-dma.h>
+#include <linux/omap-dmaengine.h>
#include <linux/mmc/host.h>
#include <linux/mmc/core.h>
#include <linux/mmc/mmc.h>
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9..6aa97e5 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
#ifndef __LINUX_OMAP_DMA_H
#define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
- return false;
-}
-#endif
+#include <linux/omap-dmaengine.h>
/*
* Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 0000000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+ return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */
--
1.7.5.4
^ permalink raw reply related
* [Linaro-acpi] [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Tomasz Nowicki @ 2014-01-24 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124125332.GA23274@e102568-lin.cambridge.arm.com>
Hi Lorenzo,
W dniu 24.01.2014 13:53, Lorenzo Pieralisi pisze:
> Hi Hanjun,
>
> On Fri, Jan 24, 2014 at 09:09:40AM +0000, Hanjun Guo wrote:
>> On 2014?01?23? 23:56, Tomasz Nowicki wrote:
>>> Hi Lorenzo,
>>>
>>> W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
>>>> On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>>>> index bd9bbd0..2210353 100644
>>>>> --- a/arch/arm64/kernel/setup.c
>>>>> +++ b/arch/arm64/kernel/setup.c
>>>>> @@ -41,6 +41,7 @@
>>>>> #include <linux/memblock.h>
>>>>> #include <linux/of_fdt.h>
>>>>> #include <linux/of_platform.h>
>>>>> +#include <linux/acpi.h>
>>>>>
>>>>> #include <asm/cputype.h>
>>>>> #include <asm/elf.h>
>>>>> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
>>>>>
>>>>> arm64_memblock_init();
>>>>>
>>>>> + /* Parse the ACPI tables for possible boot-time configuration */
>>>>> + acpi_boot_table_init();
>>>>> + early_acpi_boot_init();
>>>>> + acpi_boot_init();
>>>>> +
>>>>> paging_init();
>>>>
>>>> Can I ask you please why we need to parse ACPI tables before
>>>> paging_init() ?
>>> This is for future usage and because of couple of reasons. Mainly SRAT
>>> table parsing should be done (before paging_init()) for proper NUMA
>>> initialization and then paging_init().
>
> Thank you for the explanation. I still have some questions:
>
> 1) What are the other reasons ?
If we agreed that we need SRAT parsing before paging_init() the second
reason is all implications related to that. I mean if we want to make
ACPI tables parseable before paging_init(), we need early_ioremap
mechanism and __acpi_map_table() fixes. In that case, IMHO, it is better
to please it in the right place now. early_ioremap is object of UEFI
support patch set.
> 2) NUMA is not supported at the moment and I reckon SRAT needs updating
> since the only way to associate a CPU to a memory node is through
> a local APIC id that is non-existent on ARM and at least deserves a
> new entry.
Right, that requires further work on SRAT.
>
> I am still not sure that providing a hook for parsing the ACPI tables before
> paging_init() is the main focus at the moment, it is probably best, as we've
> mentioned manifold times, to make sure that the infrastructure to detect
> ACPI vs DT at run-time is in place in the kernel and allows us to boot
> either with ACPI or DT, in a mutual exclusive way (same binary kernel
> supporting both, runtime detection/decision on what data to use, ACPI tables
> vs DT nodes, detection made once for all and NOT on a per property basis).
>
> I will have a look at SRAT and how it is used on x86, and get back to you on
> this.
>
> [...]
>
>>>>> + * acpi_boot_table_init() and acpi_boot_init()
>>>>> + * called from setup_arch(), always.
>>>>> + * 1. checksums all tables
>>>>> + * 2. enumerates lapics
>>>>> + * 3. enumerates io-apics
>>>>> + *
>>>>> + * acpi_table_init() is separated to allow reading SRAT without
>>>>> + * other side effects.
>>>>> + */
>>>>> +void __init acpi_boot_table_init(void)
>>>>> +{
>>>>> + /*
>>>>> + * If acpi_disabled, bail out
>>>>> + */
>>>>> + if (acpi_disabled)
>>>>> + return;
>>>>> +
>>>>> + /*
>>>>> + * Initialize the ACPI boot-time table parser.
>>>>> + */
>>>>> + if (acpi_table_init()) {
>>>>> + disable_acpi();
>>>>> + return;
>>>>> + }
>>>>> +}
>>>>> +
>>>>> +int __init early_acpi_boot_init(void)
>>>>> +{
>>>>> + /*
>>>>> + * If acpi_disabled, bail out
>>>>> + */
>>>>> + if (acpi_disabled)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + /*
>>>>> + * Process the Multiple APIC Description Table (MADT), if present
>>>>> + */
>>>>> + early_acpi_process_madt();
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +int __init acpi_boot_init(void)
>>>>> +{
>>>>> + /*
>>>>> + * If acpi_disabled, bail out
>>>>> + */
>>>>> + if (acpi_disabled)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
>>>>> +
>>>>> + /*
>>>>> + * Process the Multiple APIC Description Table (MADT), if present
>>>>> + */
>>>>> + acpi_process_madt();
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>
>>>> Well, apart from having three init calls, one returning void and two
>>>> returning proper values, do not understand why, and do not understand
>>>> why we need three calls in the first place...why should we process MADT
>>>> twice in two separate calls ? What is supposed to change in between that
>>>> prevents you from merging the two together ?
>>
>> Thanks for pointing this out. I can merge acpi_boot_table_init() and
>> early_acpi_boot_init() together, but can not merge early_acpi_boot_init()
>> and acpi_boot_init() together.
>>
>> early_acpi_boot_init() and acpi_boot_init() was separated intentionally for
>> memory hotplug reasons. memory allocated in this stage can not be migrated
>> and cause memory hot-remove failed, in order to keep memory allocated
>> at base node (general NUMA node 0 in the system) at boot stage, we should
>> parse SRAT first before CPU is enumerated, does this make sense to you?
>
> Are you parsing the SRAT in this series to get memory info or memory is
> still initialized by DT even when system is supposed to be booted with ACPI
> (ie there is a valid ACPI root table ?)
>
> I have a hunch the latter is what's happening (and that's wrong, because
> memory information when kernel is booted through ACPI must be retrieved
> from UEFI - at least that's what has been defined), so I still see an early
> hook to initialize ACPI tables before paging_init() that has no use as the
> current patchset stands, please correct me if I am wrong.
Yes, currently memory is initialized by DT but getting memory map from
UEFI is the matter of time (pending upstream process). Also, SRAT table
is not parsing in this series but it will, and I think it plays the main
role to put it before paging_init.
Regards,
Tomasz
^ permalink raw reply
* [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
From: Will Deacon @ 2014-01-24 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-5-git-send-email-adrienverge@gmail.com>
On Fri, Jan 24, 2014 at 04:40:54PM +0000, Adrien Verg? wrote:
> When using namespaces, different processes can have the same PID.
> It makes no sense to store a PID value in the Context ID register
> to track a specific process, when others share the same value.
>
> Consequently, PID_IN_CONTEXTIDR (which is used for tracing and
> debugging processes) should not be compatible with PID_NS.
>
> Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
> ---
> arch/arm/Kconfig.debug | 2 +-
> arch/arm64/Kconfig.debug | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 5765abf..ed46748 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1143,7 +1143,7 @@ config ARM_KPROBES_TEST
>
> config PID_IN_CONTEXTIDR
> bool "Write the current PID to the CONTEXTIDR register"
> - depends on CPU_COPY_V6
> + depends on CPU_COPY_V6 && !PID_NS
> help
> Enabling this option causes the kernel to write the current PID to
> the PROCID field of the CONTEXTIDR register, at the expense of some
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 835c559..06b2633b 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -17,6 +17,7 @@ config EARLY_PRINTK
>
> config PID_IN_CONTEXTIDR
> bool "Write the current PID to the CONTEXTIDR register"
> + depends on !PID_NS
> help
> Enabling this option causes the kernel to write the current PID to
> the CONTEXTIDR register, at the expense of some additional
Are you sure about this? The value we write is actually task_pid_nr, which I
believe to be globally unique.
Will
^ permalink raw reply
* [PATCH V2 6/6] ARM CoreSight: ETM: Allocate a trace buffer only when necessary
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
Some user applications try to retrieve trace data often, there
is no need to call vmalloc() when there is 0 byte to fetch.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 54b5128..bc97240 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -309,7 +309,7 @@ static ssize_t etb_read(struct file *file, char __user *data,
long length;
struct tracectx *t = file->private_data;
u32 first = 0;
- u32 *buf;
+ u32 *buf = NULL;
mutex_lock(&t->mutex);
@@ -327,12 +327,14 @@ static ssize_t etb_read(struct file *file, char __user *data,
etb_writel(t, first, ETBR_READADDR);
length = min(total * 4, (int)len);
- buf = vmalloc(length);
+ if (length != 0)
+ buf = vmalloc(length);
dev_dbg(t->dev, "ETB buffer length: %d\n", total);
dev_dbg(t->dev, "ETB status reg: %x\n", etb_readl(t, ETBR_STATUS));
- for (i = 0; i < length / 4; i++)
- buf[i] = etb_readl(t, ETBR_READMEM);
+ if (buf)
+ for (i = 0; i < length / 4; i++)
+ buf[i] = etb_readl(t, ETBR_READMEM);
/* the only way to deassert overflow bit in ETB status is this */
etb_writel(t, 1, ETBR_CTRL);
@@ -345,7 +347,8 @@ static ssize_t etb_read(struct file *file, char __user *data,
etb_lock(t);
length -= copy_to_user(data, buf, length);
- vfree(buf);
+ if (buf)
+ vfree(buf);
out:
mutex_unlock(&t->mutex);
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 5/6] ARM CoreSight: ETM: Add PID control support
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
In the same manner as for enabling tracing, an entry is created in
sysfs to set the PID that triggers tracing. This change is effective
only if CONFIG_PID_IN_CONTEXTIDR is set, and thus is not compatible
with PID namespaces.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/include/asm/hardware/coresight.h | 5 ++
arch/arm/kernel/etm.c | 82 ++++++++++++++++++++++++++++---
2 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
index 8c50cf6..2051af0 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -98,6 +98,11 @@
#define ETMR_ADDRCOMP_VAL(x) (0x40 + (x) * 4)
#define ETMR_ADDRCOMP_ACC_TYPE(x) (0x80 + (x) * 4)
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+#define ETMR_CTXIDCOMP_VAL(x) (0x1b0 + (x) * 4)
+#define ETMR_CTXIDCOMP_MASK (0x1bc)
+#endif
+
/* ETM status register, "ETM Architecture", 3.3.2 */
#define ETMR_STATUS (0x10)
#define ETMST_OVERFLOW BIT(0)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 4442e5c..54b5128 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -40,12 +40,14 @@ struct tracectx {
void __iomem *etm_regs;
unsigned long flags;
int naddrcmppairs;
+ int nctxidcmp;
int etm_portsz;
struct device *dev;
struct clk *emu_clk;
struct mutex mutex;
unsigned long addrrange_start;
unsigned long addrrange_end;
+ int pid;
};
static struct tracectx tracer;
@@ -59,14 +61,18 @@ static inline bool trace_isrunning(struct tracectx *t)
* Setups ETM to trace only when:
* - address between start and end
* or address not between start and end (if exclude)
+ * - in user-space when process id equals pid,
+ * in kernel-space (if pid == 0),
+ * always (if pid == -1)
* - trace executed instructions
* or trace loads and stores (if data)
*/
-static int etm_setup_address_range(struct tracectx *t, int n,
- unsigned long start, unsigned long end, int exclude, int data)
+static int etm_setup(struct tracectx *t, int n,
+ unsigned long start, unsigned long end, int exclude,
+ int pid,
+ int data)
{
- u32 flags = ETMAAT_ARM | ETMAAT_IGNCONTEXTID | ETMAAT_NSONLY | \
- ETMAAT_NOVALCMP;
+ u32 flags = ETMAAT_ARM | ETMAAT_NSONLY | ETMAAT_NOVALCMP;
if (n < 1 || n > t->naddrcmppairs)
return -EINVAL;
@@ -75,6 +81,23 @@ static int etm_setup_address_range(struct tracectx *t, int n,
* to bits in a word */
n--;
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ if (pid < 0) {
+ /* ignore Context ID */
+ flags |= ETMAAT_IGNCONTEXTID;
+ } else {
+ flags |= ETMAAT_VALUE1;
+
+ /* Set up the first Context ID comparator.
+ Process ID is found in the 24 first bits of Context ID
+ (provided by CONFIG_PID_IN_CONTEXTIDR) */
+ etm_writel(t, pid << 8, ETMR_CTXIDCOMP_VAL(0));
+ etm_writel(t, 0xff, ETMR_CTXIDCOMP_MASK);
+ }
+#else
+ flags |= ETMAAT_IGNCONTEXTID;
+#endif
+
if (data)
flags |= ETMAAT_DLOADSTORE;
else
@@ -124,8 +147,10 @@ static int trace_start(struct tracectx *t)
return -EFAULT;
}
- etm_setup_address_range(t, 1, t->addrrange_start, t->addrrange_end,
- 0, 0);
+ etm_setup(t, 1,
+ t->addrrange_start, t->addrrange_end, 0,
+ t->pid,
+ 0);
etm_writel(t, 0, ETMR_TRACEENCTRL2);
etm_writel(t, 0, ETMR_TRACESSCTRL);
etm_writel(t, 0x6f, ETMR_TRACEENEVT);
@@ -486,6 +511,7 @@ static ssize_t trace_info_show(struct device *dev,
return sprintf(buf, "Trace buffer len: %d\n"
"Addr comparator pairs: %d\n"
+ "Ctx ID comparators: %d\n"
"ETBR_WRITEADDR:\t%08x\n"
"ETBR_READADDR:\t%08x\n"
"ETBR_STATUS:\t%08x\n"
@@ -494,6 +520,7 @@ static ssize_t trace_info_show(struct device *dev,
"ETMR_STATUS:\t%08x\n",
datalen,
tracer.naddrcmppairs,
+ tracer.nctxidcmp,
etb_wa,
etb_ra,
etb_st,
@@ -566,6 +593,36 @@ static ssize_t trace_addrrange_store(struct device *dev,
DEVICE_ATTR(trace_addrrange, S_IRUGO|S_IWUSR,
trace_addrrange_show, trace_addrrange_store);
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+static ssize_t trace_pid_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", tracer.pid);
+}
+
+static ssize_t trace_pid_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ int pid;
+
+ if (tracer.flags & TRACER_RUNNING)
+ return -EBUSY;
+
+ if (sscanf(buf, "%i", &pid) != 1)
+ return -EINVAL;
+
+ mutex_lock(&tracer.mutex);
+ tracer.pid = pid;
+ mutex_unlock(&tracer.mutex);
+
+ return n;
+}
+
+DEVICE_ATTR(trace_pid, S_IRUGO|S_IWUSR, trace_pid_show, trace_pid_store);
+#endif
+
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
struct tracectx *t = &tracer;
@@ -595,6 +652,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
t->etm_portsz = 1;
t->addrrange_start = (unsigned long) _stext;
t->addrrange_end = (unsigned long) _etext;
+ t->pid = -1; /* trace everything */
etm_unlock(t);
(void)etm_readl(t, ETMMR_PDSR);
@@ -602,6 +660,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
(void)etm_readl(&tracer, ETMMR_OSSRR);
t->naddrcmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
+ t->nctxidcmp = (etm_readl(t, ETMR_CONFCODE) >> 24) & 0x3;
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
@@ -609,7 +668,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto out_unmap;
- /* failing to create any of these three is not fatal */
+ /* failing to create any of these four is not fatal */
ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
@@ -622,6 +681,12 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_addrrange in sysfs\n");
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ ret = device_create_file(&dev->dev, &dev_attr_trace_pid);
+ if (ret)
+ dev_dbg(&dev->dev, "Failed to create trace_pid in sysfs\n");
+#endif
+
dev_dbg(t->dev, "ETM AMBA driver initialized.\n");
out:
@@ -652,6 +717,9 @@ static int etm_remove(struct amba_device *dev)
device_remove_file(&dev->dev, &dev_attr_trace_info);
device_remove_file(&dev->dev, &dev_attr_trace_mode);
device_remove_file(&dev->dev, &dev_attr_trace_addrrange);
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ device_remove_file(&dev->dev, &dev_attr_trace_pid);
+#endif
return 0;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
When using namespaces, different processes can have the same PID.
It makes no sense to store a PID value in the Context ID register
to track a specific process, when others share the same value.
Consequently, PID_IN_CONTEXTIDR (which is used for tracing and
debugging processes) should not be compatible with PID_NS.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/Kconfig.debug | 2 +-
arch/arm64/Kconfig.debug | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 5765abf..ed46748 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1143,7 +1143,7 @@ config ARM_KPROBES_TEST
config PID_IN_CONTEXTIDR
bool "Write the current PID to the CONTEXTIDR register"
- depends on CPU_COPY_V6
+ depends on CPU_COPY_V6 && !PID_NS
help
Enabling this option causes the kernel to write the current PID to
the PROCID field of the CONTEXTIDR register, at the expense of some
diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 835c559..06b2633b 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -17,6 +17,7 @@ config EARLY_PRINTK
config PID_IN_CONTEXTIDR
bool "Write the current PID to the CONTEXTIDR register"
+ depends on !PID_NS
help
Enabling this option causes the kernel to write the current PID to
the CONTEXTIDR register, at the expense of some additional
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 3/6] ARM CoreSight: ETM: Add address control support
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
In the same manner as for enabling tracing, an entry is created
in sysfs to set the address range that triggers tracing.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 7f7a0ee..4442e5c 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -44,6 +44,8 @@ struct tracectx {
struct device *dev;
struct clk *emu_clk;
struct mutex mutex;
+ unsigned long addrrange_start;
+ unsigned long addrrange_end;
};
static struct tracectx tracer;
@@ -53,6 +55,13 @@ static inline bool trace_isrunning(struct tracectx *t)
return !!(t->flags & TRACER_RUNNING);
}
+/*
+ * Setups ETM to trace only when:
+ * - address between start and end
+ * or address not between start and end (if exclude)
+ * - trace executed instructions
+ * or trace loads and stores (if data)
+ */
static int etm_setup_address_range(struct tracectx *t, int n,
unsigned long start, unsigned long end, int exclude, int data)
{
@@ -115,8 +124,8 @@ static int trace_start(struct tracectx *t)
return -EFAULT;
}
- etm_setup_address_range(t, 1, (unsigned long)_stext,
- (unsigned long)_etext, 0, 0);
+ etm_setup_address_range(t, 1, t->addrrange_start, t->addrrange_end,
+ 0, 0);
etm_writel(t, 0, ETMR_TRACEENCTRL2);
etm_writel(t, 0, ETMR_TRACESSCTRL);
etm_writel(t, 0x6f, ETMR_TRACEENEVT);
@@ -527,6 +536,36 @@ static ssize_t trace_mode_store(struct device *dev,
DEVICE_ATTR(trace_mode, S_IRUGO|S_IWUSR, trace_mode_show, trace_mode_store);
+static ssize_t trace_addrrange_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%08lx - %08lx\n", tracer.addrrange_start,
+ tracer.addrrange_end);
+}
+
+static ssize_t trace_addrrange_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned long start, end;
+
+ if (tracer.flags & TRACER_RUNNING)
+ return -EBUSY;
+
+ if (sscanf(buf, "%08lx - %08lx", &start, &end) != 2)
+ return -EINVAL;
+
+ mutex_lock(&tracer.mutex);
+ tracer.addrrange_start = start;
+ tracer.addrrange_end = end;
+ mutex_unlock(&tracer.mutex);
+
+ return n;
+}
+
+DEVICE_ATTR(trace_addrrange, S_IRUGO|S_IWUSR,
+ trace_addrrange_show, trace_addrrange_store);
+
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
struct tracectx *t = &tracer;
@@ -554,6 +593,8 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
t->dev = &dev->dev;
t->flags = TRACER_CYCLE_ACC;
t->etm_portsz = 1;
+ t->addrrange_start = (unsigned long) _stext;
+ t->addrrange_end = (unsigned long) _etext;
etm_unlock(t);
(void)etm_readl(t, ETMMR_PDSR);
@@ -568,7 +609,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto out_unmap;
- /* failing to create any of these two is not fatal */
+ /* failing to create any of these three is not fatal */
ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
@@ -577,6 +618,10 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_mode in sysfs\n");
+ ret = device_create_file(&dev->dev, &dev_attr_trace_addrrange);
+ if (ret)
+ dev_dbg(&dev->dev, "Failed to create trace_addrrange in sysfs\n");
+
dev_dbg(t->dev, "ETM AMBA driver initialized.\n");
out:
@@ -606,6 +651,7 @@ static int etm_remove(struct amba_device *dev)
device_remove_file(&dev->dev, &dev_attr_trace_running);
device_remove_file(&dev->dev, &dev_attr_trace_info);
device_remove_file(&dev->dev, &dev_attr_trace_mode);
+ device_remove_file(&dev->dev, &dev_attr_trace_addrrange);
return 0;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 2/6] ARM CoreSight: ETM: Rename 'comparator' to 'address comparator'
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
Since there are different types of comparators, and other kinds will
be used (such as Context ID comparators), rename them properly.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/include/asm/hardware/coresight.h | 4 ++--
arch/arm/kernel/etm.c | 19 ++++++++++---------
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
index ad774f3..8c50cf6 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -95,8 +95,8 @@
#define ETMAAT_NSONLY (1 << 10)
#define ETMAAT_SONLY (2 << 10)
-#define ETMR_COMP_VAL(x) (0x40 + (x) * 4)
-#define ETMR_COMP_ACC_TYPE(x) (0x80 + (x) * 4)
+#define ETMR_ADDRCOMP_VAL(x) (0x40 + (x) * 4)
+#define ETMR_ADDRCOMP_ACC_TYPE(x) (0x80 + (x) * 4)
/* ETM status register, "ETM Architecture", 3.3.2 */
#define ETMR_STATUS (0x10)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 2b1a307..7f7a0ee 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -39,7 +39,7 @@ struct tracectx {
void __iomem *etb_regs;
void __iomem *etm_regs;
unsigned long flags;
- int ncmppairs;
+ int naddrcmppairs;
int etm_portsz;
struct device *dev;
struct clk *emu_clk;
@@ -59,7 +59,7 @@ static int etm_setup_address_range(struct tracectx *t, int n,
u32 flags = ETMAAT_ARM | ETMAAT_IGNCONTEXTID | ETMAAT_NSONLY | \
ETMAAT_NOVALCMP;
- if (n < 1 || n > t->ncmppairs)
+ if (n < 1 || n > t->naddrcmppairs)
return -EINVAL;
/* comparators and ranges are numbered starting with 1 as opposed
@@ -72,12 +72,12 @@ static int etm_setup_address_range(struct tracectx *t, int n,
flags |= ETMAAT_IEXEC;
/* first comparator for the range */
- etm_writel(t, flags, ETMR_COMP_ACC_TYPE(n * 2));
- etm_writel(t, start, ETMR_COMP_VAL(n * 2));
+ etm_writel(t, flags, ETMR_ADDRCOMP_ACC_TYPE(n * 2));
+ etm_writel(t, start, ETMR_ADDRCOMP_VAL(n * 2));
/* second comparator is right next to it */
- etm_writel(t, flags, ETMR_COMP_ACC_TYPE(n * 2 + 1));
- etm_writel(t, end, ETMR_COMP_VAL(n * 2 + 1));
+ etm_writel(t, flags, ETMR_ADDRCOMP_ACC_TYPE(n * 2 + 1));
+ etm_writel(t, end, ETMR_ADDRCOMP_VAL(n * 2 + 1));
flags = exclude ? ETMTE_INCLEXCL : 0;
etm_writel(t, flags | (1 << n), ETMR_TRACEENCTRL);
@@ -475,7 +475,8 @@ static ssize_t trace_info_show(struct device *dev,
etm_st = etm_readl(&tracer, ETMR_STATUS);
etm_lock(&tracer);
- return sprintf(buf, "Trace buffer len: %d\nComparator pairs: %d\n"
+ return sprintf(buf, "Trace buffer len: %d\n"
+ "Addr comparator pairs: %d\n"
"ETBR_WRITEADDR:\t%08x\n"
"ETBR_READADDR:\t%08x\n"
"ETBR_STATUS:\t%08x\n"
@@ -483,7 +484,7 @@ static ssize_t trace_info_show(struct device *dev,
"ETMR_CTRL:\t%08x\n"
"ETMR_STATUS:\t%08x\n",
datalen,
- tracer.ncmppairs,
+ tracer.naddrcmppairs,
etb_wa,
etb_ra,
etb_st,
@@ -559,7 +560,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
/* dummy first read */
(void)etm_readl(&tracer, ETMMR_OSSRR);
- t->ncmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
+ t->naddrcmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 1/6] ARM CoreSight: ETM: Use device attributes
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390581656-16372-1-git-send-email-adrienverge@gmail.com>
Replace all kobjects attributes with device attributes.
User experience isn't changed since the same files are created in sysfs.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 48 +++++++++++++++++++++---------------------------
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 8ff0ecd..2b1a307 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -430,15 +430,14 @@ static struct amba_driver etb_driver = {
};
/* use a sysfs file "trace_running" to start/stop tracing */
-static ssize_t trace_running_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_running_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%x\n", trace_isrunning(&tracer));
}
-static ssize_t trace_running_store(struct kobject *kobj,
- struct kobj_attribute *attr,
+static ssize_t trace_running_store(struct device *dev,
+ struct device_attribute *attr,
const char *buf, size_t n)
{
unsigned int value;
@@ -454,12 +453,11 @@ static ssize_t trace_running_store(struct kobject *kobj,
return ret ? : n;
}
-static struct kobj_attribute trace_running_attr =
- __ATTR(trace_running, 0644, trace_running_show, trace_running_store);
+DEVICE_ATTR(trace_running, S_IRUGO|S_IWUSR,
+ trace_running_show, trace_running_store);
-static ssize_t trace_info_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_info_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
u32 etb_wa, etb_ra, etb_st, etb_fc, etm_ctrl, etm_st;
int datalen;
@@ -495,21 +493,19 @@ static ssize_t trace_info_show(struct kobject *kobj,
);
}
-static struct kobj_attribute trace_info_attr =
- __ATTR(trace_info, 0444, trace_info_show, NULL);
+DEVICE_ATTR(trace_info, S_IRUGO, trace_info_show, NULL);
-static ssize_t trace_mode_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%d %d\n",
!!(tracer.flags & TRACER_CYCLE_ACC),
tracer.etm_portsz);
}
-static ssize_t trace_mode_store(struct kobject *kobj,
- struct kobj_attribute *attr,
- const char *buf, size_t n)
+static ssize_t trace_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
{
unsigned int cycacc, portsz;
@@ -528,8 +524,7 @@ static ssize_t trace_mode_store(struct kobject *kobj,
return n;
}
-static struct kobj_attribute trace_mode_attr =
- __ATTR(trace_mode, 0644, trace_mode_show, trace_mode_store);
+DEVICE_ATTR(trace_mode, S_IRUGO|S_IWUSR, trace_mode_show, trace_mode_store);
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
@@ -568,17 +563,16 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
- ret = sysfs_create_file(&dev->dev.kobj,
- &trace_running_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_running);
if (ret)
goto out_unmap;
/* failing to create any of these two is not fatal */
- ret = sysfs_create_file(&dev->dev.kobj, &trace_info_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
- ret = sysfs_create_file(&dev->dev.kobj, &trace_mode_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_mode);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_mode in sysfs\n");
@@ -608,9 +602,9 @@ static int etm_remove(struct amba_device *dev)
amba_release_regions(dev);
- sysfs_remove_file(&dev->dev.kobj, &trace_running_attr.attr);
- sysfs_remove_file(&dev->dev.kobj, &trace_info_attr.attr);
- sysfs_remove_file(&dev->dev.kobj, &trace_mode_attr.attr);
+ device_remove_file(&dev->dev, &dev_attr_trace_running);
+ device_remove_file(&dev->dev, &dev_attr_trace_info);
+ device_remove_file(&dev->dev, &dev_attr_trace_mode);
return 0;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH V2 0/6] ARM CoreSight: Enhance ETM tracing control
From: Adrien Vergé @ 2014-01-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Different ARM users have shown their interest in this patch, so I made
a second version that corrects the first mistakes.
Mainly, it extends current support of CoreSight ETM, that is currently
very limited. ETM provides hardware-assisted program tracing, a
cycle-precise and low-overhead solution that software tools such as
'perf record' cannot provide.
Usage of ETM tracing facility is presently limited to start and stop
tracing. This set of patches enables management of address combinations
and PIDs that trigger tracing, thus allowing to trace specific
functions and processes.
ETM management was done via sysfs entries (trace_info,
trace_running...), this code adds trace_addrrange and trace_pid to
let the user read/write custom values.
Changes in V2:
- Use device attributes rather than raw kobjects
- Make PID_IN_CONTEXTIDR incompatible with PID_NS in Kconfig
- Use int for pid type (not long)
- During trace fetching, call vmalloc() only if really needed
This series of patches applies to v3.13.
Adrien Verg? (6):
ARM CoreSight: ETM: Use device attributes
ARM CoreSight: ETM: Rename 'comparator' to 'address comparator'
ARM CoreSight: ETM: Add address control support
ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
ARM CoreSight: ETM: Add PID control support
ARM CoreSight: ETM: Allocate a trace buffer only when necessary
arch/arm/Kconfig.debug | 2 +-
arch/arm/include/asm/hardware/coresight.h | 9 +-
arch/arm/kernel/etm.c | 208 +++++++++++++++++++++++-------
arch/arm64/Kconfig.debug | 1 +
4 files changed, 169 insertions(+), 51 deletions(-)
--
1.8.5.2
^ permalink raw reply
* [PATCH 1/6] arm64: Add macros to manage processor debug state
From: Will Deacon @ 2014-01-24 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390490948-25386-1-git-send-email-vijay.kilari@gmail.com>
Hello,
On Thu, Jan 23, 2014 at 03:29:07PM +0000, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>
> Add macros to enable and disable to manage PSTATE.D
> for debugging. The macros local_dbg_save and local_dbg_restore
> are moved to irqflags.h file
>
> KGDB boot tests fail because of PSTATE.D is masked.
> unmask it for debugging support
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
> arch/arm64/include/asm/debug-monitors.h | 17 -----------
> arch/arm64/include/asm/irqflags.h | 48 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/debug-monitors.c | 1 +
> 3 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> index 6231479..ee9f28e 100644
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -43,23 +43,6 @@ enum debug_el {
> #ifndef __ASSEMBLY__
> struct task_struct;
>
> -#define local_dbg_save(flags) \
> - do { \
> - typecheck(unsigned long, flags); \
> - asm volatile( \
> - "mrs %0, daif // local_dbg_save\n" \
> - "msr daifset, #8" \
> - : "=r" (flags) : : "memory"); \
> - } while (0)
> -
> -#define local_dbg_restore(flags) \
> - do { \
> - typecheck(unsigned long, flags); \
> - asm volatile( \
> - "msr daif, %0 // local_dbg_restore\n" \
> - : : "r" (flags) : "memory"); \
> - } while (0)
> -
> #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
>
> #define DBG_HOOK_HANDLED 0
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index b2fcfbc..f9b013e 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -90,5 +90,53 @@ static inline int arch_irqs_disabled_flags(unsigned long flags)
> return flags & PSR_I_BIT;
> }
>
> +/*
> + * save and restore debug state
> + */
> +static inline unsigned long arch_local_dbg_save(void)
> +{
> + unsigned long flags;
> + asm volatile(
> + "mrs %0, daif // arch_local_dbg_save"
> + "msr daifset, #8"
> + : "=r" (flags) : : "memory");
> + return flags;
> +}
> +
> +static inline void arch_local_dbg_restore(unsigned long flags)
> +{
> + asm volatile(
> + "msr daif, %0 // arch_local_dbg_restore"
> + :
> + : "r" (flags)
> + : "memory");
> +}
> +
> +#define raw_local_dbg_save(flags) \
> + do { \
> + typecheck(unsigned long, flags); \
> + flags = arch_local_dbg_save(); \
> + } while (0)
> +
> +#define raw_local_dbg_restore(flags) \
> + do { \
> + typecheck(unsigned long, flags); \
> + arch_local_dbg_restore(flags); \
> + } while (0)
> +
> +#define local_dbg_save(flags) \
> + do { \
> + raw_local_dbg_save(flags); \
> + } while (0)
> +
> +#define local_dbg_restore(flags) \
> + do { \
> + typecheck(unsigned long, flags); \
> + raw_local_dbg_restore(flags); \
> + } while (0)
Hehe, I think you took me a bit too literally when I said to follow what we
do for irqs. This code is arm64-specific, so you don't need to construct it
in the same way. All you need to do is *move* the existing code from
debug-monitors.h to irqflags.h. That's it!
> +#define local_dbg_enable() asm("msr daifclr, #8" : : : "memory")
> +#define local_dbg_disable() asm("msr daifset, #8" : : : "memory")
I'm also fine with adding these two.
Will
^ permalink raw reply
* [PATCH v5 0/4] perf: AARCH64 arch support
From: Will Deacon @ 2014-01-24 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390399879-5109-1-git-send-email-jean.pihet@linaro.org>
Hi Jean,
On Wed, Jan 22, 2014 at 02:11:15PM +0000, Jean Pihet wrote:
> Add AARCH64 specific support. This includes the following:
> - AARCH64 perf registers definition and hooks,
> - compat mode registers use, i.e. profiling a 32-bit binary on
> a 64-bit system,
> - unwinding using the dwarf information from the .debug_frame
> section of the ELF binary,
> - unwinding using the frame pointer information; in 64-bit and
> compat modes.
>
> Note: support for unwinding using the dwarf information in compat
> mode requires some changes to the libunwind code. Those changes
> have been submitted on the libunwind ML and are in discussion.
>
> Tested on ARMv7, ARMv8 and x86_64 platforms. The compat mode has been
> tested on ARMv8 using statically built 32-bit binaries.
This is look alright to me now, but there are still two blockers:
(1) Getting the libunwind code merged
(2) Splitting this into an arch/arm64 series and a tools/perf series, so
that acme can merge the latter independently (and avoid the mess we had
last time).
Anyway, for the series:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v5 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver
From: Tomasz Figa @ 2014-01-24 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389238094-19386-5-git-send-email-shaik.ameer@samsung.com>
Hi Shaik,
On 09.01.2014 04:28, Shaik Ameer Basha wrote:
> This patch adds the DT binding documentation for the
> Exynos5420/5410 based SCALER device driver.
>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> .../devicetree/bindings/media/exynos5-scaler.txt | 22 ++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
>
> diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> new file mode 100644
> index 0000000..9328e7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> @@ -0,0 +1,22 @@
> +* Samsung Exynos5 SCALER device
> +
> +SCALER is used for scaling, blending, color fill and color space
> +conversion on EXYNOS[5420/5410] SoCs.
> +
> +Required properties:
> +- compatible: should be "samsung,exynos5420-scaler" or
> + "samsung,exynos5410-scaler"
> +- reg: should contain SCALER physical address location and length
> +- interrupts: should contain SCALER interrupt number
s/number/specifier/
> +- clocks: should contain the SCALER clock specifier, from the
> + common clock bindings
s/specifier/phandle and specifier pair for each clock listed in
clock-names property/
s/from/according to/
> +- clock-names: should be "scaler"
should contain exactly one entry:
- "scaler" - IP bus clock.
Also this patch should be first in the series to let the driver added in
further patches use already present bindings.
Best regards,
Tomasz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox