* Re: [PATCH V4 08/10] powerpc, perf: Enable SW filtering in branch stack sampling framework
From: Anshuman Khandual @ 2013-12-12 8:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: mikey, ak, linux-kernel, eranian, linuxppc-dev, acme, sukadev,
mingo
In-Reply-To: <52A6AD61.4050408@linux.vnet.ibm.com>
On 12/10/2013 11:27 AM, Anshuman Khandual wrote:
> On 12/09/2013 11:51 AM, Michael Ellerman wrote:
>> This code was already in need of some unindentation, and now it's just
>> ridiculous.
>>
>> To start with at the beginning of this routine we have:
>>
>> while (..) {
>> if (!val)
>> break;
>> else {
>> // Bulk of the logic
>> ...
>> }
>> }
>>
>> That should almost always become:
>>
>> while (..) {
>> if (!val)
>> break;
>>
>> // Bulk of the logic
>> ...
>> }
>>
>>
>> But in this case that's not enough. Please send a precursor patch which moves
>> this logic out into a helper function.
>
> Hey Michael,
>
> I believe this patch should be able to take care of this.
>
> commit d66d729715cabe0cfd8e34861a6afa8ad639ddf3
> Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Date: Tue Dec 10 11:10:06 2013 +0530
>
> power, perf: Clean up BHRB processing
>
> This patch cleans up some indentation problem and re-organizes the
> BHRB processing code with an additional helper function.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 29b89e8..9ae96c5 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -400,11 +400,20 @@ static __u64 power_pmu_bhrb_to(u64 addr)
> return target - (unsigned long)&instr + addr;
> }
>
> +void update_branch_entry(struct cpu_hw_events *cpuhw, int u_index, u64 from, u64 to, int pred)
> +{
> + cpuhw->bhrb_entries[u_index].from = from;
> + cpuhw->bhrb_entries[u_index].to = to;
> + cpuhw->bhrb_entries[u_index].mispred = pred;
> + cpuhw->bhrb_entries[u_index].predicted = ~pred;
> + return;
> +}
> +
> /* Processing BHRB entries */
> void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
> {
> u64 val;
> - u64 addr;
> + u64 addr, tmp;
> int r_index, u_index, pred;
>
> r_index = 0;
> @@ -415,62 +424,54 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
> if (!val)
> /* Terminal marker: End of valid BHRB entries */
> break;
> - else {
> - addr = val & BHRB_EA;
> - pred = val & BHRB_PREDICTION;
>
> - if (!addr)
> - /* invalid entry */
> - continue;
> + addr = val & BHRB_EA;
> + pred = val & BHRB_PREDICTION;
>
> - /* Branches are read most recent first (ie. mfbhrb 0 is
> - * the most recent branch).
> - * There are two types of valid entries:
> - * 1) a target entry which is the to address of a
> - * computed goto like a blr,bctr,btar. The next
> - * entry read from the bhrb will be branch
> - * corresponding to this target (ie. the actual
> - * blr/bctr/btar instruction).
> - * 2) a from address which is an actual branch. If a
> - * target entry proceeds this, then this is the
> - * matching branch for that target. If this is not
> - * following a target entry, then this is a branch
> - * where the target is given as an immediate field
> - * in the instruction (ie. an i or b form branch).
> - * In this case we need to read the instruction from
> - * memory to determine the target/to address.
> + if (!addr)
> + /* invalid entry */
> + continue;
> +
> + /* Branches are read most recent first (ie. mfbhrb 0 is
> + * the most recent branch).
> + * There are two types of valid entries:
> + * 1) a target entry which is the to address of a
> + * computed goto like a blr,bctr,btar. The next
> + * entry read from the bhrb will be branch
> + * corresponding to this target (ie. the actual
> + * blr/bctr/btar instruction).
> + * 2) a from address which is an actual branch. If a
> + * target entry proceeds this, then this is the
> + * matching branch for that target. If this is not
> + * following a target entry, then this is a branch
> + * where the target is given as an immediate field
> + * in the instruction (ie. an i or b form branch).
> + * In this case we need to read the instruction from
> + * memory to determine the target/to address.
> + */
> + if (val & BHRB_TARGET) {
> + /* Target branches use two entries
> + * (ie. computed gotos/XL form)
> */
> + tmp = addr;
>
> + /* Get from address in next entry */
> + val = read_bhrb(r_index++);
> + addr = val & BHRB_EA;
> if (val & BHRB_TARGET) {
> - /* Target branches use two entries
> - * (ie. computed gotos/XL form)
> - */
> - cpuhw->bhrb_entries[u_index].to = addr;
> - cpuhw->bhrb_entries[u_index].mispred = pred;
> - cpuhw->bhrb_entries[u_index].predicted = ~pred;
> -
> - /* Get from address in next entry */
> - val = read_bhrb(r_index++);
> - addr = val & BHRB_EA;
> - if (val & BHRB_TARGET) {
> - /* Shouldn't have two targets in a
> - row.. Reset index and try again */
> - r_index--;
> - addr = 0;
> - }
> - cpuhw->bhrb_entries[u_index].from = addr;
> - } else {
> - /* Branches to immediate field
> - (ie I or B form) */
> - cpuhw->bhrb_entries[u_index].from = addr;
> - cpuhw->bhrb_entries[u_index].to =
> - power_pmu_bhrb_to(addr);
> - cpuhw->bhrb_entries[u_index].mispred = pred;
> - cpuhw->bhrb_entries[u_index].predicted = ~pred;
> + /* Shouldn't have two targets in a
> + row.. Reset index and try again */
> + r_index--;
> + addr = 0;
> }
> - u_index++;
> -
> + update_branch_entry(cpuhw, u_index, addr, tmp, pred);
> + } else {
> + /* Branches to immediate field
> + (ie I or B form) */
> + tmp = power_pmu_bhrb_to(addr);
> + update_branch_entry(cpuhw, u_index, addr, tmp, pred);
> }
> + u_index++;
> }
> cpuhw->bhrb_stack.nr = u_index;
> return;
Hey Michael,
Does the patch looks okay ? In which case will send it out separately. Do let
me know. Thank you.
Regards
Anshuman
^ permalink raw reply
* Re: [PATCH] DTS: DMA: Fix DMA3 interrupts
From: Hongbo Zhang @ 2013-12-12 9:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1386700403.10013.109.camel@snotra.buserror.net>
On 12/11/2013 02:33 AM, Scott Wood wrote:
> On Tue, 2013-12-10 at 18:33 +0800, Hongbo Zhang wrote:
>> Scott,
>> This issue is due to the non-continuous MPIC register, I think there is
>> two ways to fix it.
>>
>> The first one is as what we are discussing, in fact the Bman/Qman DT
>> author had introduced this way, and I had to follow it, it is a trick,
>> adding 208 is a bit ugly I think, and even difficult to explain it to
>> customers etc, but this way changes less codes.
>>
>> The second one is editing MPIC related codes without adding 208 to high
>> interrupts. The point of translate interrupt number to MPIC register
>> address is a so called 'isu' mechanism, we can do like the following
>> example codes, then the tricky adding 208 isn't needed any more.
>>
>> Which one do you prefer?
>> In fact I myself prefer the second, if the idea is acceptable, I will
>> send a patch instead of this one. (and also alone with the internal
>> patch decreasing 208 for the Bman/Qman)
>>
>> void __init corenet_ds_pic_init(void)
>> {
>> ......
>>
>> mpic = mpic_alloc(NULL, 0, flags, 0, 512, "OpenPIC");
>> BUG_ON(mpic == NULL);
>>
>> // Add this start
>> for (i = 0; i < 17; i++) {
>> if (i < 11)
>> addr_off = 0x10000 + 0x20 * 16 * i;
>> else
>> addr_off = 0x13000 + 0x20 * 16 * (i - 11); /* scape the
>> address not for interrupts */
>> mpic_assign_isu(mpic, i, mpic->paddr + addr_off);
>> }
>> // Add this end
>>
>> mpic_init(mpic);
>> }
> NACK
>
> We already have a binding that states that the interrupt number is based
> on the register offset, rather than whatever arbitrary numbers hardware
> documenters decide to use next week.
>
> While I'm not terribly happy with the usability of this, especially now
> that it's not a simple "add 16", redefining the existing binding is not
> OK (and in any case the code above seems obfuscatory). If we decide to
> do something other than continue with register offset divided by 32,
> then we need to define a new interrupt type (similar to current defined
> types of error interrupt, timer, and IPI) for the new numberspace -- and
> it should be handled when decoding that type of interrupt specifier,
> rather than with the isu mechanism.
>
> -Scott
>
>
Scott,
Thanks for your comments. Since the second way isn't so good, let's
choose the original one.
But we meet a small accident now.
My patch is based on the http://patchwork.ozlabs.org/patch/291553/,
which had been superseded, so this thread can be closed now.
And Shenzhou has already sent a complete dma3 dtsi patch including
correct interrupt numbers, http://patchwork.ozlabs.org/patch/300026/, so
let's focus on this patch, and I will forward your first comments of my
patch there.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component
From: Hongbo Zhang @ 2013-12-12 9:57 UTC (permalink / raw)
To: Shengzhou Liu, linuxppc-dev, scottwood
In-Reply-To: <1386760774-14743-1-git-send-email-Shengzhou.Liu@freescale.com>
Shengzhou,
I canceled my patch http://patchwork.ozlabs.org/patch/295157/ because
the original wrong elo3-dma-2.dtsi hadn't been merged.
But please pay attention to comments from Scott about my changes of
adding 208 for some interrupts, and take some actions if needed, or
further discussions.
Below comments form Scott:
"The FSL MPIC binding should be updated to point out how this works.
Technically it's not a change to the binding itself, since it's defined
in terms of register offset, but the explanatory text says "So interrupt
0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on." which is
not accurate for these new high interrupt numbers."
On 12/11/2013 07:19 PM, Shengzhou Liu wrote:
> Add elo3-dma-2.dtsi to support the third DMA controller.
> This is used on T2080, T4240, etc.
>
> MPIC registers for internal interrupts is non-continous in address, any
> internal interrupt number greater than 159 should be added (16+208) to work,
> adding 16 is due to external interrupts as usual, adding 208 is due to
> non-continous MPIC register space.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi | 82 +++++++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
>
> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
> new file mode 100644
> index 0000000..d3cc8d0
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
> @@ -0,0 +1,82 @@
> +/*
> + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x102300 ]
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote products
> + * derived from this software without specific prior written permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +dma2: dma@102300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,elo3-dma";
> + reg = <0x102300 0x4>,
> + <0x102600 0x4>;
> + ranges = <0x0 0x102100 0x500>;
> + dma-channel@0 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + interrupts = <464 2 0 0>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + interrupts = <465 2 0 0>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + interrupts = <466 2 0 0>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x180 0x80>;
> + interrupts = <467 2 0 0>;
> + };
> + dma-channel@300 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x300 0x80>;
> + interrupts = <468 2 0 0>;
> + };
> + dma-channel@380 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x380 0x80>;
> + interrupts = <469 2 0 0>;
> + };
> + dma-channel@400 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x400 0x80>;
> + interrupts = <470 2 0 0>;
> + };
> + dma-channel@480 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x480 0x80>;
> + interrupts = <471 2 0 0>;
> + };
> +};
^ permalink raw reply
* [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
From: Nicolin Chen @ 2013-12-12 10:44 UTC (permalink / raw)
To: broonie, timur; +Cc: tiwai, alsa-devel, linuxppc-dev, lgirdwood, perex
From: Nicolin Chen <b42378@freescale.com>
This patch adds three main functions for DAI master mode: set_dai_fmt(),
set_dai_sysclk() and set_dai_tdm_slot(), and one essential baud clock
accordingly. After appending this patch, the fsl_ssi driver on i.MX series
has the ability to derive LRCLK and BCLK from baud clock source so as to
support some audio Codecs which can only be used in slave mode.
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
---
sound/soc/fsl/fsl_ssi.c | 280 +++++++++++++++++++++++++++++++++++++++++++++++-
sound/soc/fsl/fsl_ssi.h | 2 +
2 files changed, 278 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index f9f4569..b2ebaf8 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -38,6 +38,7 @@
#include <linux/device.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/spinlock.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
@@ -139,7 +140,10 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool baudclk_locked;
u8 i2s_mode;
+ spinlock_t baudclk_lock;
+ struct clk *baudclk;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -434,13 +438,18 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct fsl_ssi_private *ssi_private =
snd_soc_dai_get_drvdata(rtd->cpu_dai);
+ unsigned long flags;
/* First, we only do fsl_ssi_setup() when SSI is going to be active.
* Second, fsl_ssi_setup was already called by ac97_init earlier if
* the driver is in ac97 mode.
*/
- if (!dai->active && !ssi_private->imx_ac97)
+ if (!dai->active && !ssi_private->imx_ac97) {
fsl_ssi_setup(ssi_private);
+ spin_lock_irqsave(&ssi_private->baudclk_lock, flags);
+ ssi_private->baudclk_locked = false;
+ spin_unlock_irqrestore(&ssi_private->baudclk_lock, flags);
+ }
return 0;
}
@@ -502,6 +511,243 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream,
}
/**
+ * fsl_ssi_set_dai_fmt - configure Digital Audio Interface Format.
+ */
+static int fsl_ssi_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
+{
+ struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
+ struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ u32 strcr = 0, stcr, srcr, scr, mask;
+
+ scr = read_ssi(&ssi->scr) & ~(CCSR_SSI_SCR_SYN | CCSR_SSI_SCR_I2S_MODE_MASK);
+ scr |= CCSR_SSI_SCR_NET;
+
+ mask = CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFDIR | CCSR_SSI_STCR_TXDIR |
+ CCSR_SSI_STCR_TSCKP | CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TFSL |
+ CCSR_SSI_STCR_TEFS;
+ stcr = read_ssi(&ssi->stcr) & ~mask;
+ srcr = read_ssi(&ssi->srcr) & ~mask;
+
+ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S:
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_MASTER;
+ break;
+ case SND_SOC_DAIFMT_CBM_CFM:
+ ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+ break;
+ default:
+ return -EINVAL;
+ }
+ scr |= ssi_private->i2s_mode;
+
+ /* Data on rising edge of bclk, frame low, 1clk before data */
+ strcr |= CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TSCKP |
+ CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TEFS;
+ break;
+ case SND_SOC_DAIFMT_LEFT_J:
+ /* Data on rising edge of bclk, frame high */
+ strcr |= CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TSCKP;
+ break;
+ case SND_SOC_DAIFMT_DSP_A:
+ /* Data on rising edge of bclk, frame high, 1clk before data */
+ strcr |= CCSR_SSI_STCR_TFSL | CCSR_SSI_STCR_TSCKP |
+ CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TEFS;
+ break;
+ case SND_SOC_DAIFMT_DSP_B:
+ /* Data on rising edge of bclk, frame high */
+ strcr |= CCSR_SSI_STCR_TFSL | CCSR_SSI_STCR_TSCKP |
+ CCSR_SSI_STCR_TXBIT0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* DAI clock inversion */
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ /* Nothing to do for both normal cases */
+ break;
+ case SND_SOC_DAIFMT_IB_NF:
+ /* Invert bit clock */
+ strcr ^= CCSR_SSI_STCR_TSCKP;
+ break;
+ case SND_SOC_DAIFMT_NB_IF:
+ /* Invert frame clock */
+ strcr ^= CCSR_SSI_STCR_TFSI;
+ break;
+ case SND_SOC_DAIFMT_IB_IF:
+ /* Invert both clocks */
+ strcr ^= CCSR_SSI_STCR_TSCKP;
+ strcr ^= CCSR_SSI_STCR_TFSI;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* DAI clock master masks */
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ strcr |= CCSR_SSI_STCR_TFDIR | CCSR_SSI_STCR_TXDIR;
+ scr |= CCSR_SSI_SCR_SYS_CLK_EN;
+ break;
+ case SND_SOC_DAIFMT_CBM_CFM:
+ scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ stcr |= strcr;
+ srcr |= strcr;
+
+ if (ssi_private->cpu_dai_drv.symmetric_rates) {
+ /* Need to clear RXDIR when using SYNC mode */
+ srcr &= ~CCSR_SSI_SRCR_RXDIR;
+ scr |= CCSR_SSI_SCR_SYN;
+ }
+
+ write_ssi(stcr, &ssi->stcr);
+ write_ssi(srcr, &ssi->srcr);
+ write_ssi(scr, &ssi->scr);
+
+ return 0;
+}
+
+/**
+ * fsl_ssi_set_dai_sysclk - configure Digital Audio Interface bit clock
+ *
+ * Note: This function can be only called when using SSI as DAI master
+ *
+ * Quick instruction for parameters:
+ * freq: Output BCLK frequency = samplerate * 32 (fixed) * channels
+ * dir: SND_SOC_CLOCK_OUT -> TxBCLK, SND_SOC_CLOCK_IN -> RxBCLK.
+ */
+static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
+ int clk_id, unsigned int freq, int dir)
+{
+ struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
+ struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ int synchronous = ssi_private->cpu_dai_drv.symmetric_rates, ret;
+ u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
+ unsigned long flags, clkrate, baudrate, tmprate;
+ u64 sub, savesub = 100000;
+
+ /* Don't apply it to any non-baudclk circumstance */
+ if (IS_ERR(ssi_private->baudclk))
+ return -EINVAL;
+
+ /* It should be already enough to divide clock by setting pm alone */
+ psr = 0;
+ div2 = 0;
+
+ factor = (div2 + 1) * (7 * psr + 1) * 2;
+
+ for (i = 0; i < 255; i++) {
+ /* The bclk rate must be smaller than 1/5 sysclk rate */
+ if (factor * (i + 1) < 5)
+ continue;
+
+ tmprate = freq * factor * (i + 2);
+ clkrate = clk_round_rate(ssi_private->baudclk, tmprate);
+
+ do_div(clkrate, factor);
+ afreq = (u32)clkrate / (i + 1);
+
+ if (freq == afreq)
+ sub = 0;
+ else if (freq / afreq == 1)
+ sub = freq - afreq;
+ else if (afreq / freq == 1)
+ sub = afreq - freq;
+ else
+ continue;
+
+ /* Calculate the fraction */
+ sub *= 100000;
+ do_div(sub, freq);
+
+ if (sub < savesub) {
+ baudrate = tmprate;
+ savesub = sub;
+ pm = i;
+ }
+
+ /* We are lucky */
+ if (savesub == 0)
+ break;
+ }
+
+ /* No proper pm found if it is still remaining the initial value */
+ if (pm == 999) {
+ dev_err(cpu_dai->dev, "failed to handle the required sysclk\n");
+ return -EINVAL;
+ }
+
+ stccr = CCSR_SSI_SxCCR_PM(pm + 1) | (div2 ? CCSR_SSI_SxCCR_DIV2 : 0) |
+ (psr ? CCSR_SSI_SxCCR_PSR : 0);
+ mask = CCSR_SSI_SxCCR_PM_MASK | CCSR_SSI_SxCCR_DIV2 | CCSR_SSI_SxCCR_PSR;
+
+ if (dir == SND_SOC_CLOCK_OUT || synchronous)
+ write_ssi_mask(&ssi->stccr, mask, stccr);
+ else
+ write_ssi_mask(&ssi->srccr, mask, stccr);
+
+ spin_lock_irqsave(&ssi_private->baudclk_lock, flags);
+ if (!ssi_private->baudclk_locked) {
+ ret = clk_set_rate(ssi_private->baudclk, baudrate);
+ if (ret) {
+ spin_unlock_irqrestore(&ssi_private->baudclk_lock, flags);
+ dev_err(cpu_dai->dev, "failed to set baudclk rate\n");
+ return -EINVAL;
+ }
+ ssi_private->baudclk_locked = true;
+ }
+ spin_unlock_irqrestore(&ssi_private->baudclk_lock, flags);
+
+ return 0;
+}
+
+/**
+ * fsl_ssi_set_dai_tdm_slot - set TDM slot number
+ *
+ * Note: This function can be only called when using SSI as DAI master
+ */
+static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, u32 tx_mask,
+ u32 rx_mask, int slots, int slot_width)
+{
+ struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
+ struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ u32 val;
+
+ /* The slot number should be >= 2 if using Network mode or I2S mode */
+ val = read_ssi(&ssi->scr) & (CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_NET);
+ if (val && slots < 2) {
+ dev_err(cpu_dai->dev, "slot number should be >= 2 in I2S or NET\n");
+ return -EINVAL;
+ }
+
+ write_ssi_mask(&ssi->stccr, CCSR_SSI_SxCCR_DC_MASK,
+ CCSR_SSI_SxCCR_DC(slots));
+ write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_DC_MASK,
+ CCSR_SSI_SxCCR_DC(slots));
+
+ /* The register SxMSKs needs SSI to provide essential clock due to
+ * hardware design. So we here temporarily enable SSI to set them.
+ */
+ val = read_ssi(&ssi->scr) & CCSR_SSI_SCR_SSIEN;
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_SSIEN);
+
+ write_ssi(tx_mask, &ssi->stmsk);
+ write_ssi(rx_mask, &ssi->srmsk);
+
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, val);
+
+ return 0;
+}
+
+/**
* fsl_ssi_trigger: start and stop the DMA transfer.
*
* This function is called by ALSA to start, stop, pause, and resume the DMA
@@ -517,6 +763,7 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(rtd->cpu_dai);
struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
unsigned int sier_bits;
+ unsigned long flags;
/*
* Enable only the interrupts and DMA requests
@@ -557,8 +804,12 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
if (!ssi_private->imx_ac97 && (read_ssi(&ssi->scr) &
- (CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE)) == 0)
+ (CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE)) == 0) {
write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+ spin_lock_irqsave(&ssi_private->baudclk_lock, flags);
+ ssi_private->baudclk_locked = false;
+ spin_unlock_irqrestore(&ssi_private->baudclk_lock, flags);
+ }
break;
default:
@@ -585,6 +836,9 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
.startup = fsl_ssi_startup,
.hw_params = fsl_ssi_hw_params,
+ .set_fmt = fsl_ssi_set_dai_fmt,
+ .set_sysclk = fsl_ssi_set_dai_sysclk,
+ .set_tdm_slot = fsl_ssi_set_dai_tdm_slot,
.trigger = fsl_ssi_trigger,
};
@@ -897,6 +1151,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Older 8610 DTs didn't have the fifo-depth property */
ssi_private->fifo_depth = 8;
+ ssi_private->baudclk_locked = false;
+ spin_lock_init(&ssi_private->baudclk_lock);
+
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
u32 dma_events[2];
ssi_private->ssi_on_imx = true;
@@ -914,6 +1171,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
goto error_irqmap;
}
+ /* For those SLAVE implementations, we ingore non-baudclk cases
+ * and, instead, abandon MASTER mode that needs baud clock.
+ */
+ ssi_private->baudclk = devm_clk_get(&pdev->dev, "baud");
+ if (IS_ERR(ssi_private->baudclk))
+ dev_warn(&pdev->dev, "could not get baud clock: %d\n", ret);
+ else
+ clk_prepare_enable(ssi_private->baudclk);
+
/*
* We have burstsize be "fifo_depth - 2" to match the SSI
* watermark setting in fsl_ssi_startup().
@@ -1059,8 +1325,11 @@ error_dev:
device_remove_file(&pdev->dev, dev_attr);
error_clk:
- if (ssi_private->ssi_on_imx)
+ if (ssi_private->ssi_on_imx) {
+ if (!IS_ERR(ssi_private->baudclk))
+ clk_disable_unprepare(ssi_private->baudclk);
clk_disable_unprepare(ssi_private->clk);
+ }
error_irqmap:
irq_dispose_mapping(ssi_private->irq);
@@ -1076,8 +1345,11 @@ static int fsl_ssi_remove(struct platform_device *pdev)
platform_device_unregister(ssi_private->pdev);
snd_soc_unregister_component(&pdev->dev);
device_remove_file(&pdev->dev, &ssi_private->dev_attr);
- if (ssi_private->ssi_on_imx)
+ if (ssi_private->ssi_on_imx) {
+ if (!IS_ERR(ssi_private->baudclk))
+ clk_disable_unprepare(ssi_private->baudclk);
clk_disable_unprepare(ssi_private->clk);
+ }
irq_dispose_mapping(ssi_private->irq);
return 0;
diff --git a/sound/soc/fsl/fsl_ssi.h b/sound/soc/fsl/fsl_ssi.h
index e6b9a69..e6b6324 100644
--- a/sound/soc/fsl/fsl_ssi.h
+++ b/sound/soc/fsl/fsl_ssi.h
@@ -125,7 +125,9 @@ struct ccsr_ssi {
#define CCSR_SSI_SRCR_REFS 0x00000001
/* STCCR and SRCCR */
+#define CCSR_SSI_SxCCR_DIV2_SHIFT 18
#define CCSR_SSI_SxCCR_DIV2 0x00040000
+#define CCSR_SSI_SxCCR_PSR_SHIFT 17
#define CCSR_SSI_SxCCR_PSR 0x00020000
#define CCSR_SSI_SxCCR_WL_SHIFT 13
#define CCSR_SSI_SxCCR_WL_MASK 0x0001E000
--
1.8.4
^ permalink raw reply related
* powerpc/powernv: Framework to log critical errors on powernv.
From: Deepthi Dharwar @ 2013-12-12 11:25 UTC (permalink / raw)
To: PowerPC email list, Benjamin Herrenschmidt
powerpc/powernv: Framework to log critical errors on powernv.
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
This patch provides error logging interfaces to report critical
powernv error logs to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 125 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 59 +++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 184 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index be404ea..b8d1dd4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -134,6 +134,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_ELOG_ACK 73
#define OPAL_ELOG_RESEND 74
#define OPAL_ELOG_SIZE 75
+#define OPAL_ELOG_SEND 87
#ifndef __ASSEMBLY__
@@ -216,6 +217,122 @@ enum OpalPendingState {
OPAL_EVENT_PCI_ERROR = 0x200
};
+/* Classification of Error/Events reporting type classification
+ * Platform Events/Errors: Report Machine Check Interrupt
+ * INPUT_OUTPUT: Report all I/O related events/errors
+ * RESOURCE_DEALLOC: Hotplug events and errors
+ * MISC: Miscellanous error
+ * Field: error_events_type
+ */
+enum Error_Events {
+ OPAL_PLATFORM,
+ OPAL_INPUT_OUTPUT,
+ OPAL_RESOURCE_DEALLOC,
+ OPAL_MISC,
+};
+
+/* OPAL Subsystem IDs listed for reporting events/errors
+ * Field: subsystem_id
+ */
+
+#define OPAL_PROCESSOR_SUBSYSTEM 0x10
+#define OPAL_MEMORY_SUBSYSTEM 0x20
+#define OPAL_IO_SUBSYSTEM 0x30
+#define OPAL_IO_DEVICES 0x40
+#define OPAL_CEC_HARDWARE 0x50
+#define OPAL_POWER_COOLING 0x60
+#define OPAL_MISC_SUBSYSTEM 0x70
+#define OPAL_SURVEILLANCE_ERR 0x7A
+#define OPAL_PLATFORM_FIRMWARE 0x80
+#define OPAL_SOFTWARE 0x90
+#define OPAL_EXTERNAL_ENV 0xA0
+
+/* During reporting an event/error the following represents
+ * how serious the logged event/error is. (Severity)
+ * Field: event_sev
+ */
+#define OPAL_INFO 0x00
+#define OPAL_RECOVERED_ERR_GENERAL 0x10
+
+/* 0x2X series is to denote set of Predictive Error
+ * 0x20 Generic predictive error
+ * 0x21 Predictive error, degraded performance
+ * 0x22 Predictive error, fault may be corrected after reboot
+ * 0x23 Predictive error, fault may be corrected after reboot,
+ * degraded performance
+ * 0x24 Predictive error, loss of redundancy
+ */
+#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
+#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
+#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
+
+/* 0x4X series for Unrecoverable Error
+ * 0x40 Generic Unrecoverable error
+ * 0x41 Unrecoverable error bypassed with degraded performance
+ * 0x44 Unrecoverable error bypassed with loss of redundancy
+ * 0x45 Unrecoverable error bypassed with loss of redundancy and performance
+ * 0x48 Unrecoverable error bypassed with loss of function
+ */
+#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
+#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
+#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
+
+/* Event Sub-type
+ * This field provides additional information on the non-error
+ * event type
+ * Field: event_subtype
+ */
+#define OPAL_NA 0x00
+#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
+#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
+#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
+#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
+#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
+#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
+#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
+#define OPAL_RESOURCE_SPARING_EVENT 0x70
+#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
+#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
+#define OPAL_ABNORMAL_POWER_OFF 0xE0
+
+/* Max user dump size is 14K */
+#define OPAL_LOG_MAX_DUMP 14336
+
+/* Multiple user data sections */
+struct opal_usr_data_scn {
+ uint32_t tag;
+ uint16_t size;
+ uint16_t component_id;
+ char data_dump[4];
+};
+
+
+/* All the information regarding an error/event to be reported
+ * needs to populate this structure using pre-defined interfaces
+ * only
+ */
+struct opal_errorlog {
+
+ uint16_t component_id;
+ uint8_t error_events_type:3;
+ uint8_t subsystem_id;
+
+ uint8_t event_sev;
+ uint8_t event_subtype;
+ uint8_t usr_scn_count; /* User section count */
+ uint8_t elog_origin;
+
+ uint32_t usr_scn_size; /* User section size */
+ uint32_t reason_code;
+ uint32_t additional_info[4];
+
+ char usr_data_dump[OPAL_LOG_MAX_DUMP];
+};
+
/* Machine check related definitions */
enum OpalMCE_Version {
OpalMCE_V1 = 1,
@@ -667,6 +784,14 @@ int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
+struct opal_errorlog *elog_create(uint8_t err_evt_type, uint16_t component_id,
+ uint8_t subsystem_id, uint8_t event_sev, uint8_t event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3);
+int update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size);
+void commit_errorlog_to_fsp(struct opal_errorlog *buf);
+int opal_commit_log_to_fsp(void *buf);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int depth, void *data);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 58849d0..af8d385 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -16,13 +16,15 @@
#include <linux/fs.h>
#include <linux/vmalloc.h>
#include <linux/fcntl.h>
+#include <linux/mm.h>
#include <asm/uaccess.h>
#include <asm/opal.h>
/* Maximum size of a single log on FSP is 16KB */
#define OPAL_MAX_ERRLOG_SIZE 16384
+#define USR_CHAR_ARRAY_FIXED_SIZE 4
-/* maximu number of records powernv can hold */
+/* maximum number of records powernv can hold */
#define MAX_NUM_RECORD 128
struct opal_err_log {
@@ -272,6 +274,61 @@ static int init_err_log_buffer(void)
return 0;
}
+/* Interface to be used by POWERNV to push the logs to FSP via Sapphire */
+struct opal_errorlog *elog_create(uint8_t err_evt_type, uint16_t component_id,
+ uint8_t subsystem_id, uint8_t event_sev, uint8_t event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3)
+{
+ struct opal_errorlog *buf;
+
+ buf = kzalloc(sizeof(struct opal_errorlog), GFP_KERNEL);
+ if (!buf) {
+ printk(KERN_ERR "ELOG: failed to allocate memory.\n");
+ return -ENOMEM;
+ }
+
+ buf->error_events_type = err_evt_type;
+ buf->component_id = component_id;
+ buf->subsystem_id = subsystem_id;
+ buf->event_sev = event_sev;
+ buf->event_subtype = event_subtype;
+ buf->reason_code = reason_code;
+ buf->additional_info[0] = info0;
+ buf->additional_info[1] = info1;
+ buf->additional_info[2] = info2;
+ buf->additional_info[3] = info3;
+ return buf;
+}
+
+int update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size)
+{
+ char *buffer = (char *)buf->usr_data_dump + buf->usr_scn_size;
+ struct opal_usr_data_scn *tmp;
+
+ if ((buf->usr_scn_size + size) > OPAL_LOG_MAX_DUMP) {
+ printk(KERN_ERR "ELOG: Size of dump data overruns buffer");
+ return -1;
+ }
+
+ tmp = (struct opal_usr_data_scn *)buffer;
+ tmp->tag = tag;
+ tmp->size = size + sizeof(struct opal_usr_data_scn)
+ - USR_CHAR_ARRAY_FIXED_SIZE;
+ memcpy(tmp->data_dump, data, size);
+
+ buf->usr_scn_size += tmp->size;
+ buf->usr_scn_count++;
+ return 0;
+}
+
+void commit_errorlog_to_fsp(struct opal_errorlog *buf)
+{
+ opal_commit_log_to_fsp((void *)(vmalloc_to_pfn(buf) << PAGE_SHIFT));
+ kfree(buf);
+}
+
/* Initialize error logging */
static int __init opal_elog_init(void)
{
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 66def92..f0c5178 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -121,3 +121,4 @@ OPAL_CALL(opal_send_ack_elog, OPAL_ELOG_ACK);
OPAL_CALL(opal_get_elog_size, OPAL_ELOG_SIZE);
OPAL_CALL(opal_resend_pending_logs, OPAL_ELOG_RESEND);
OPAL_CALL(opal_write_elog, OPAL_ELOG_WRITE);
+OPAL_CALL(opal_commit_log_to_fsp, OPAL_ELOG_SEND);
^ permalink raw reply related
* Re: [PATCH v2] spi/fsl-espi: Add Power Management support for eSPI controller
From: Mark Brown @ 2013-12-12 11:56 UTC (permalink / raw)
To: Hou Zhiqiang; +Cc: linuxppc-dev, Mingkai.Hu, scottwood, linux-spi
In-Reply-To: <1386824032-19198-1-git-send-email-b48286@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
On Thu, Dec 12, 2013 at 12:53:52PM +0800, Hou Zhiqiang wrote:
> Add PM support for eSPI controller using callback function suspend
> and resume in .driver.pm of platform_driver.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta @ 2013-12-12 15:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20131211045728.GB9399@drongo>
On 12/10/2013 10:57 PM, Paul Mackerras wrote:
> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
>> This breaks 32-bit big-endian (as well as making the code longer and
>> more complex).
>
> And in fact none of this code will get executed in little-endian mode
> anyway, since we still have this in the middle of emulate_step():
>
> /*
> * Following cases are for loads and stores, so bail out
> * if we're in little-endian mode.
> */
> if (regs->msr & MSR_LE)
> return 0;
>
> Paul.
>
See patch 1/3 to explain how it becomes relevant in LE.
I will take another look at the change.
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Matteo Facchinetti @ 2013-12-12 16:12 UTC (permalink / raw)
To: Gerhard Sittig, linuxppc-dev, Anatolij Gustschin, Mike Turquette
Cc: Scott Wood, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
On 10/12/2013 14:11, Gerhard Sittig wrote:
> this series improves the previously introduced common clock support for
> MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> (MPC5125 turned out to be rather different from MPC5121 than I perceived
> before -- there is much more than "just two FECs and no MBX")
Ohhh yesss..... welcome to hell! :-)
I report also these differences:
- I/O control module:
to do integration with linux pin-muxing subsystem
- GPIO module:
controller is the same of the mpc5121 but with these differences:
- 64 gpios divided in 2 banks
- input only gpios are numbers form 0 to 3 of the first bank
I'm finishing to write the patch... when done I'll post in ML
- NFC: one of the biggest unsolved mystery
Is this ip-core used in others microcontrollers? Seems to be
used only in mpc5125!!!
>
> Matteo, can you verify the crystal frequency in the DTS update, please?
Crystal frequency is ok: 33MHz.
> And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> MPC512x plus this series for MPC5125 operate your peripherals, both with
> an updated device tree as well as with a former device tree that lacks
> clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
> .config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
>
>
I tested all on TWR board.
In DTS, for the moment, have to comment out this block:
- usb@3000 {
- compatible = "fsl,mpc5121-usb2-dr";
- reg = <0x3000 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <43 0x8>;
- dr_mode = "host";
- phy_type = "ulpi";
- clocks = <&clks MPC512x_CLK_USB1>;
- clock-names = "ipg";
- };
Because USB controller pinout is not initialized correctly and when
system boot, causes a kernel panic.
For the rest, kernel works correctly. For MPC5125 the patches are OK.
I also check clk_summary and all clocks values are OK (except for NFC
clock value).
I notice that there are missing clock like: gpio1, gpio2, fuse, dma,
wdt, pmc, rtc.
Is this OK or should be added?
Regards,
Matteo Facchinetti
Sirius Electronic Systems
^ permalink raw reply
* [PATCH] powerpc: Make unaligned accesses endian-safe for powerpc
From: Rajesh B Prathipati @ 2013-12-12 15:45 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, anton
From: Rajesh B Prathipati <rprathip@linux.vnet.ibm.com>
The generic put_unaligned/get_unaligned macros were made endian-safe by
calling the appropriate endian dependent macros based on the endian type
of the powerpc processor.
Signed-off-by: Rajesh B Prathipati <rprathip@linux.vnet.ibm.com>
---
This patch applies to linux kernel version 3.12. This patch has been
tested and it fixes the problem with linux 3.12 USB stack.
--- linux/arch/powerpc/include/asm/unaligned.h.orig 2013-12-12
00:07:05.329073544 -0200
+++ linux/arch/powerpc/include/asm/unaligned.h 2013-12-11
23:56:52.918630238 -0200
@@ -4,13 +4,18 @@
#ifdef __KERNEL__
/*
- * The PowerPC can do unaligned accesses itself in big endian mode.
+ * The PowerPC can do unaligned accesses itself based on its endian mode.
*/
#include <linux/unaligned/access_ok.h>
#include <linux/unaligned/generic.h>
+#ifdef __LITTLE_ENDIAN__
+#define get_unaligned __get_unaligned_le
+#define put_unaligned __put_unaligned_le
+#else
#define get_unaligned __get_unaligned_be
#define put_unaligned __put_unaligned_be
+#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UNALIGNED_H */
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Sinan Akman @ 2013-12-12 17:46 UTC (permalink / raw)
To: Matteo Facchinetti
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Scott Wood,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52A9E074.5080607@sirius-es.it>
Matteo Facchinetti wrote:
> [...]
> - NFC: one of the biggest unsolved mystery
> Is this ip-core used in others microcontrollers? Seems to be used only
> in mpc5125!!!
I don't think that IP is used in any other FSL SoC. Scott can probably
confirm this for us.
I did some digging on this NFC just to put enough things together
that I can erase and flash firmware using BDI3000 that is read and
executed properly when the boot flag is set.
Do you see any other anomalies with MPC5125 NFC ?
Thanks
Sinan Akman
^ permalink raw reply
* Re: [PATCH 2/4] kexec: Add IND_FLAGS macro
From: Geoff Levand @ 2013-12-12 19:33 UTC (permalink / raw)
To: Zhang Yanfei; +Cc: linuxppc-dev, kexec, Eric Biederman, Paul Mackerras
In-Reply-To: <52A912E3.1060802@cn.fujitsu.com>
Hi Zhang,
On Thu, 2013-12-12 at 09:35 +0800, Zhang Yanfei wrote:
> On 12/12/2013 08:18 AM, Geoff Levand wrote:
> > Add a new kexec preprocessor macro IND_FLAGS, which is the bitwise OR of
> > all the possible kexec IND_ kimage_entry indirection flags.
> >
> > Having this macro allows for simplified code in the prosessing of the
> > kexec kimage_entry items.
>
> Where? I didn't see any place you use this macro to help simplification.
As in powerpc, it allows constructions like this:
switch (entry & IND_FLAGS) {
case IND_DESTINATION:
...
case IND_INDIRECTION:
...
}
-Geoff
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Scott Wood @ 2013-12-12 19:32 UTC (permalink / raw)
To: Sinan Akman
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Matteo Facchinetti,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52A9F685.3040204@writeme.com>
On Thu, 2013-12-12 at 18:46 +0100, Sinan Akman wrote:
> Matteo Facchinetti wrote:
> > [...]
> > - NFC: one of the biggest unsolved mystery
> > Is this ip-core used in others microcontrollers? Seems to be used only
> > in mpc5125!!!
> I don't think that IP is used in any other FSL SoC. Scott can probably
> confirm this for us.
That's a different part of Freescale, so I don't know much about it, but
it looks pretty similar to MXC NAND. Back when those drivers were
submitted I tried to get the authors of each to work together to see if
a common driver made sense, but I got little response.
-Scott
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta @ 2013-12-12 20:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <52A9D17E.3000809@gmail.com>
On 12/12/2013 9:08 AM, Tom Musta wrote:
> On 12/10/2013 10:57 PM, Paul Mackerras wrote:
>> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
>
>>> This breaks 32-bit big-endian (as well as making the code longer and
>>> more complex).
>>
>> And in fact none of this code will get executed in little-endian mode
>> anyway, since we still have this in the middle of emulate_step():
>>
>> /*
>> * Following cases are for loads and stores, so bail out
>> * if we're in little-endian mode.
>> */
>> if (regs->msr & MSR_LE)
>> return 0;
>>
>> Paul.
>>
>
> See patch 1/3 to explain how it becomes relevant in LE.
>
> I will take another look at the change.
>
It appears that patch 1/3 never got picked up, even though I thought Ben & I
had worked through that.
And I agree that the code could be simpler. I will work up a patch to address
these two issues.
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Paul Mackerras @ 2013-12-12 21:19 UTC (permalink / raw)
To: Tom Musta; +Cc: linuxppc-dev
In-Reply-To: <52AA1DA0.80003@gmail.com>
On Thu, Dec 12, 2013 at 02:33:36PM -0600, Tom Musta wrote:
> On 12/12/2013 9:08 AM, Tom Musta wrote:
> > On 12/10/2013 10:57 PM, Paul Mackerras wrote:
> >> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
> >
> >>> This breaks 32-bit big-endian (as well as making the code longer and
> >>> more complex).
> >>
> >> And in fact none of this code will get executed in little-endian mode
> >> anyway, since we still have this in the middle of emulate_step():
> >>
> >> /*
> >> * Following cases are for loads and stores, so bail out
> >> * if we're in little-endian mode.
> >> */
> >> if (regs->msr & MSR_LE)
> >> return 0;
> >>
> >> Paul.
> >>
> >
> > See patch 1/3 to explain how it becomes relevant in LE.
> >
> > I will take another look at the change.
> >
>
> It appears that patch 1/3 never got picked up, even though I thought Ben & I
> had worked through that.
>
> And I agree that the code could be simpler. I will work up a patch to address
> these two issues.
The other thing that's important for us to know is how you are testing
these changes. For something like this I'd like to see a description
of the tests you have done in the commit message.
I have been hacking on sstep.c pretty heavily myself recently, so we
will need to coordinate on the changes.
Paul.
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Gerhard Sittig @ 2013-12-12 22:25 UTC (permalink / raw)
To: Matteo Facchinetti
Cc: Scott Wood, Mike Turquette, Anatolij Gustschin, linuxppc-dev,
Detlev Zundel
In-Reply-To: <52A9E074.5080607@sirius-es.it>
On Thu, Dec 12, 2013 at 17:12 +0100, Matteo Facchinetti wrote:
>
> On 10/12/2013 14:11, Gerhard Sittig wrote:
> >this series improves the previously introduced common clock support for
> >MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> >(MPC5125 turned out to be rather different from MPC5121 than I perceived
> >before -- there is much more than "just two FECs and no MBX")
> Ohhh yesss..... welcome to hell! :-)
>
> I report also these differences:
>
> - I/O control module:
> to do integration with linux pin-muxing subsystem
>
> - GPIO module:
> controller is the same of the mpc5121 but with these differences:
> - 64 gpios divided in 2 banks
> - input only gpios are numbers form 0 to 3 of the first bank
> I'm finishing to write the patch... when done I'll post in ML
Yes, I've seen the 2x 32bits thing on MPC5125. Can't tell
whether one can just use two mpc8xxx-gpio nodes in the device
tree and be done.
MPC5121 has just one 32bits GPIO bank. And four of those pins
are "GPI only" as well. This may be identical to one of the two
MPC5125 banks.
> - NFC: one of the biggest unsolved mystery
> Is this ip-core used in others microcontrollers? Seems to be
> used only in mpc5125!!!
>
> >
> >Matteo, can you verify the crystal frequency in the DTS update, please?
> Crystal frequency is ok: 33MHz.
great
> >And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> >MPC512x plus this series for MPC5125 operate your peripherals, both with
> >an updated device tree as well as with a former device tree that lacks
> >clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
> >.config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
> >
> >
> I tested all on TWR board.
Thank you! I think this qualifies as Tested-by: then. :)
> In DTS, for the moment, have to comment out this block:
> - usb@3000 {
> - compatible = "fsl,mpc5121-usb2-dr";
> - reg = <0x3000 0x400>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - interrupts = <43 0x8>;
> - dr_mode = "host";
> - phy_type = "ulpi";
> - clocks = <&clks MPC512x_CLK_USB1>;
> - clock-names = "ipg";
> - };
> Because USB controller pinout is not initialized correctly and when
> system boot, causes a kernel panic.
>
> For the rest, kernel works correctly. For MPC5125 the patches are OK.
>
> I also check clk_summary and all clocks values are OK (except for
> NFC clock value).
Since there is no user of the NFC block yet, I did not implement
the driver for the clock item. The list of clocks in debugfs
should completely lack an NFC entry since nothing was registered
with the CCF subsystem.
> I notice that there are missing clock like: gpio1, gpio2, fuse, dma,
> wdt, pmc, rtc.
> Is this OK or should be added?
Are there registers for those clock items? Haven't seen any when
flipping through the RM's clocks chapter. If there's no
(software controllable) gate or divider, then there's no clock
item in need of software support.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [1/3] powerpc/vfio: Enable on POWERNV platform
From: Scott Wood @ 2013-12-12 23:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, linux-kernel, Alex Williamson, Paul Mackerras, Varun Sethi,
linuxppc-dev, David Gibson
In-Reply-To: <1369107191-28547-2-git-send-email-aik@ozlabs.ru>
On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
> +static int iommu_add_device(struct device *dev)
> +{
> + struct iommu_table *tbl;
> + int ret = 0;
> +
> + if (WARN_ON(dev->iommu_group)) {
> + pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
> + dev_name(dev),
> + iommu_group_id(dev->iommu_group));
> + return -EBUSY;
> + }
[snip]
> +static int __init tce_iommu_init(void)
> +{
> + struct pci_dev *pdev = NULL;
> +
> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> +
> + for_each_pci_dev(pdev)
> + iommu_add_device(&pdev->dev);
> +
> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> + return 0;
> +}
> +
> +subsys_initcall_sync(tce_iommu_init);
This is missing a check to see whether the appropriate hardware is
present. This file should also be renamed to something less generic, and
depend on a kconfig symbol more specific than CONFIG_PPC64.
When this is combined with CONFIG_FSL_PAMU on hardware with a PAMU, I get
a bunch of those "WARN_ON(dev->iommu_group)" dumps because PAMU already
got to them. Presumably without PAMU it silently (or with just pr_debug)
bails out at some other point.
-Scott
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 17/12/2013)
From: Michael Barry @ 2013-12-12 23:58 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 17/12/2013.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 112, Issue 55" sent on 12/12/2013 23:35:43.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Sinan Akman @ 2013-12-13 0:29 UTC (permalink / raw)
To: Scott Wood
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Matteo Facchinetti,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1386876720.10013.260.camel@snotra.buserror.net>
Scott Wood wrote:
> On Thu, 2013-12-12 at 18:46 +0100, Sinan Akman wrote:
>> Matteo Facchinetti wrote:
>>> [...]
>>> - NFC: one of the biggest unsolved mystery
>>> Is this ip-core used in others microcontrollers? Seems to be used only
>>> in mpc5125!!!
>> I don't think that IP is used in any other FSL SoC. Scott can probably
>> confirm this for us.
>
> That's a different part of Freescale, so I don't know much about it, but
> it looks pretty similar to MXC NAND. Back when those drivers were
> submitted I tried to get the authors of each to work together to see if
> a common driver made sense, but I got little response.
OK Scott thanks for your comments. I am somewhat deep in 5125 NFC. I will
take a look at mxc nand and see how similar they are. Who is maintaining
mxc nand ? I might spend some time and create some common components.
But right now I am not familiar with mxc nand.
Thanks
Sinan Akman
^ permalink raw reply
* Re: powerpc/powernv: Framework to log critical errors on powernv.
From: Michael Ellerman @ 2013-12-13 2:00 UTC (permalink / raw)
To: Deepthi Dharwar; +Cc: PowerPC email list
In-Reply-To: <52A99D47.4090503@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 16:55 +0530, Deepthi Dharwar wrote:
> powerpc/powernv: Framework to log critical errors on powernv.
>
> From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
>
> This patch provides error logging interfaces to report critical
> powernv error logs to FSP.
> All the required information to dump the error is collected
> at POWERNV level through error log interfaces
> and then pushed on to FSP.
>
> Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/opal.h | 125 ++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/opal-elog.c | 59 +++++++++++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1
> 3 files changed, 184 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index be404ea..b8d1dd4 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -134,6 +134,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
> #define OPAL_ELOG_ACK 73
> #define OPAL_ELOG_RESEND 74
> #define OPAL_ELOG_SIZE 75
> +#define OPAL_ELOG_SEND 87
>
> #ifndef __ASSEMBLY__
>
> @@ -216,6 +217,122 @@ enum OpalPendingState {
> OPAL_EVENT_PCI_ERROR = 0x200
> };
>
> +/* Classification of Error/Events reporting type classification
> + * Platform Events/Errors: Report Machine Check Interrupt
> + * INPUT_OUTPUT: Report all I/O related events/errors
> + * RESOURCE_DEALLOC: Hotplug events and errors
> + * MISC: Miscellanous error
> + * Field: error_events_type
> + */
> +enum Error_Events {
> + OPAL_PLATFORM,
> + OPAL_INPUT_OUTPUT,
> + OPAL_RESOURCE_DEALLOC,
> + OPAL_MISC,
> +};
> +
> +/* OPAL Subsystem IDs listed for reporting events/errors
> + * Field: subsystem_id
> + */
> +
> +#define OPAL_PROCESSOR_SUBSYSTEM 0x10
> +#define OPAL_MEMORY_SUBSYSTEM 0x20
> +#define OPAL_IO_SUBSYSTEM 0x30
> +#define OPAL_IO_DEVICES 0x40
> +#define OPAL_CEC_HARDWARE 0x50
> +#define OPAL_POWER_COOLING 0x60
> +#define OPAL_MISC_SUBSYSTEM 0x70
> +#define OPAL_SURVEILLANCE_ERR 0x7A
> +#define OPAL_PLATFORM_FIRMWARE 0x80
> +#define OPAL_SOFTWARE 0x90
> +#define OPAL_EXTERNAL_ENV 0xA0
> +
> +/* During reporting an event/error the following represents
> + * how serious the logged event/error is. (Severity)
> + * Field: event_sev
> + */
> +#define OPAL_INFO 0x00
> +#define OPAL_RECOVERED_ERR_GENERAL 0x10
> +
> +/* 0x2X series is to denote set of Predictive Error
> + * 0x20 Generic predictive error
> + * 0x21 Predictive error, degraded performance
> + * 0x22 Predictive error, fault may be corrected after reboot
> + * 0x23 Predictive error, fault may be corrected after reboot,
> + * degraded performance
> + * 0x24 Predictive error, loss of redundancy
> + */
> +#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
> +#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
> +#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
> +#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
> +#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
> +
> +/* 0x4X series for Unrecoverable Error
> + * 0x40 Generic Unrecoverable error
> + * 0x41 Unrecoverable error bypassed with degraded performance
> + * 0x44 Unrecoverable error bypassed with loss of redundancy
> + * 0x45 Unrecoverable error bypassed with loss of redundancy and performance
> + * 0x48 Unrecoverable error bypassed with loss of function
> + */
> +#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
> +#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
> +
> +/* Event Sub-type
> + * This field provides additional information on the non-error
> + * event type
> + * Field: event_subtype
> + */
> +#define OPAL_NA 0x00
> +#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
> +#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
> +#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
> +#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
> +#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
> +#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
> +#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
> +#define OPAL_RESOURCE_SPARING_EVENT 0x70
> +#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
> +#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
> +#define OPAL_ABNORMAL_POWER_OFF 0xE0
None of the above seem to be used anywhere.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: set default kernel thread priority to medium-low
From: Michael Ellerman @ 2013-12-13 2:03 UTC (permalink / raw)
To: Philippe Bergheaud; +Cc: Linuxppc-dev
In-Reply-To: <52A961A0.5010307@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 08:11 +0100, Philippe Bergheaud wrote:
> Michael Ellerman wrote:
> > On Wed, 2013-12-11 at 11:30 +0100, Philippe Bergheaud wrote:
> >
> >>Shouldn't we define a new macro HMT_DEFAULT, to identify explicitely where
> >>the default priority is required?
> >
> >
> > That might help clarify things yes.
>
> Thank you for the help. I will rework this.
Thanks.
^ permalink raw reply
* Re: [PATCH V4 08/10] powerpc, perf: Enable SW filtering in branch stack sampling framework
From: Michael Ellerman @ 2013-12-13 2:47 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mikey, ak, linux-kernel, eranian, linuxppc-dev, acme, sukadev,
mingo
In-Reply-To: <52A9779B.1030003@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 14:15 +0530, Anshuman Khandual wrote:
> On 12/10/2013 11:27 AM, Anshuman Khandual wrote:
> > On 12/09/2013 11:51 AM, Michael Ellerman wrote:
> >> This code was already in need of some unindentation, and now it's just
> >> ridiculous.
> >>
> >> To start with at the beginning of this routine we have:
> >>
> >> while (..) {
> >> if (!val)
> >> break;
> >> else {
> >> // Bulk of the logic
> >> ...
> >> }
> >> }
> >>
> >> That should almost always become:
> >>
> >> while (..) {
> >> if (!val)
> >> break;
> >>
> >> // Bulk of the logic
> >> ...
> >> }
> >>
> >>
> >> But in this case that's not enough. Please send a precursor patch which moves
> >> this logic out into a helper function.
> >
> > Hey Michael,
> >
> > I believe this patch should be able to take care of this.
...
> Does the patch looks okay ? In which case will send it out separately. Do let
> me know. Thank you.
It's OK.
Don't send it out separately, make it the first patch in your series.
cheers
^ permalink raw reply
* Re: [PATCH 1/2] power7, perf: Make some new raw event codes available in sysfs
From: Michael Ellerman @ 2013-12-13 2:50 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, mikey, sukadev
In-Reply-To: <1381902780-2719-2-git-send-email-khandual@linux.vnet.ibm.com>
On Wed, 2013-10-16 at 11:22 +0530, Anshuman Khandual wrote:
> This patch adds some more raw event codes into the existing list
> of event codes present in power7-events-list.h file. This tries
> to complete the list of events supported in Power7 and matches
> the raw event list with libpfm4 library.
It's a bit annoying, but you also need to update the "ABI" document:
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
Please do so and resend.
cheers
^ permalink raw reply
* Re: powerpc/powernv: Framework to log critical errors on powernv.
From: Benjamin Herrenschmidt @ 2013-12-13 2:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Deepthi Dharwar, PowerPC email list
In-Reply-To: <1386900030.21216.7.camel@concordia>
On Fri, 2013-12-13 at 13:00 +1100, Michael Ellerman wrote:
> None of the above seem to be used anywhere.
They are the arguments you pass when creating an error log, ie, they
are the values that are used by the firmware to generate the actual
error log entry.
They will be used as we add code that generate error log entries
subsequently.
Cheers,
Ben.
^ permalink raw reply
* Re: [1/3] powerpc/vfio: Enable on POWERNV platform
From: Alexey Kardashevskiy @ 2013-12-13 3:02 UTC (permalink / raw)
To: Scott Wood
Cc: kvm, linux-kernel, Bharat Bhushan, Alex Williamson,
Paul Mackerras, Varun Sethi, linuxppc-dev, David Gibson
In-Reply-To: <20131212233527.GA16929@home.buserror.net>
On 12/13/2013 10:35 AM, Scott Wood wrote:
> On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
>> +static int iommu_add_device(struct device *dev)
>> +{
>> + struct iommu_table *tbl;
>> + int ret = 0;
>> +
>> + if (WARN_ON(dev->iommu_group)) {
>> + pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>> + dev_name(dev),
>> + iommu_group_id(dev->iommu_group));
>> + return -EBUSY;
>> + }
> [snip]
>> +static int __init tce_iommu_init(void)
>> +{
>> + struct pci_dev *pdev = NULL;
>> +
>> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
>> +
>> + for_each_pci_dev(pdev)
>> + iommu_add_device(&pdev->dev);
>> +
>> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
>> + return 0;
>> +}
>> +
>> +subsys_initcall_sync(tce_iommu_init);
>
> This is missing a check to see whether the appropriate hardware is
> present. This file should also be renamed to something less generic, and
> depend on a kconfig symbol more specific than CONFIG_PPC64.
>
> When this is combined with CONFIG_FSL_PAMU on hardware with a PAMU, I get
> a bunch of those "WARN_ON(dev->iommu_group)" dumps because PAMU already
> got to them. Presumably without PAMU it silently (or with just pr_debug)
> bails out at some other point.
I posted (yet again) yesterday "[PATCH v11] PPC: POWERNV: move
iommu_add_device earlier" which should fix this. And Bharat asked many
times for this to get accepted :)
--
Alexey
^ permalink raw reply
* RE: [PATCH v7] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2013-12-13 3:39 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384938289-24713-1-git-send-email-Yuantian.Tang@freescale.com>
UElORy4NCg0KVGhhbmtzLA0KWXVhbnRpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBUYW5nIFl1YW50aWFuLUIyOTk4Mw0KPiBTZW50OiAyMDEzxOoxMdTCMjDI1SDQ
x8bayP0gMTc6MDUNCj4gVG86IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmcNCj4gQ2M6IGRldmlj
ZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4g
bWFyay5ydXRsYW5kQGFybS5jb207IFdvb2QgU2NvdHQtQjA3NDIxOyBncmFudC5saWtlbHlAc2Vj
cmV0bGFiLmNhOyBUYW5nDQo+IFl1YW50aWFuLUIyOTk4MzsgVGFuZyBZdWFudGlhbi1CMjk5ODM7
IExpIFlhbmctTGVvLVI1ODQ3Mg0KPiBTdWJqZWN0OiBbUEFUQ0ggdjddIGNsazogY29yZW5ldDog
QWRkcyB0aGUgY2xvY2sgYmluZGluZw0KPiANCj4gRnJvbTogVGFuZyBZdWFudGlhbiA8eXVhbnRp
YW4udGFuZ0BmcmVlc2NhbGUuY29tPg0KPiANCj4gQWRkcyB0aGUgY2xvY2sgYmluZGluZ3MgZm9y
IEZyZWVzY2FsZSBQb3dlclBDIENvcmVOZXQgcGxhdGZvcm1zDQo+IA0KPiBTaWduZWQtb2ZmLWJ5
OiBUYW5nIFl1YW50aWFuIDxZdWFudGlhbi5UYW5nQGZyZWVzY2FsZS5jb20+DQo+IFNpZ25lZC1v
ZmYtYnk6IExpIFlhbmcgPGxlb2xpQGZyZWVzY2FsZS5jb20+DQo+IC0tLQ0KPiB2NzoNCj4gCS0g
cmVmaW5lZCBzb21lIHByb3BlcnRpZXMnIGRlZmluaXRpb25zDQo+IHY2Og0KPiAJLSBzcGxpdGVk
IHRoZSBwcmV2aW91cyBwYXRjaCBpbnRvIDIgcGFydHMsIG9uZSBpcyBmb3IgYmluZGluZyh0aGlz
DQo+IG9uZSksDQo+IAkgIHRoZSBvdGhlciBpcyBmb3IgRFRTIG1vZGlmaWNhdGlvbih3aWxsIHN1
Ym1pdCBvbmNlIHRoaXMgZ2V0cw0KPiBhY2NlcHRlZCkNCj4gCS0gZml4ZWQgdHlwbw0KPiAJLSBy
ZWZpbmVkICNjbG9jay1jZWxscyBhbmQgY2xvY2stb3V0cHV0LW5hbWVzIHByb3BlcnRpZXMNCj4g
CS0gcmVtb3ZlZCBmaXhlZC1jbG9jayBjb21wYXRpYmxlIHN0cmluZw0KPiB2NToNCj4gCS0gcmVm
aW5lIHRoZSBiaW5kaW5nIGRvY3VtZW50DQo+IAktIHVwZGF0ZSB0aGUgY29tcGF0aWJsZSBzdHJp
bmcNCj4gdjQ6DQo+IAktIGFkZCBiaW5kaW5nIGRvY3VtZW50DQo+IAktIHVwZGF0ZSBjb21wYXRp
YmxlIHN0cmluZw0KPiAJLSB1cGRhdGUgdGhlIHJlZyBwcm9wZXJ0eQ0KPiB2MzoNCj4gCS0gZml4
IHR5cG8NCj4gdjI6DQo+IAktIGFkZCB0NDI0MCwgYjQ0MjAsIGI0ODYwIHN1cHBvcnQNCj4gCS0g
cmVtb3ZlIHBsbC80IGNsb2NrIGZyb20gcDIwNDEsIHAzMDQxIGFuZCBwNTAyMCBib2FyZA0KPiAg
Li4uL2RldmljZXRyZWUvYmluZGluZ3MvY2xvY2svY29yZW5ldC1jbG9jay50eHQgICAgfCAxMjgN
Cj4gKysrKysrKysrKysrKysrKysrKysrDQo+ICAxIGZpbGUgY2hhbmdlZCwgMTI4IGluc2VydGlv
bnMoKykNCj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu
ZGluZ3MvY2xvY2svY29yZW5ldC0NCj4gY2xvY2sudHh0DQo+IA0KPiBkaWZmIC0tZ2l0IGEvRG9j
dW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2sudHh0DQo+
IGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2su
dHh0DQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+IGluZGV4IDAwMDAwMDAuLjYwOWJhMmINCj4g
LS0tIC9kZXYvbnVsbA0KPiArKysgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3Mv
Y2xvY2svY29yZW5ldC1jbG9jay50eHQNCj4gQEAgLTAsMCArMSwxMjggQEANCj4gKyogQ2xvY2sg
QmxvY2sgb24gRnJlZXNjYWxlIENvcmVOZXQgUGxhdGZvcm1zDQo+ICsNCj4gK0ZyZWVzY2FsZSBD
b3JlTmV0IGNoaXBzIHRha2UgcHJpbWFyeSBjbG9ja2luZyBpbnB1dCBmcm9tIHRoZSBleHRlcm5h
bA0KPiArU1lTQ0xLIHNpZ25hbC4gVGhlIFNZU0NMSyBpbnB1dCAoZnJlcXVlbmN5KSBpcyBtdWx0
aXBsaWVkIHVzaW5nDQo+ICttdWx0aXBsZSBwaGFzZSBsb2NrZWQgbG9vcHMgKFBMTCkgdG8gY3Jl
YXRlIGEgdmFyaWV0eSBvZiBmcmVxdWVuY2llcw0KPiArd2hpY2ggY2FuIHRoZW4gYmUgcGFzc2Vk
IHRvIGEgdmFyaWV0eSBvZiBpbnRlcm5hbCBsb2dpYywgaW5jbHVkaW5nDQo+ICtjb3JlcyBhbmQg
cGVyaXBoZXJhbCBJUCBibG9ja3MuDQo+ICtQbGVhc2UgcmVmZXIgdG8gdGhlIFJlZmVyZW5jZSBN
YW51YWwgZm9yIGRldGFpbHMuDQo+ICsNCj4gKzEuIENsb2NrIEJsb2NrIEJpbmRpbmcNCj4gKw0K
PiArUmVxdWlyZWQgcHJvcGVydGllczoNCj4gKy0gY29tcGF0aWJsZTogU2hvdWxkIGNvbnRhaW4g
YSBzcGVjaWZpYyBjbG9jayBibG9jayBjb21wYXRpYmxlIHN0cmluZw0KPiArCWFuZCBhIHNpbmds
ZSBjaGFzc2lzIGNsb2NrIGNvbXBhdGlibGUgc3RyaW5nLg0KPiArCUNsb2NrIGJsb2NrIHN0cmlu
Z3MgaW5jbHVkZSwgYnV0IG5vdCBsaW1pdGVkIHRvLCBvbmUgb2YgdGhlOg0KPiArCSogImZzbCxw
MjA0MS1jbG9ja2dlbiINCj4gKwkqICJmc2wscDMwNDEtY2xvY2tnZW4iDQo+ICsJKiAiZnNsLHA0
MDgwLWNsb2NrZ2VuIg0KPiArCSogImZzbCxwNTAyMC1jbG9ja2dlbiINCj4gKwkqICJmc2wscDUw
NDAtY2xvY2tnZW4iDQo+ICsJKiAiZnNsLHQ0MjQwLWNsb2NrZ2VuIg0KPiArCSogImZzbCxiNDQy
MC1jbG9ja2dlbiINCj4gKwkqICJmc2wsYjQ4NjAtY2xvY2tnZW4iDQo+ICsJQ2hhc3NpcyBjbG9j
ayBzdHJpbmdzIGluY2x1ZGU6DQo+ICsJKiAiZnNsLHFvcmlxLWNsb2NrZ2VuLTEuMCI6IGZvciBj
aGFzc2lzIDEuMCBjbG9ja3MNCj4gKwkqICJmc2wscW9yaXEtY2xvY2tnZW4tMi4wIjogZm9yIGNo
YXNzaXMgMi4wIGNsb2Nrcw0KPiArLSByZWc6IE9mZnNldCBhbmQgbGVuZ3RoIG9mIHRoZSBjbG9j
ayByZWdpc3RlciBzZXQNCj4gKw0KPiArUmVjb21tZW5kZWQgcHJvcGVydGllczoNCj4gKy0gcmFu
Z2VzOiBBbGxvd3MgdmFsaWQgdHJhbnNsYXRpb24gYmV0d2VlbiBjaGlsZCdzIGFkZHJlc3Mgc3Bh
Y2UgYW5kDQo+ICsJcGFyZW50J3MuIE11c3QgYmUgcHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcyBz
dWItbm9kZXMuDQo+ICstICNhZGRyZXNzLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBvZiBj
ZWxscyB1c2VkIHRvIHJlcHJlc2VudA0KPiArCXBoeXNpY2FsIGJhc2UgYWRkcmVzc2VzLiAgTXVz
dCBiZSBwcmVzZW50IGlmIHRoZSBkZXZpY2UgaGFzDQo+ICsJc3ViLW5vZGVzIGFuZCBzZXQgdG8g
MSBpZiBwcmVzZW50DQo+ICstICNzaXplLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBvZiBj
ZWxscyB1c2VkIHRvIHJlcHJlc2VudA0KPiArCXRoZSBzaXplIG9mIGFuIGFkZHJlc3MuIE11c3Qg
YmUgcHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcw0KPiArCXN1Yi1ub2RlcyBhbmQgc2V0IHRvIDEg
aWYgcHJlc2VudA0KPiArDQo+ICsyLiBDbG9jayBQcm92aWRlci9Db25zdW1lciBCaW5kaW5nDQo+
ICsNCj4gK01vc3Qgb2YgdGhlIGJpbmRpbmdzIGFyZSBmcm9tIHRoZSBjb21tb24gY2xvY2sgYmlu
ZGluZ1sxXS4NCj4gKyBbMV0gRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2Nr
L2Nsb2NrLWJpbmRpbmdzLnR4dA0KPiArDQo+ICtSZXF1aXJlZCBwcm9wZXJ0aWVzOg0KPiArLSBj
b21wYXRpYmxlIDogU2hvdWxkIGluY2x1ZGUgb25lIG9mIHRoZSBmb2xsb3dpbmc6DQo+ICsJKiAi
ZnNsLHFvcmlxLWNvcmUtcGxsLTEuMCIgZm9yIGNvcmUgUExMIGNsb2NrcyAodjEuMCkNCj4gKyAg
ICAqICJmc2wscW9yaXEtY29yZS1wbGwtMi4wIiBmb3IgY29yZSBQTEwgY2xvY2tzICh2Mi4wKQ0K
PiArICAgICogImZzbCxxb3JpcS1jb3JlLW11eC0xLjAiIGZvciBjb3JlIG11eCBjbG9ja3MgKHYx
LjApDQo+ICsgICAgKiAiZnNsLHFvcmlxLWNvcmUtbXV4LTIuMCIgZm9yIGNvcmUgbXV4IGNsb2Nr
cyAodjIuMCkNCj4gKwkqICJmc2wscW9yaXEtc3lzY2xrLTEuMCI6IGZvciBpbnB1dCBzeXN0ZW0g
Y2xvY2sgKHYxLjApDQo+ICsJKiAiZnNsLHFvcmlxLXN5c2Nsay0yLjAiOiBmb3IgaW5wdXQgc3lz
dGVtIGNsb2NrICh2Mi4wKQ0KPiArLSAjY2xvY2stY2VsbHM6IEZyb20gY29tbW9uIGNsb2NrIGJp
bmRpbmcuIFRoZSBudW1iZXIgb2YgY2VsbHMgaW4gYQ0KPiArCWNsb2NrLXNwZWNpZmllci4gU2hv
dWxkIGJlIDwwPiBmb3IgImZzbCxxb3JpcS1zeXNjbGstWzEsMl0uMCINCj4gKwljbG9ja3MsIG9y
IDwxPiBmb3IgImZzbCxxb3JpcS1jb3JlLXBsbC1bMSwyXS4wIiBjbG9ja3MuDQo+ICsJRm9yICJm
c2wscW9yaXEtY29yZS1wbGwtWzEsMl0uMCIgY2xvY2tzLCB0aGUgc2luZ2xlDQo+ICsJY2xvY2st
c3BlY2lmaWVyIGNlbGwgbWF5IHRha2UgdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQo+ICsJKiAwIC0g
ZXF1YWwgdG8gdGhlIFBMTCBmcmVxdWVuY3kNCj4gKwkqIDEgLSBlcXVhbCB0byB0aGUgUExMIGZy
ZXF1ZW5jeSBkaXZpZGVkIGJ5IDINCj4gKwkqIDIgLSBlcXVhbCB0byB0aGUgUExMIGZyZXF1ZW5j
eSBkaXZpZGVkIGJ5IDQNCj4gKw0KPiArUmVjb21tZW5kZWQgcHJvcGVydGllczoNCj4gKy0gY2xv
Y2tzOiBTaG91bGQgYmUgdGhlIHBoYW5kbGUgb2YgaW5wdXQgcGFyZW50IGNsb2NrDQo+ICstIGNs
b2NrLW5hbWVzOiBGcm9tIGNvbW1vbiBjbG9jayBiaW5kaW5nLCBpbmRpY2F0ZXMgdGhlIGNsb2Nr
IG5hbWUNCj4gKy0gY2xvY2stb3V0cHV0LW5hbWVzOiBGcm9tIGNvbW1vbiBjbG9jayBiaW5kaW5n
LCBpbmRpY2F0ZXMgdGhlIG5hbWVzIG9mDQo+ICsJb3V0cHV0IGNsb2Nrcw0KPiArLSByZWc6IFNo
b3VsZCBiZSB0aGUgb2Zmc2V0IGFuZCBsZW5ndGggb2YgY2xvY2sgYmxvY2sgYmFzZSBhZGRyZXNz
Lg0KPiArCVRoZSBsZW5ndGggc2hvdWxkIGJlIDQuDQo+ICsNCj4gK0V4YW1wbGUgZm9yIGNsb2Nr
IGJsb2NrIGFuZCBjbG9jayBwcm92aWRlcjoNCj4gKy8gew0KPiArCWNsb2NrZ2VuOiBnbG9iYWwt
dXRpbGl0aWVzQGUxMDAwIHsNCj4gKwkJY29tcGF0aWJsZSA9ICJmc2wscDUwMjAtY2xvY2tnZW4i
LCAiZnNsLHFvcmlxLWNsb2NrZ2VuLTEuMCI7DQo+ICsJCXJhbmdlcyA9IDwweDAgMHhlMTAwMCAw
eDEwMDA+Ow0KPiArCQlyZWcgPSA8MHhlMTAwMCAweDEwMDA+Ow0KPiArCQkjYWRkcmVzcy1jZWxs
cyA9IDwxPjsNCj4gKwkJI3NpemUtY2VsbHMgPSA8MT47DQo+ICsNCj4gKwkJc3lzY2xrOiBzeXNj
bGsgew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDA+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2ws
cW9yaXEtc3lzY2xrLTEuMCI7DQo+ICsJCQljbG9jay1vdXRwdXQtbmFtZXMgPSAic3lzY2xrIjsN
Cj4gKwkJfQ0KPiArDQo+ICsJCXBsbDA6IHBsbDBAODAwIHsNCj4gKwkJCSNjbG9jay1jZWxscyA9
IDwxPjsNCj4gKwkJCXJlZyA9IDwweDgwMCAweDQ+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2ws
cW9yaXEtY29yZS1wbGwtMS4wIjsNCj4gKwkJCWNsb2NrcyA9IDwmc3lzY2xrPjsNCj4gKwkJCWNs
b2NrLW91dHB1dC1uYW1lcyA9ICJwbGwwIiwgInBsbDAtZGl2MiI7DQo+ICsJCX07DQo+ICsNCj4g
KwkJcGxsMTogcGxsMUA4MjAgew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDE+Ow0KPiArCQkJcmVn
ID0gPDB4ODIwIDB4ND47DQo+ICsJCQljb21wYXRpYmxlID0gImZzbCxxb3JpcS1jb3JlLXBsbC0x
LjAiOw0KPiArCQkJY2xvY2tzID0gPCZzeXNjbGs+Ow0KPiArCQkJY2xvY2stb3V0cHV0LW5hbWVz
ID0gInBsbDEiLCAicGxsMS1kaXYyIjsNCj4gKwkJfTsNCj4gKw0KPiArCQltdXgwOiBtdXgwQDAg
ew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDA+Ow0KPiArCQkJcmVnID0gPDB4MCAweDQ+Ow0KPiAr
CQkJY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtY29yZS1tdXgtMS4wIjsNCj4gKwkJCWNsb2NrcyA9
IDwmcGxsMCAwPiwgPCZwbGwwIDE+LCA8JnBsbDEgMD4sIDwmcGxsMSAxPjsNCj4gKwkJCWNsb2Nr
LW5hbWVzID0gInBsbDAiLCAicGxsMC1kaXYyIiwgInBsbDEiLCAicGxsMS1kaXYyIjsNCj4gKwkJ
CWNsb2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MCI7DQo+ICsJCX07DQo+ICsNCj4gKwkJbXV4MTog
bXV4MUAyMCB7DQo+ICsJCQkjY2xvY2stY2VsbHMgPSA8MD47DQo+ICsJCQlyZWcgPSA8MHgyMCAw
eDQ+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtY29yZS1tdXgtMS4wIjsNCj4gKwkJ
CWNsb2NrcyA9IDwmcGxsMCAwPiwgPCZwbGwwIDE+LCA8JnBsbDEgMD4sIDwmcGxsMSAxPjsNCj4g
KwkJCWNsb2NrLW5hbWVzID0gInBsbDAiLCAicGxsMC1kaXYyIiwgInBsbDEiLCAicGxsMS1kaXYy
IjsNCj4gKwkJCWNsb2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MSI7DQo+ICsJCX07DQo+ICsJfTsN
Cj4gKyAgfQ0KPiArDQo+ICtFeGFtcGxlIGZvciBjbG9jayBjb25zdW1lcjoNCj4gKw0KPiArLyB7
DQo+ICsJY3B1MDogUG93ZXJQQyxlNTUwMEAwIHsNCj4gKwkJLi4uDQo+ICsJCWNsb2NrcyA9IDwm
bXV4MD47DQo+ICsJCS4uLg0KPiArCX07DQo+ICsgIH0NCj4gLS0NCj4gMS44LjANCg0K
^ 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