Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
Mohan Kumar M writes: All of the variables references through @got translated into relocation type R_PPC64_GOT16_DS entries. All these entries correspond to one of the above entries in the .got section. But none of the entries in .got section are relocated. If that last statement is really true, then that would be an absolute show-stopper, since you're not going to stop the compiler generating loads from the TOC to get addresses of things. However, I don't think it's true. I compiled up a kernel using --emit-relocs on the final link, and with readelf -e I can see a .rela.got section containing a bunch of R_PPC64_ADDR64 relocs for entries in the .got section. So the problem appears to be either just that you are ignoring R_PPC64_ADDR64 relocs, or else that your relocs.c program has a bug and isn't seeing the .rela.got section. Now I have two options left: 1. Check for R_PPC64_GOT16_DS entries and check whether the contents addressed by r2+offset is relocated or not and apply relocation if its not. 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have already done. I was trying to point out that this can't possibly be a viable solution to the problem, because most of the TOC loads in the binary are generated by the C compiler, and only a few of them come from use of the LOAD_REG_ADDR macro in assembly code. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
Mohan Kumar M writes:
diff --git a/arch/powerpc/boot/relocs.c b/arch/powerpc/boot/relocs.c
new file mode 100644
index 000..31ca903
Where did this file come from? Did you write it all yourself? If
not, then you need to credit the original author in the patch
description at least. Also it needs a copyright notice.
There is some evidence that this has been copied from a similar
program for x86. For instance, this:
+/*
+ * Following symbols have been audited. There values are constant and do
+ * not change if bzImage is loaded at a different physical address than
+ * the address for which it has been compiled. Don't warn user about
+ * absolute relocations present w.r.t these symbols.
+ */
+static const char* safe_abs_relocs[] = {
+ __kernel_vsyscall,
+ __kernel_rt_sigreturn,
+ __kernel_sigreturn,
+ SYSENTER_RETURN,
+};
refers to symbols that don't exist on powerpc but (presumably) do on
x86.
Also, this:
+ if (shdr[i].sh_type == SHT_REL) {
+ reltab[i] = malloc(shdr[i].sh_size);
+ if (!reltab[i]) {
+ die(malloc of %d bytes for relocs failed\n,
+ shdr[i].sh_size);
+ }
+ relp = reltab[i];
is, I think, unnecessary, since as far as I know we never get SHT_REL
sections on powerpc.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely [EMAIL PROTECTED]
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver. At the moment, the driver
is not very capable and it is expected to be extended as more features
are needed for specifying the configuration in the device tree.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. When v2 is merged, most of this driver will
need to be reworked.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
include/sound/soc-of-simple.h | 21 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile|3 +
sound/soc/fsl/soc-of-simple.c | 171 +
4 files changed, 198 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
new file mode 100644
index 000..696fc51
--- /dev/null
+++ b/include/sound/soc-of-simple.h
@@ -0,0 +1,21 @@
+/*
+ * OF helpers for ALSA SoC
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#ifndef _INCLUDE_SOC_OF_H_
+#define _INCLUDE_SOC_OF_H_
+
+#include linux/of.h
+#include sound/soc.h
+
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_dai *dai,
+ struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+struct device_node *node,
+struct snd_soc_dai *cpu_dai);
+
+#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3368ace..398f002 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,3 +1,6 @@
+config SND_SOC_OF_SIMPLE
+ tristate
+
config SND_SOC_MPC8610
bool ALSA SoC support for the MPC8610 SOC
depends on MPC8610_HPCD
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 62f680a..aa2100b 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -1,3 +1,6 @@
+# Simple machine driver that extracts configuration from the OF device tree
+obj-$(CONFIG_SND_SOC_OF_SIMPLE) += soc-of-simple.o
+
# MPC8610 HPCD Machine Support
obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
new file mode 100644
index 000..0382fda
--- /dev/null
+++ b/sound/soc/fsl/soc-of-simple.c
@@ -0,0 +1,171 @@
+/*
+ * OF helpers for ALSA SoC Layer
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/of.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+#include sound/initval.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(ALSA SoC OpenFirmware bindings);
+
+static DEFINE_MUTEX(of_snd_soc_mutex);
+static LIST_HEAD(of_snd_soc_device_list);
+static int of_snd_soc_next_index;
+
+struct of_snd_soc_device {
+ int id;
+ struct list_head list;
+ struct snd_soc_device device;
+ struct snd_soc_machine machine;
+ struct snd_soc_dai_link dai_link;
+ struct platform_device *pdev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+};
+
+static struct snd_soc_ops of_snd_soc_ops = {
+};
+
+static struct of_snd_soc_device *
+of_snd_soc_get_device(struct device_node *codec_node)
+{
+ struct of_snd_soc_device *of_soc;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ if (of_soc-codec_node == codec_node)
+ return of_soc;
+ }
+
+ of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
+ if (!of_soc)
+ return NULL;
+
+ /* Initialize the structure and add it to the global list */
+ of_soc-codec_node = codec_node;
+ of_soc-id = of_snd_soc_next_index++;
+ of_soc-machine.dai_link = of_soc-dai_link;
+ of_soc-machine.num_links = 1;
+ of_soc-device.machine = of_soc-machine;
+ of_soc-dai_link.ops = of_snd_soc_ops;
+ list_add(of_soc-list, of_snd_soc_device_list);
+
+ return of_soc;
+}
+
+static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ /* Only register the device if both the codec and platform have
+* been registered */
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ return;
+
+ pr_info(platform--codec match achieved; registering machine\n);
+
+ pdev =
[PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Grant Likely [EMAIL PROTECTED]
This is an I2S bus driver for the MPC5200 PSC device. It depends on the
soc-of helper functions to match a PSC device with a codec based on data
in the device tree.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
sound/soc/fsl/Kconfig |7
sound/soc/fsl/Makefile |2
sound/soc/fsl/mpc5200_psc_i2s.c | 884 +++
3 files changed, 893 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 398f002..bba9546 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -17,3 +17,10 @@ config SND_SOC_MPC8610_HPCD
default y if MPC8610_HPCD
help
Say Y if you want to enable audio on the Freescale MPC8610 HPCD.
+
+config SND_SOC_MPC5200_I2S
+ tristate Freescale MPC5200 PSC in I2S mode driver
+ select SND_SOC_OF_SIMPLE
+ depends on SND_SOC PPC_MPC52xx
+ help
+ Say Y here to support the MPC5200 PSCs in I2S mode.
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index aa2100b..035da4a 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -7,3 +7,5 @@ obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
# MPC8610 Platform Support
obj-$(CONFIG_SND_SOC_MPC8610) += fsl_ssi.o fsl_dma.o
+obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
+
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
new file mode 100644
index 000..8692329
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -0,0 +1,884 @@
+/*
+ * Freescale MPC5200 PSC in I2S mode
+ * ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+
+#include sysdev/bestcomm/bestcomm.h
+#include sysdev/bestcomm/gen_bd.h
+#include asm/mpc52xx_psc.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Freescale MPC5200 PSC in I2S mode ASoC Driver);
+MODULE_LICENSE(GPL);
+
+/**
+ * PSC_I2S_RATES: sample rates supported by the I2S
+ *
+ * This driver currently only supports the PSC running in I2S slave mode,
+ * which means the codec determines the sample rate. Therefore, we tell
+ * ALSA that we support all rates and let the codec driver decide what rates
+ * are really supported.
+ */
+#define PSC_I2S_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \
+ SNDRV_PCM_RATE_CONTINUOUS)
+
+/**
+ * PSC_I2S_FORMATS: audio formats supported by the PSC I2S mode
+ */
+#define PSC_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | \
+SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE | \
+SNDRV_PCM_FMTBIT_S32_BE)
+
+/**
+ * psc_i2s_stream - Data specific to a single stream (playback or capture)
+ * @active:flag indicating if the stream is active
+ * @psc_i2s: pointer back to parent psc_i2s data structure
+ * @bcom_task: bestcomm task structure
+ * @irq: irq number for bestcomm task
+ * @period_start: physical address of start of DMA region
+ * @period_end:physical address of end of DMA region
+ * @period_next_pt:physical address of next DMA buffer to enqueue
+ * @period_bytes: size of DMA period in bytes
+ */
+struct psc_i2s_stream {
+ int active;
+ struct psc_i2s *psc_i2s;
+ struct bcom_task *bcom_task;
+ int irq;
+ struct snd_pcm_substream *stream;
+ dma_addr_t period_start;
+ dma_addr_t period_end;
+ dma_addr_t period_next_pt;
+ dma_addr_t period_current_pt;
+ int period_bytes;
+};
+
+/**
+ * psc_i2s - Private driver data
+ * @name: short name for this device (PSC0, PSC1, etc)
+ * @psc_regs: pointer to the PSC's registers
+ * @fifo_regs: pointer to the PSC's FIFO registers
+ * @irq: IRQ of this PSC
+ * @dev: struct device pointer
+ * @dai: the CPU DAI for this device
+ * @sicr: Base value used in serial interface control register; mode is ORed
+ *with this value.
+ * @playback: Playback stream context data
+ * @capture: Capture stream context data
+ */
+struct psc_i2s {
+ char name[32];
+ struct mpc52xx_psc __iomem *psc_regs;
+ struct mpc52xx_psc_fifo __iomem *fifo_regs;
+ unsigned int irq;
+ struct device *dev;
+ struct snd_soc_dai dai;
+ spinlock_t lock;
+ u32 sicr;
+
+ /* per-stream data */
+ struct psc_i2s_stream playback;
+ struct psc_i2s_stream capture;
+
+ /* Statistics */
+ struct {
+ int overrun_count;
+ int underrun_count;
+ } stats;
+};
+
[PATCH v3 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely [EMAIL PROTECTED]
ASoC Codec driver for the TLV320AIC26 device. As it stands, this driver
doesn't support all the modes and clocking options of the AIC16, but it
is a start.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
sound/soc/codecs/Kconfig |4
sound/soc/codecs/Makefile |2
sound/soc/codecs/tlv320aic26.c | 519
sound/soc/codecs/tlv320aic26.h | 93 +++
4 files changed, 618 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 1db04a2..b399a64 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -47,6 +47,10 @@ config SND_SOC_CS4270_VD33_ERRATA
bool
depends on SND_SOC_CS4270
+config SND_SOC_TLV320AIC26
+ tristate TI TLB320AIC26 Codec support
+ depends on SND_SOC SPI
+
config SND_SOC_TLV320AIC3X
tristate
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d7b97ab..dc0357e 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -9,6 +9,7 @@ snd-soc-wm8990-objs := wm8990.o
snd-soc-wm9712-objs := wm9712.o
snd-soc-wm9713-objs := wm9713.o
snd-soc-cs4270-objs := cs4270.o
+snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
@@ -22,4 +23,5 @@ obj-$(CONFIG_SND_SOC_WM8990) += snd-soc-wm8990.o
obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
+obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
new file mode 100644
index 000..4621fda
--- /dev/null
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -0,0 +1,519 @@
+/*
+ * Texas Instruments TLV320AIC26 low power audio CODEC
+ * ALSA SoC CODEC driver
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/device.h
+#include linux/sysfs.h
+#include linux/spi/spi.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/soc-of-simple.h
+#include sound/initval.h
+
+#include tlv320aic26.h
+
+MODULE_DESCRIPTION(ASoC TLV320AIC26 codec driver);
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+
+/* AIC26 driver private data */
+struct aic26 {
+ struct spi_device *spi;
+ struct snd_soc_codec codec;
+ u16 reg_cache[AIC26_NUM_REGS]; /* shadow registers */
+ int master;
+ int datfm;
+ int mclk;
+
+ /* Keyclick parameters */
+ int keyclick_amplitude;
+ int keyclick_freq;
+ int keyclick_len;
+};
+
+/* -
+ * Register access routines
+ */
+static unsigned int aic26_reg_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ struct aic26 *aic26 = codec-private_data;
+ u16 *cache = codec-reg_cache;
+ u16 cmd, value;
+ u8 buffer[2];
+ int rc;
+
+ if (reg = AIC26_NUM_REGS) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ /* Do SPI transfer; first 16bits are command; remaining is
+* register contents */
+ cmd = AIC26_READ_COMMAND_WORD(reg);
+ buffer[0] = (cmd 8) 0xff;
+ buffer[1] = cmd 0xff;
+ rc = spi_write_then_read(aic26-spi, buffer, 2, buffer, 2);
+ if (rc) {
+ dev_err(aic26-spi-dev, AIC26 reg read error\n);
+ return -EIO;
+ }
+ value = (buffer[0] 8) | buffer[1];
+
+ /* Update the cache before returning with the value */
+ cache[reg] = value;
+ return value;
+}
+
+static unsigned int aic26_reg_read_cache(struct snd_soc_codec *codec,
+unsigned int reg)
+{
+ u16 *cache = codec-reg_cache;
+
+ if (reg = AIC26_NUM_REGS) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ return cache[reg];
+}
+
+static int aic26_reg_write(struct snd_soc_codec *codec, unsigned int reg,
+ unsigned int value)
+{
+ struct aic26 *aic26 = codec-private_data;
+ u16 *cache = codec-reg_cache;
+ u16 cmd;
+ u8 buffer[4];
+ int rc;
+
+ if (reg = AIC26_NUM_REGS) {
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
+
+ /* Do SPI transfer; first 16bits are command; remaining is data
+* to write into register */
+ cmd = AIC26_WRITE_COMMAND_WORD(reg);
+ buffer[0] = (cmd 8) 0xff;
+ buffer[1] = cmd 0xff;
+ buffer[2] = value 8;
+ buffer[3]
[PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
Hi all,
Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
support to ALSA SoC. I believe all the comments are addressed and I
hope that this series is now ready to be merged. I would really like
to see these ones land in 2.6.27.
Thanks,
g.
include/sound/soc-of-simple.h | 21 +
sound/soc/codecs/Kconfig|4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tlv320aic26.c | 519 +++
sound/soc/codecs/tlv320aic26.h | 93
sound/soc/fsl/Kconfig | 10 +
sound/soc/fsl/Makefile |5 +
sound/soc/fsl/mpc5200_psc_i2s.c | 884 +++
sound/soc/fsl/soc-of-simple.c | 171
9 files changed, 1709 insertions(+), 0 deletions(-)
Cheers,
g.
On Tue, Jul 22, 2008 at 12:53 AM, Grant Likely
[EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver. At the moment, the driver
is not very capable and it is expected to be extended as more features
are needed for specifying the configuration in the device tree.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. When v2 is merged, most of this driver will
need to be reworked.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
include/sound/soc-of-simple.h | 21 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile|3 +
sound/soc/fsl/soc-of-simple.c | 171
+
4 files changed, 198 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
new file mode 100644
index 000..696fc51
--- /dev/null
+++ b/include/sound/soc-of-simple.h
@@ -0,0 +1,21 @@
+/*
+ * OF helpers for ALSA SoC
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#ifndef _INCLUDE_SOC_OF_H_
+#define _INCLUDE_SOC_OF_H_
+
+#include linux/of.h
+#include sound/soc.h
+
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_dai *dai,
+ struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+struct device_node *node,
+struct snd_soc_dai *cpu_dai);
+
+#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3368ace..398f002 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,3 +1,6 @@
+config SND_SOC_OF_SIMPLE
+ tristate
+
config SND_SOC_MPC8610
bool ALSA SoC support for the MPC8610 SOC
depends on MPC8610_HPCD
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 62f680a..aa2100b 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -1,3 +1,6 @@
+# Simple machine driver that extracts configuration from the OF device tree
+obj-$(CONFIG_SND_SOC_OF_SIMPLE) += soc-of-simple.o
+
# MPC8610 HPCD Machine Support
obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
new file mode 100644
index 000..0382fda
--- /dev/null
+++ b/sound/soc/fsl/soc-of-simple.c
@@ -0,0 +1,171 @@
+/*
+ * OF helpers for ALSA SoC Layer
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/of.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+#include sound/initval.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(ALSA SoC OpenFirmware bindings);
+
+static DEFINE_MUTEX(of_snd_soc_mutex);
+static LIST_HEAD(of_snd_soc_device_list);
+static int of_snd_soc_next_index;
+
+struct of_snd_soc_device {
+ int id;
+ struct list_head list;
+ struct snd_soc_device device;
+ struct snd_soc_machine machine;
+ struct snd_soc_dai_link dai_link;
+ struct platform_device *pdev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+};
+
+static struct snd_soc_ops of_snd_soc_ops = {
+};
+
+static struct of_snd_soc_device *
+of_snd_soc_get_device(struct device_node *codec_node)
+{
+ struct of_snd_soc_device *of_soc;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ if (of_soc-codec_node == codec_node)
+ return of_soc;
+ }
+
+ of_soc =
[PATCH] powerpc/mpc5200: add PSC SICR bit definitions
From: Grant Likely [EMAIL PROTECTED]
Required by the PSC I2S audio driver.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
include/asm-powerpc/mpc52xx_psc.h | 32 +++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/mpc52xx_psc.h
b/include/asm-powerpc/mpc52xx_psc.h
index 5467c2c..8917ed6 100644
--- a/include/asm-powerpc/mpc52xx_psc.h
+++ b/include/asm-powerpc/mpc52xx_psc.h
@@ -60,10 +60,12 @@
#define MPC52xx_PSC_RXTX_FIFO_ALARM0x0002
#define MPC52xx_PSC_RXTX_FIFO_EMPTY0x0001
-/* PSC interrupt mask bits */
+/* PSC interrupt status/mask bits */
#define MPC52xx_PSC_IMR_TXRDY 0x0100
#define MPC52xx_PSC_IMR_RXRDY 0x0200
#define MPC52xx_PSC_IMR_DB 0x0400
+#define MPC52xx_PSC_IMR_TXEMP 0x0800
+#define MPC52xx_PSC_IMR_ORERR 0x1000
#define MPC52xx_PSC_IMR_IPC0x8000
/* PSC input port change bit */
@@ -92,6 +94,34 @@
#define MPC52xx_PSC_RFNUM_MASK 0x01ff
+#define MPC52xx_PSC_SICR_DTS1 (1 29)
+#define MPC52xx_PSC_SICR_SHDR (1 28)
+#define MPC52xx_PSC_SICR_SIM_MASK (0xf 24)
+#define MPC52xx_PSC_SICR_SIM_UART (0x0 24)
+#define MPC52xx_PSC_SICR_SIM_UART_DCD (0x8 24)
+#define MPC52xx_PSC_SICR_SIM_CODEC_8 (0x1 24)
+#define MPC52xx_PSC_SICR_SIM_CODEC_16 (0x2 24)
+#define MPC52xx_PSC_SICR_SIM_AC97 (0x3 24)
+#define MPC52xx_PSC_SICR_SIM_SIR (0x8 24)
+#define MPC52xx_PSC_SICR_SIM_SIR_DCD (0xc 24)
+#define MPC52xx_PSC_SICR_SIM_MIR (0x5 24)
+#define MPC52xx_PSC_SICR_SIM_FIR (0x6 24)
+#define MPC52xx_PSC_SICR_SIM_CODEC_24 (0x7 24)
+#define MPC52xx_PSC_SICR_SIM_CODEC_32 (0xf 24)
+#define MPC52xx_PSC_SICR_GENCLK(1 23)
+#define MPC52xx_PSC_SICR_I2S (1 22)
+#define MPC52xx_PSC_SICR_CLKPOL(1 21)
+#define MPC52xx_PSC_SICR_SYNCPOL (1 20)
+#define MPC52xx_PSC_SICR_CELLSLAVE (1 19)
+#define MPC52xx_PSC_SICR_CELL2XCLK (1 18)
+#define MPC52xx_PSC_SICR_ESAI (1 17)
+#define MPC52xx_PSC_SICR_ENAC97(1 16)
+#define MPC52xx_PSC_SICR_SPI (1 15)
+#define MPC52xx_PSC_SICR_MSTR (1 14)
+#define MPC52xx_PSC_SICR_CPOL (1 13)
+#define MPC52xx_PSC_SICR_CPHA (1 12)
+#define MPC52xx_PSC_SICR_USEEOF(1 11)
+#define MPC52xx_PSC_SICR_DISABLEEOF(1 10)
/* Structure of the hardware registers */
struct mpc52xx_psc {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull mpc5200-next
Hi Paul/Ben Please pull my mpc5200 next branch for the following commits: Thanks, g. The following changes since commit e89970aa93b06d0605a488e74af3b0a2a80e03b5: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant Likely (3): powerpc/mpc5200: Make mpc5200 GPIO driver select the GENERIC_GPIO config powerpc/mpc5200: add PSC SICR bit definitions of-bindings: Add binding documentation for SPI busses and devices Jon Smirl (2): powerpc/mpc5200: Add AC97 register definitions for the MPC52xx PSC powerpc/mpc5200: Remove fsl-soc.c from mpc5200 build, it is not needed. Wolfram Sang (1): powerpc/mpc5200: Fix wrong 'no interrupt' handling in of_i2c Documentation/powerpc/booting-without-of.txt | 57 ++ arch/powerpc/platforms/52xx/Kconfig |2 +- drivers/of/of_i2c.c |2 - include/asm-powerpc/mpc52xx_psc.h| 40 +- 4 files changed, 95 insertions(+), 6 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull from powerpc.git merge branch
Hi Linus ! Here's the second batch of powerpc updates. I should have a last one before the end of the merge window for things that are stealing dealing with conflicts or dependencies but we are getting there. So please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Hopefully this one shouldn't whack the main Makefile :-) Note a couple of fbdev updates. One is an offb change by me, this is a powerpc specific driver so that shouldn't affect anybody else, and one is the ps3 specific fbdev by Geoff, so again, there should be no collateral damage. Some drivers/net changes to freescale specific drivers are coming from Kumar's tree. Kumar, I merged them, however, shouldn't we have Jeff's ack on these things or is it ok as long as those are arch specific drivers and the changes boring ? The cell EDAC change has been ack'ed by the EDAC maintainer. Cheers, Ben. Documentation/DMA-attributes.txt |9 Documentation/powerpc/booting-without-of.txt | 189 + .../powerpc/dts-bindings/fsl/cpm_qe/gpio.txt | 38 .../powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt | 53 .../powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt | 17 Documentation/powerpc/dts-bindings/fsl/pmc.txt | 63 Documentation/powerpc/dts-bindings/fsl/tsec.txt| 31 .../powerpc/dts-bindings/fsl/upm-nand.txt | 28 Documentation/powerpc/dts-bindings/gpio/led.txt| 15 arch/powerpc/Kconfig | 14 arch/powerpc/boot/Makefile |4 arch/powerpc/boot/dts/mpc7448hpc2.dts | 24 arch/powerpc/boot/dts/mpc8313erdb.dts | 241 + arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14 arch/powerpc/configs/85xx/mpc8544_ds_defconfig |8 arch/powerpc/configs/85xx/mpc8572_ds_defconfig |8 arch/powerpc/configs/mpc85xx_defconfig |8 arch/powerpc/configs/mpc8610_hpcd_defconfig| 121 + arch/powerpc/configs/mpc8641_hpcn_defconfig|8 arch/powerpc/configs/ppc6xx_defconfig | 3304 arch/powerpc/configs/ps3_defconfig | 196 + arch/powerpc/kernel/cputable.c | 20 arch/powerpc/kernel/head_fsl_booke.S | 187 - arch/powerpc/kernel/iommu.c| 13 arch/powerpc/kernel/pci-common.c |1 arch/powerpc/kernel/prom_parse.c | 44 arch/powerpc/kernel/stacktrace.c |2 arch/powerpc/kernel/vmlinux.lds.S | 31 arch/powerpc/lib/feature-fixups.c |2 arch/powerpc/lib/string.S | 18 arch/powerpc/platforms/52xx/Kconfig|1 arch/powerpc/platforms/82xx/Kconfig|1 arch/powerpc/platforms/82xx/ep8248e.c |4 arch/powerpc/platforms/83xx/Kconfig|3 arch/powerpc/platforms/83xx/Makefile |2 arch/powerpc/platforms/83xx/mpc831x_rdb.c |1 arch/powerpc/platforms/83xx/mpc832x_mds.c |1 arch/powerpc/platforms/83xx/mpc832x_rdb.c |1 arch/powerpc/platforms/83xx/mpc834x_itx.c |1 arch/powerpc/platforms/83xx/mpc834x_mds.c |1 arch/powerpc/platforms/83xx/mpc836x_mds.c |1 arch/powerpc/platforms/83xx/mpc836x_rdk.c |1 arch/powerpc/platforms/83xx/mpc837x_mds.c |1 arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 arch/powerpc/platforms/83xx/mpc83xx.h |5 arch/powerpc/platforms/83xx/pci.c | 91 - arch/powerpc/platforms/83xx/sbc834x.c |1 arch/powerpc/platforms/83xx/suspend-asm.S | 533 +++ arch/powerpc/platforms/83xx/suspend.c | 388 ++ arch/powerpc/platforms/83xx/usb.c | 24 arch/powerpc/platforms/85xx/Kconfig|3 arch/powerpc/platforms/85xx/mpc85xx_ds.c |2 arch/powerpc/platforms/86xx/Kconfig|3 arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 87 - arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 arch/powerpc/platforms/Kconfig |6 arch/powerpc/platforms/Kconfig.cputype |5 arch/powerpc/platforms/cell/Kconfig| 25 arch/powerpc/platforms/cell/Makefile |3 arch/powerpc/platforms/cell/cbe_powerbutton.c | 117 + arch/powerpc/platforms/cell/cpufreq_spudemand.c| 184 + arch/powerpc/platforms/cell/iommu.c| 118 + arch/powerpc/platforms/cell/pervasive.c| 27 arch/powerpc/platforms/cell/pervasive.h|9 arch/powerpc/platforms/cell/ras.c | 46 arch/powerpc/platforms/fsl_uli1575.c | 117 + arch/powerpc/platforms/iseries/Kconfig |1
Re: UIO not working on ppc405 onchip registers
Hello Uwe,
On Tuesday 22 July 2008, Uwe Kleine-König wrote:
I don't know powerpc in general nor ppc405ep in detail but IIRC arm has
problems if some memory is mapped twice. Might this be the problem
here?
Maybee, the emac0 (0xef600800) and emac1 (0xef600900) get mapped as well,
because AFAIK I have to map a whole pagesize (0x1000).
+ int uiofd = open(UIO_DEV,O_RDWR);
For debugging this is OK, in the final application you should add some
tests. Check the UIO documentation for the details.
The whole example was meant to be short.
+static int uio_gpio_remove(struct device *dev)
+{
+ uio_unregister_device(info);
+ info.mem[0].addr = 0;
+ info.mem[0].size = 0;
+ return 0;
+}
Are you sure that overwriting info.mem[0].addr is a good idea? Then
unbinding the platform device and rebinding it fails to do the right
thing for sure.
This was stolen from uio_dummy. So this might become a common error :(
Thanks a lot for your comments, I will try to get an exclusive memory region
mapped.
Markus
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UIO not working on ppc405 onchip registers
On Tuesday 22 July 2008, Ben Nizette wrote: As an aside, you sure you want to do this anyway? No ;) I'd suggest that you just do a gpio chip driver for this, tie it in to gpiolib and use the gpiolib user interface (which IIRC has only made it as far as -mm but is on the way up). This gives kernel internals nice access to the pins as well through the standard gpio framework. This was just an example to make it others easier to reproduce my problem. My goal is to have a soft spi driver in userspace, which would probably be slower if it uses gpiolib. This driver is integrated in the application I want to port to Linux. Thanks Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UIO not working on ppc405 onchip registers
Hey Markus, +config UIO_GPIO + tristate Driver for PPC_4xx GPIO As an aside, you sure you want to do this anyway? I'd suggest that you just do a gpio chip driver for this, tie it in to gpiolib and use the gpiolib user interface (which IIRC has only made it as far as -mm but is on the way up). This gives kernel internals nice access to the pins as well through the standard gpio framework. Thanks :-) --Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UIO not working on ppc405 onchip registers
Hello Markus,
Markus Brunner wrote:
I'm unable to get UIO working on the ppc405ep onchip registers (e.g. gpio/iic)
however it's working fine on peripherals.
I don't know powerpc in general nor ppc405ep in detail but IIRC arm has
problems if some memory is mapped twice. Might this be the problem
here?
It seems to me to be a problem with UIO on powerpc, because if I change the
address (and nothing more) to point to a external FPGA it's working fine.
I also tried the generic uio_pdrv which had the same problems.
Sometimes I get a bus error sometimes it only produces wrong results.
The bus error occurred when not a full 32 bit register was read (e.g. only a
byte of it), but I'm not sure if it doesn't occur for other reasons as well.
Well, if this is a 32bit memory mapped device and you do a non-32 bit
access strage things can happen.
diff -upNr linux-2.6.26/drivers/uio-orig/Kconfig
linux-2.6.26/drivers/uio/Kconfig
--- linux-2.6.26/drivers/uio-orig/Kconfig 2008-07-18 09:15:51.0
+0200
+++ linux-2.6.26/drivers/uio/Kconfig2008-07-18 09:16:18.0 +0200
@@ -39,4 +39,12 @@ config UIO_SMX
If you compile this as a module, it will be called uio_smx.
+config UIO_GPIO
+ tristate Driver for PPC_4xx GPIO
+ depends on UIO
+ default n
+ help
+ Driver for PPC_4xx GPIO Registers
+
endif
This endif matches an if UIO, so there is no need to depend on UIO
explicitly.
diff -upNr linux-2.6.26/drivers/uio-orig/Makefile
linux-2.6.26/drivers/uio/Makefile
--- linux-2.6.26/drivers/uio-orig/Makefile 2008-07-18 09:27:18.0
+0200
+++ linux-2.6.26/drivers/uio/Makefile 2008-07-18 09:16:50.0 +0200
@@ -1,3 +1,4 @@
obj-$(CONFIG_UIO) += uio.o
obj-$(CONFIG_UIO_CIF) += uio_cif.o
obj-$(CONFIG_UIO_SMX) += uio_smx.o
+obj-$(CONFIG_UIO_GPIO) += uio_ppc_4xx-gpio.o
diff -upNr linux-2.6.26/drivers/uio-orig/uio-gpio.c
linux-2.6.26/drivers/uio/uio-gpio.c
--- linux-2.6.26/drivers/uio-orig/uio-gpio.c1970-01-01 01:00:00.0
+0100
+++ linux-2.6.26/drivers/uio/uio-gpio.c 2008-07-18 09:18:56.0 +0200
@@ -0,0 +1,59 @@
+#include sys/types.h
+#include sys/time.h
+#include sys/stat.h
+#include sys/mman.h
+#include fcntl.h
+#include unistd.h
+#include stdio.h
+#include stdlib.h
+
+const unsigned long pin_mask( unsigned int pin) { return (0x8000
(pin));}
+
+const char UIO_DEV[] = /dev/uio0;
+const unsigned int UIO_SIZE = 0x1000;
+const unsigned int UIO_ADDR = 0xef600700;
+
+const int or = 0;
+const int tcr = 1;
+
+const unsigned int gpio_pin = 0;/* What gpio pin do you want to
toggle? */
+
+volatile unsigned long *gpio_regs;
+
+int main(int argc, char *argv[])
+{
+ int uiofd = open(UIO_DEV,O_RDWR);
For debugging this is OK, in the final application you should add some
tests. Check the UIO documentation for the details.
+ if (uiofd 0)
+ return uiofd;
+
+ unsigned long* map_addr = mmap(NULL,
+ UIO_SIZE,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED,
+ uiofd,
+ 0);
+ if (map_addr == ((unsigned long*) -1))
+ return -1;
[...]
diff -upNr linux-2.6.26/drivers/uio-orig/uio_ppc_4xx-gpio.c
linux-2.6.26/drivers/uio/uio_ppc_4xx-gpio.c
--- linux-2.6.26/drivers/uio-orig/uio_ppc_4xx-gpio.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.26/drivers/uio/uio_ppc_4xx-gpio.c 2008-07-18 09:23:32.0
+0200
@@ -0,0 +1,74 @@
+/*
+ * simple UIO GPIO driver.
+ *
+ * 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/device.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/uio_driver.h
+
+#include asm/io.h
+
+static struct uio_info info = {
+ .name = uio_gpio,
+ .version = 0.0.0,
+ .irq = UIO_IRQ_NONE,
+ .irq_flags = 0,
+.mem[0].addr = 0xef600700,
+.mem[0].size = 0x1000,
+ .mem[0].memtype = UIO_MEM_PHYS,
+};
IIRC you should initialise the other mem members.
+static int __devinit uio_gpio_probe(struct device *dev)
+{
+ if (uio_register_device(dev, info)){
+ printk(KERN_ERR uio_gpio: uio_register_device failed\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static int uio_gpio_remove(struct device *dev)
+{
+ uio_unregister_device(info);
+ info.mem[0].addr = 0;
+ info.mem[0].size = 0;
+ return 0;
+}
Are you sure that overwriting info.mem[0].addr is a good idea? Then
unbinding the platform device and rebinding it fails to do the right
thing for sure.
+static struct platform_device
Re: UIO not working on ppc405 onchip registers
On Tue, 2008-07-22 at 09:48 +0200, [EMAIL PROTECTED] wrote: On Tuesday 22 July 2008, Ben Nizette wrote: As an aside, you sure you want to do this anyway? No ;) I'd suggest that you just do a gpio chip driver for this, tie it in to gpiolib and use the gpiolib user interface (which IIRC has only made it as far as -mm but is on the way up). This gives kernel internals nice access to the pins as well through the standard gpio framework. This was just an example to make it others easier to reproduce my problem. My goal is to have a soft spi driver in userspace, which would probably be slower if it uses gpiolib. This driver is integrated in the application I want to port to Linux. Ah right, cool. I donno what the speed would be like, but both David Brownell and Michael Buesch both have spi-over-gpio patches floating around (eg [1]). That, plus the spidev interface, might at least be worth a try..? But I'll let you get back to solving the UIO problem at hand :-D --Ben. [1] http://lwn.net/Articles/290066/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
Hi,
On Fri, Jul 18, 2008 at 02:10:08PM +0200, Sebastian Siewior wrote:
Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping]
changed the phydev-lock from spinlock into a mutex. Now, the following
code path got triggered while NFS was unavailable:
[...]
I found out that the same code path may be trigger in
- drivers/net/ucc_geth.c
- drivers/net/fec_mpc52xx.c
Recently, I described a (I think) similar problem:
(http://ozlabs.org/pipermail/linuxppc-dev/2008-July/059686.html)
===
Hello,
today, I was debugging a kernel crash on a board with a MPC5200B using
2.6.26-rc9. I found the following code in drivers/net/fec_mpc52xx.c:
static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
{
[...]
/* on fifo error, soft-reset fec */
if (ievent (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR))
dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n);
if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR))
dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n);
mpc52xx_fec_reset(dev);
netif_wake_queue(dev);
return IRQ_HANDLED;
}
[...]
}
Calling mpc52xx_fec_reset() from interrupt context is bad, at least
because
a) it calls phy_write, which contains BUG_ON(in_interrupt())
b) it calls mpc52xx_fec_hw_init, which has a delay-loop to check
if the reset was successful (1..50 us)
I assume the proper thing to do is to set a flag in the ISR and handle
the soft reset later in some other context. Having never dealt with the
network core and its drivers so far, I am not sure which place would be
the right one to perform the soft reset. To not make things worse, I
hope people with more insight to network stuff can deliver a suitable
solution to this problem.
All the best,
Wolfram
===
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
Paul Mackerras wrote:
Mohan Kumar M writes:
diff --git a/arch/powerpc/boot/relocs.c b/arch/powerpc/boot/relocs.c
new file mode 100644
index 000..31ca903
Where did this file come from? Did you write it all yourself? If
not, then you need to credit the original author in the patch
description at least. Also it needs a copyright notice.
There is some evidence that this has been copied from a similar
program for x86. For instance, this:
Hi Paul,
Yes, its taken from x86 relocs.c. I will include proper credits to the
original author in the next patch.
Also, this:
+ if (shdr[i].sh_type == SHT_REL) {
+ reltab[i] = malloc(shdr[i].sh_size);
+ if (!reltab[i]) {
+ die(malloc of %d bytes for relocs failed\n,
+ shdr[i].sh_size);
+ }
+ relp = reltab[i];
is, I think, unnecessary, since as far as I know we never get SHT_REL
sections on powerpc.
Ok, I will remove SHT_REL code in the relocs.c file.
Regards,
Mohan.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: radeonfb, dedicate memory to something else
Jon Smirl wrote: On 7/20/08, Matt Sealey [EMAIL PROTECTED] wrote: Hi guys, I know this isn't a PPC question, but since some of the RadeonFB developers live here I thought best (and it's about a PPC platform). Is there any way to hack up the RadeonFB driver - or anything related - to reserve portions of the memory for a fake MTD or so, and still use the Radeon as a graphics device? What I am talking about basically is turning a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB card.. Somebody write this long ago. Maybe around 2000. That's all I remember. I think they made the video memory into a ram disk. Yeah making it into a ramdisk precludes the use of the card as a video card though.. this is what I am trying to get around. If fbdev and X can cooperate on believing that a 64MB card is a 32MB card, then the upper 32MB can be used to attach the MTD ram driver at a certain address (maybe we can even make a hacky stub driver that recognizes this configuration based on OF tree..) There are obvious limitations in that the Pegasos/Efika firmware only will map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway, but that shouldn't matter. I just wonder, how it can be done that radeonfb or other graphics drivers can be told please only use the first 32MB and then either manually or automatically, map the rest as ramdisk. I believe there is more to it, the GART window may be smaller than the total RAM on the card. You need to use the GART to map in the appropriate pieces. The problem here is the PCI bus on the Efika is a PCI bus, with an AGP riser. It doesn't add any AGP functionality like real GART on the host controller side, so there is nothing to map system memory into AGP's view of the system.. it always confused me how pcigart is meant to work and how an AGP GART does anything different to how PCI works in the first place (the documentation/spec doesn't make it that clear in my opinion :) You would certainly know better than I.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: radeonfb, dedicate memory to something else
On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote: Jon Smirl wrote: On 7/20/08, Matt Sealey [EMAIL PROTECTED] wrote: Hi guys, I know this isn't a PPC question, but since some of the RadeonFB developers live here I thought best (and it's about a PPC platform). Is there any way to hack up the RadeonFB driver - or anything related - to reserve portions of the memory for a fake MTD or so, and still use the Radeon as a graphics device? What I am talking about basically is turning a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB card.. Somebody write this long ago. Maybe around 2000. That's all I remember. I think they made the video memory into a ram disk. Yeah making it into a ramdisk precludes the use of the card as a video card though.. this is what I am trying to get around. If fbdev and X can cooperate on believing that a 64MB card is a 32MB card, then the upper 32MB can be used to attach the MTD ram driver at a certain address (maybe we can even make a hacky stub driver that recognizes this configuration based on OF tree..) There are obvious limitations in that the Pegasos/Efika firmware only will map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway, but that shouldn't matter. I just wonder, how it can be done that radeonfb or other graphics drivers can be told please only use the first 32MB and then either manually or automatically, map the rest as ramdisk. You can limit the amount of video RAM used by X using the VideoRam directive in xorg.conf(5). I believe there is more to it, the GART window may be smaller than the total RAM on the card. You need to use the GART to map in the appropriate pieces. The problem here is the PCI bus on the Efika is a PCI bus, with an AGP riser. It doesn't add any AGP functionality like real GART on the host controller side, so there is nothing to map system memory into AGP's view of the system.. it always confused me how pcigart is meant to work and how an AGP GART does anything different to how PCI works in the first place (the documentation/spec doesn't make it that clear in my opinion :) GART doesn't have anything to do with this. I suspect he was thinking of the PCI BARs not covering all video RAM. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
Scan for linux,usable-memory properties in case of dynamic reconfiguration
memory . Support for kexec/kdump.
Signed-off-by: Chandru Siddalingappa [EMAIL PROTECTED]
---
Patch applies on powerpc tree. Patch was reviewed by Nathan Fontenot, Stephen
Rothwell, Michael Neuling.
arch/powerpc/kernel/prom.c | 40 +++--
arch/powerpc/mm/numa.c | 48 ---
2 files changed, 65 insertions(+), 23 deletions(-)
diff -Naurp powerpc-orig/arch/powerpc/kernel/prom.c
powerpc/arch/powerpc/kernel/prom.c
--- powerpc-orig/arch/powerpc/kernel/prom.c 2008-07-22 14:11:53.0
+0530
+++ powerpc/arch/powerpc/kernel/prom.c 2008-07-22 14:12:17.0 +0530
@@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *usm;
+ unsigned long l, n, flags, ranges;
u64 base, size, lmb_size;
+ char buf[32];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
@@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
or if the block is not assigned to this partition (0x8) */
if ((flags 0x80) || !(flags 0x8))
continue;
- size = lmb_size;
- if (iommu_is_off) {
+ if (iommu_is_off)
if (base = 0x8000ul)
continue;
- if ((base + size) 0x8000ul)
- size = 0x8000ul - base;
- }
- lmb_add(base, size);
+ size = lmb_size;
+
+ /*
+* Append 'n' to 'linux,usable-memory' to get special
+* properties passed in by tools like kexec-tools. Relevant
+* only if this is a kexec/kdump kernel.
+*/
+ sprintf(buf, linux,usable-memory%d, (int)n);
+ usm = of_get_flat_dt_prop(node, buf, l);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (l 2)/(dt_root_addr_cells
+ + dt_root_size_cells);
+ do {
+ if (usm != NULL) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+usm);
+ if (size == 0)
+ break;
+ }
+ if (iommu_is_off)
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+
+ lmb_add(base, size);
+ } while (--ranges);
}
lmb_dump_all();
return 0;
diff -Naurp powerpc-orig/arch/powerpc/mm/numa.c powerpc/arch/powerpc/mm/numa.c
--- powerpc-orig/arch/powerpc/mm/numa.c 2008-07-22 14:11:53.0 +0530
+++ powerpc/arch/powerpc/mm/numa.c 2008-07-22 14:12:17.0 +0530
@@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm;
- unsigned int n, rc;
- unsigned long lmb_size, size;
+ const u32 *dm, *usm;
+ unsigned int n, rc, len, ranges;
+ unsigned long lmb_size, size, sz;
int nid;
struct assoc_arrays aa;
+ char buf[32];
+ u64 base;
n = of_get_drconf_memory(memory, dm);
if (!n)
@@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
nid = of_drconf_to_nid_single(drmem, aa);
- fake_numa_create_new_node(
- ((drmem.base_addr + lmb_size) PAGE_SHIFT),
- nid);
-
- node_set_online(nid);
-
- size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
- if (!size)
- continue;
+ /*
+* Append 'n' to 'linux,usable-memory' to get special
+* properties passed in by tools like kexec-tools. Relevant
+* only if this is a kexec/kdump kernel.
+*/
+ sprintf(buf, linux,usable-memory%d, (int)n);
+ usm = of_get_property(memory, buf, len);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (len 2) /
+(n_mem_addr_cells + n_mem_size_cells);
+
+ base = drmem.base_addr;
+ size = lmb_size;
+ do {
+
Re: radeonfb, dedicate memory to something else
Michel Dänzer wrote: On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote: or other graphics drivers can be told please only use the first 32MB and then either manually or automatically, map the rest as ramdisk. You can limit the amount of video RAM used by X using the VideoRam directive in xorg.conf(5). Ah okay. So now.. how do we do this for framebuffers? Is it safe to poke around in radeon_identify_vram and maybe supply a kernel argument videomem=32M and let it check, if it's bigger, then limit it, and if not, keep the old size in rinfo-video_ram? Can/could this be moved to all relevant framebuffer drivers? GART doesn't have anything to do with this. I suspect he was thinking of the PCI BARs not covering all video RAM. That's certainly not the case here. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
On Tue, 2008-07-22 at 14:31 +0530, Chandru wrote:
Scan for linux,usable-memory properties in case of dynamic reconfiguration
memory . Support for kexec/kdump.
Signed-off-by: Chandru Siddalingappa [EMAIL PROTECTED]
---
Patch applies on powerpc tree. Patch was reviewed by Nathan Fontenot, Stephen
Rothwell, Michael Neuling.
Any reason why there's no acks there then ? I don't have an objection to
the patch per-se and I was planning to review it this week too, but if
you had positive reviews and you addressed whatever comments the people
had, there should be Acked-by: lines in your patch (ie, don't invent
them, only put them there if you actually got that from the reviewers).
Cheers,
Ben.
arch/powerpc/kernel/prom.c | 40 +++--
arch/powerpc/mm/numa.c | 48 ---
2 files changed, 65 insertions(+), 23 deletions(-)
diff -Naurp powerpc-orig/arch/powerpc/kernel/prom.c
powerpc/arch/powerpc/kernel/prom.c
--- powerpc-orig/arch/powerpc/kernel/prom.c 2008-07-22 14:11:53.0
+0530
+++ powerpc/arch/powerpc/kernel/prom.c2008-07-22 14:12:17.0
+0530
@@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *usm;
+ unsigned long l, n, flags, ranges;
u64 base, size, lmb_size;
+ char buf[32];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
@@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
or if the block is not assigned to this partition (0x8) */
if ((flags 0x80) || !(flags 0x8))
continue;
- size = lmb_size;
- if (iommu_is_off) {
+ if (iommu_is_off)
if (base = 0x8000ul)
continue;
- if ((base + size) 0x8000ul)
- size = 0x8000ul - base;
- }
- lmb_add(base, size);
+ size = lmb_size;
+
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+ sprintf(buf, linux,usable-memory%d, (int)n);
+ usm = of_get_flat_dt_prop(node, buf, l);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (l 2)/(dt_root_addr_cells
+ + dt_root_size_cells);
+ do {
+ if (usm != NULL) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+ usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+ usm);
+ if (size == 0)
+ break;
+ }
+ if (iommu_is_off)
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+
+ lmb_add(base, size);
+ } while (--ranges);
}
lmb_dump_all();
return 0;
diff -Naurp powerpc-orig/arch/powerpc/mm/numa.c powerpc/arch/powerpc/mm/numa.c
--- powerpc-orig/arch/powerpc/mm/numa.c 2008-07-22 14:11:53.0
+0530
+++ powerpc/arch/powerpc/mm/numa.c2008-07-22 14:12:17.0 +0530
@@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm;
- unsigned int n, rc;
- unsigned long lmb_size, size;
+ const u32 *dm, *usm;
+ unsigned int n, rc, len, ranges;
+ unsigned long lmb_size, size, sz;
int nid;
struct assoc_arrays aa;
+ char buf[32];
+ u64 base;
n = of_get_drconf_memory(memory, dm);
if (!n)
@@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
nid = of_drconf_to_nid_single(drmem, aa);
- fake_numa_create_new_node(
- ((drmem.base_addr + lmb_size) PAGE_SHIFT),
-nid);
-
- node_set_online(nid);
-
- size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
- if (!size)
- continue;
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+
Re: [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
Chandru writes: Scan for linux,usable-memory properties in case of dynamic reconfiguration memory . Support for kexec/kdump. Signed-off-by: Chandru Siddalingappa [EMAIL PROTECTED] Could we *please* have a more comprehensive patch description that that? Something which will help people coming along in two (or five or ten) years time to understand what problem exists in the code, how this patch solves it, and why this approach was chosen over any alternative approaches? Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote: Here is the latest series for adding MPC5200 I2S and TI AIC26 codec support to ALSA SoC. I believe all the comments are addressed and I hope that this series is now ready to be merged. I would really like to see these ones land in 2.6.27. That might be a bit of a push given how far into the merge window we are and Takashi's holiday this week, though as they are new drivers things could be a bit more relaxed. Takashi, I'll queue these (and other ASoC patches) for submission in bulk once you return. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Tue, Jul 22, 2008 at 12:53:53AM -0600, Grant Likely wrote: This is most likely temporary glue code to work around limitations in the ASoC v1 framework. When v2 is merged, most of this driver will need to be reworked. Whatever is needed in v2 can probably have the client registration functions integrated into the core registration functions. Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 7/9] azfs: initial submit of azfs, a non-buffered filesystem
On Tue, Jul 15, 2008 at 09:51:46PM +0200, [EMAIL PROTECTED] wrote:
From: Maxim Shchetynin [EMAIL PROTECTED]
AZFS is a file system which keeps all files on memory mapped random
access storage. It was designed to work on the axonram device driver
for IBM QS2x blade servers, but can operate on any block device
that exports a direct_access method.
I don't thinks it's quite ready yet. I've had another look through the
code and here's some issues I came up with:
- first thing is that it's not sparse clean, which is a bit of a red
flag. The __iomem and __user annotations are there for a reason.
- then even with annotations we still have the issue of
copy_{from,to}_user into mmio regions. According to benh that's
still an open issue, but it at least needs very good explanations in
comments.
- the aio_read and aio_write methods don't handle actually vectored
writes. They need to iterate over all iovecs. Or just implement
plain read/write given that it's not actually asynchronous.
- the persistent superblock hack needs to go away. Just clean up
everything in -put_super. If we want a fully persistant fs
we should just be using ext2 + xip
- azfs_open looks very fishy. there's never a need to do seeks
inside open. if O_APPEND is set the VFS makes sure the read and
write methods get the right ppos pointer passed.
And truncation is done by the VFS for O_TRUNC opens through
-setattr
- azfs_znode should not have a size field of it's own, but the
filesystem should only use the inode one
- the lists and inode_init_once should be called from the slab
constructor as in other filesystems
- I don't think there is any point of having a slab cache
for the azfs_block structures
- disk-driverfs_dev is not writeable to the filesystem, but for
driver use. The information azfs stores in there is not used
anyway, so it could easily be removed.
- lots of duplicated field in azfs_super where the superblock
ones should be used:
media_size - sb-s_maxbytes
sector_size - not needed at all
blkdev - sb-s_bdev
root- sb-s_root
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox [EMAIL PROTECTED] wrote: [PATCH] Make u64 long long on all architectures It is currently awkward to print a u64 type. Some architectures use unsigned long while others use unsigned long long. Since unsigned long long is 64-bit for all existing Linux architectures, change those that use long to use long long. Note that this applies only within the kernel. If u64 is being used in a C++ method definition, the symbol mangling would change. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h index 2af9b75..32f07bd 100644 --- a/include/asm-generic/int-l64.h +++ b/include/asm-generic/int-l64.h @@ -23,8 +23,13 @@ typedef unsigned short __u16; typedef __signed__ int __s32; typedef unsigned int __u32; +#ifdef __KERNEL__ +typedef __signed__ long long __s64; +typedef unsigned long long __u64; +#else typedef __signed__ long __s64; typedef unsigned long __u64; +#endif #endif /* __ASSEMBLY__ */ This is (IMO) a desirable change and will prevent a heck of a lot of goofing around, and will permit a lot of prior goofing around to be removed. But I bet there are lots of instalces of printk(%l, some_u64) down in arch code where the type of u64 _is_ known which will now spew warnings. Oh well. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote: Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] There's a few issues that were raised on the previous review cycle that still need to be addressed but they should be fixable in incremental patches (and easier to review that way): +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd) + spin_lock_irqsave(psc_i2s-lock, flags); + /* first make sure it is low */ + while ((in_8(regs-ipcr_acr.ipcr) 0x80) != 0) + ; + /* then wait for the transition to high */ + while ((in_8(regs-ipcr_acr.ipcr) 0x80) == 0) + ; These loops should really have some sort of time limit on them, otherwise they'll lock hard if the expected events don't happen. Given that in slave mode they're synchronising with an externally generated clock this is something that might happen in practice and should produce better diagnostics. + default: + dev_dbg(psc_i2s-dev, invalid command\n); + return -EINVAL; + } I'd really expect to see the other possible triggers handled, even if the appropriate action is to silently ignore them, rather than having them generate an error message. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Tue, Jul 22, 2008 at 12:54:03AM -0600, Grant Likely wrote:
Signed-off-by: Grant Likely [EMAIL PROTECTED]
Signed-off-by: Mark Brown [EMAIL PROTECTED]
with the same comments about outstanding issues as applied to the CPU
side.
+static int aic26_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ switch (params_rate(params)) {
+ case 8000: fsref = 48000; divisor = AIC26_DIV_6; break;
+ /* Configure PLL */
+ pval = 1;
+ jval = (fsref == 44100) ? 7 : 8;
+ dval = (fsref == 44100) ? 5264 : 1920;
Without having looked at the chip datasheet these parameters probably
all need to depend on the input clock rate and the PLL configuration
should be done in a set_pll() rather than here.
+#if defined(CONFIG_SND_SOC_OF_SIMPLE)
+ /* Tell the of_soc helper about this codec */
+ of_snd_soc_register_codec(aic26_soc_codec_dev, aic26, aic26_dai,
+ spi-dev.archdata.of_node);
+#endif
This won't work if the OF_SIMPLE stuff is a module. There's also a
checkpatch issue which I'll fix up.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
On Tue, 2008-07-22 at 03:05 -0700, Andrew Morton wrote: On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox [EMAIL PROTECTED] wrote: [PATCH] Make u64 long long on all architectures It is currently awkward to print a u64 type. Some architectures use unsigned long while others use unsigned long long. Since unsigned long long is 64-bit for all existing Linux architectures, change those that use long to use long long. Note that this applies only within the kernel. If u64 is being used in a C++ method definition, the symbol mangling would change. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h index 2af9b75..32f07bd 100644 --- a/include/asm-generic/int-l64.h +++ b/include/asm-generic/int-l64.h @@ -23,8 +23,13 @@ typedef unsigned short __u16; typedef __signed__ int __s32; typedef unsigned int __u32; +#ifdef __KERNEL__ +typedef __signed__ long long __s64; +typedef unsigned long long __u64; +#else typedef __signed__ long __s64; typedef unsigned long __u64; +#endif #endif /* __ASSEMBLY__ */ This is (IMO) a desirable change and will prevent a heck of a lot of goofing around, and will permit a lot of prior goofing around to be removed. But I bet there are lots of instalces of printk(%l, some_u64) down in arch code where the type of u64 _is_ known which will now spew warnings. Oh well. As a rough estimate: concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs grep %l | grep -v %ll | wc -l 635 Someone's gonna get a lot of git points for fixing all those. Might keep the speeling fix crowd busy for a while. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Calling the kernel from a mini-bootloader
Thank you Milton for the detailed explanation. It'll take me quite a while to digest it. As a follow up to my previous messages, I now have a working kernel and a working bootloader... but not when they are both together. Case in point: - load zImage.elf to DRAM 0x40 with JTAG debugger. Run it. It runs fine. - Load Bootloader.elf to BRAM 0x with JTAG debugger. Run it. It runs fine (but it doesn't do much yet). - Now load both of the previous ones, and have the bootloader perform a jump to kernel: typedef void tFunc(void); ((tFunc *)0x40)(); The kernel seems to start: loaded at: 0040 004EA19C board data at: 004E8120 004E819C relocated to: 0040405C 004040D8 zimage at: 00404E48 004E7A7E avail ram: 004EB000 0800 Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp Uncompressing Linux...done. Now booting the kernel But then it hangs for exactly 3 minutes, nothing on the serial port, before the bootloader restarts. Why should the behavior be different whether it's started from the debugger or from my bootloader ? -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
On Tue, 22 Jul 2008 20:36:35 +1000 Michael Ellerman [EMAIL PROTECTED] wrote: On Tue, 2008-07-22 at 03:05 -0700, Andrew Morton wrote: On Fri, 4 Jul 2008 20:03:51 -0600 Matthew Wilcox [EMAIL PROTECTED] wrote: [PATCH] Make u64 long long on all architectures It is currently awkward to print a u64 type. Some architectures use unsigned long while others use unsigned long long. Since unsigned long long is 64-bit for all existing Linux architectures, change those that use long to use long long. Note that this applies only within the kernel. If u64 is being used in a C++ method definition, the symbol mangling would change. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h index 2af9b75..32f07bd 100644 --- a/include/asm-generic/int-l64.h +++ b/include/asm-generic/int-l64.h @@ -23,8 +23,13 @@ typedef unsigned short __u16; typedef __signed__ int __s32; typedef unsigned int __u32; +#ifdef __KERNEL__ +typedef __signed__ long long __s64; +typedef unsigned long long __u64; +#else typedef __signed__ long __s64; typedef unsigned long __u64; +#endif #endif /* __ASSEMBLY__ */ This is (IMO) a desirable change and will prevent a heck of a lot of goofing around, and will permit a lot of prior goofing around to be removed. But I bet there are lots of instalces of printk(%l, some_u64) down in arch code where the type of u64 _is_ known which will now spew warnings. Oh well. As a rough estimate: concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs grep %l | grep -v %ll | wc -l 635 lolz. If yesterdays-linux-next on todays-mainline wasn't such a hilarious trainwreck I'd test your grepping. I guess that could be done on mainline too. Someone's gonna get a lot of git points for fixing all those. Might keep the speeling fix crowd busy for a while. I'm not sure I have the energy for this. But we really should do it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
What is your problem with the linux-next tree. The problem was discovered and reported when I first merged the ttydev tree into linux-next on July 1. The fixes were in linux-next on July 2. Yes .. and ? The clashes kept happening despite that when I was doing the merges (and going on holiday for a week and trying to sort it out with limited time and internet access) Sorry I don't follow your line of discussion at all here ? just going to break the tree again and mean I have to run another set of tests and regressions. Please give what until tomorrow? it - the situation. The patches have all gone to Linus. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
This is (IMO) a desirable change and will prevent a heck of a lot of goofing around, and will permit a lot of prior goofing around to be removed. But I bet there are lots of instalces of printk(%l, some_u64) down in arch code where the type of u64 _is_ known which will now spew warnings. Well, I'm about to call a big warning fixing day on the powerpc list, I saw a few today when building a couple of configs and that hurts my eyes so we may as well fold that in :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote: Here is the latest series for adding MPC5200 I2S and TI AIC26 codec support to ALSA SoC. I believe all the comments are addressed and I hope that this series is now ready to be merged. I would really like to see these ones land in 2.6.27. I added the changes in the following fairly trivial patch series to these to allow tlv320aic26 build cleanly on my ARM platforms. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] ASoC: Staticise keyclick dev_attr in tlv320aic26
Signed-off-by: Mark Brown [EMAIL PROTECTED] --- sound/soc/codecs/tlv320aic26.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c index 73b7027..bed8a9e 100644 --- a/sound/soc/codecs/tlv320aic26.c +++ b/sound/soc/codecs/tlv320aic26.c @@ -418,7 +418,7 @@ static ssize_t aic26_keyclick_set(struct device *dev, return count; } -DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set); +static DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set); /* - * SPI device portion of driver: probe and release routines and SPI -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] ASoC: Export DAI and codec for TLV320AIC26
This fixes sparse warnings and allows non-OpenFirmware systems to attempt
to bind to the device.
Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
sound/soc/codecs/tlv320aic26.c |1 +
sound/soc/codecs/tlv320aic26.h |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 4621fda..73b7027 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -383,6 +383,7 @@ struct snd_soc_codec_device aic26_soc_codec_dev = {
.probe = aic26_probe,
.remove = aic26_remove,
};
+EXPORT_SYMBOL_GPL(aic26_soc_codec_dev);
/* -
* SPI device portion of driver: sysfs files for debugging
diff --git a/sound/soc/codecs/tlv320aic26.h b/sound/soc/codecs/tlv320aic26.h
index 62b1f22..786ba16 100644
--- a/sound/soc/codecs/tlv320aic26.h
+++ b/sound/soc/codecs/tlv320aic26.h
@@ -90,4 +90,7 @@ enum aic26_wlen {
AIC26_WLEN_32 = 3 10,
};
+extern struct snd_soc_dai aic26_dai;
+extern struct snd_soc_codec_device aic26_soc_codec_dev;
+
#endif /* _TLV320AIC16_H_ */
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] ASoC: Make OpenFirmware helper include file conditional
The OpenFirmware API headers don't build on all platforms so ensure that they are not included unless they are being used. Signed-off-by: Mark Brown [EMAIL PROTECTED] --- include/sound/soc-of-simple.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h index 696fc51..a064e19 100644 --- a/include/sound/soc-of-simple.h +++ b/include/sound/soc-of-simple.h @@ -7,6 +7,8 @@ #ifndef _INCLUDE_SOC_OF_H_ #define _INCLUDE_SOC_OF_H_ +#if defined(CONFIG_SND_SOC_OF_SIMPLE) || defined(CONFIG_SND_SOC_OF_SIMPLE_MODULE) + #include linux/of.h #include sound/soc.h @@ -18,4 +20,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform, struct device_node *node, struct snd_soc_dai *cpu_dai); +#endif + #endif /* _INCLUDE_SOC_OF_H_ */ -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make u64 long long on all architectures (was: the printk problem)
On Tue, 2008-07-22 at 20:36 +1000, Michael Ellerman wrote: concordia powerpc(master) $ find arch/powerpc/ ! -name '*32.*' | xargs grep %l | grep -v %ll | wc -l 635 Someone's gonna get a lot of git points for fixing all those. Might keep the speeling fix crowd busy for a But a bunch of those might actually be real longs, not u64's ... Easier to do the change and build something like ppc6xx_defconfig to get a better approximation. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull from powerpc.git merge branch
On Jul 22, 2008, at 2:32 AM, Benjamin Herrenschmidt wrote: Hi Linus ! Here's the second batch of powerpc updates. I should have a last one before the end of the merge window for things that are stealing dealing with conflicts or dependencies but we are getting there. So please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Hopefully this one shouldn't whack the main Makefile :-) Note a couple of fbdev updates. One is an offb change by me, this is a powerpc specific driver so that shouldn't affect anybody else, and one is the ps3 specific fbdev by Geoff, so again, there should be no collateral damage. Some drivers/net changes to freescale specific drivers are coming from Kumar's tree. Kumar, I merged them, however, shouldn't we have Jeff's ack on these things or is it ok as long as those are arch specific drivers and the changes boring ? they had jeff's ack. I just didn't update the commits, my bad and I'll fix that in the future. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/16 v3] powerpc: iommu enablement for CMO
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
Robert Jennings writes:
To support Cooperative Memory Overcommitment (CMO), we need to check
for failure from some of the tce hcalls.
This patch runs into context mismatches because of changes made by
Michael Ellerman's patch Fix sparse warnings in
arch/powerpc/platforms/pseries (now in Linus' tree), which changed
code like
if (condition)
return function_returning_void(args);
into
if (condition) {
function_returning_void(args);
return;
}
which will cause problems for your patch. Please check if any of
these changes need to be undone again.
I do need to revert those changes, the return values will no longer be
void. I'll get those tested and posted. Thanks.
--Rob Jennings
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/16 v3] [v2] powerpc: iommu enablement for CMO
* Paul Mackerras ([EMAIL PROTECTED]) wrote: Robert Jennings writes: Minor change to add a call to align the return from the device's get_desired_dma() function with IOMMU_PAGE_ALIGN(). Also removed a comment referring to a non-existent structure member. Anyway, my first comment is that the first paragraph of the description (Minor change to ...) is not appropriate for the git tree and will have to be edited before the patch is applied. If the extra changes are worth describing, describe them (in stand-alone fashion) in the description; otherwise put things like this after the line of three dashes, which terminates the description. I'll correct this with the other changes that need to be made. +static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist, +int nelems, enum dma_data_direction direction) This function, and the related unmap_sg, map_single and unmap_single functions, now take an extra struct dma_attrs *attrs argument since Mark Nelson's patch powerpc/dma: implement new dma_*map*_attrs() interfaces went in (and it's now in Linus' tree). You need to roll something like the patch below in with the 11/16 patch. I'll repost with updates to add the dma_attrs field. --Rob ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On 7/22/08, Mark Brown [EMAIL PROTECTED] wrote:
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote:
Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
support to ALSA SoC. I believe all the comments are addressed and I
hope that this series is now ready to be merged. I would really like
to see these ones land in 2.6.27.
That might be a bit of a push given how far into the merge window we
are and Takashi's holiday this week, though as they are new drivers
things could be a bit more relaxed.
These drivers are going to get hit with immediate patches. The DMA is
not broken out so that AC97 support can be fixed for the Efika.
I haven't touched these up for the driver that was just posted.
From: Jon Smirl [EMAIL PROTECTED]
---
include/sound/soc-of.h |2 +
sound/soc/fsl/mpc5200_psc_i2s.c | 93 ---
sound/soc/fsl/mpc5200_psc_i2s.h | 13 +
sound/soc/soc-of.c | 26 +--
4 files changed, 112 insertions(+), 22 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
diff --git a/include/sound/soc-of.h b/include/sound/soc-of.h
index a963032..15f0b8d 100644
--- a/include/sound/soc-of.h
+++ b/include/sound/soc-of.h
@@ -17,5 +17,7 @@ int of_snd_soc_register_codec(struct
snd_soc_codec_device *codec_dev,
int of_snd_soc_register_platform(struct snd_soc_platform *platform,
struct device_node *node,
struct snd_soc_cpu_dai *cpu_dai);
+
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops);
#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index 81d0933..a34961a 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -5,6 +5,8 @@
* Copyright (C) 2008 Secret Lab Technologies Ltd.
*/
+#define DEBUG
+
#include linux/init.h
#include linux/module.h
#include linux/interrupt.h
@@ -23,8 +25,12 @@
#include sysdev/bestcomm/bestcomm.h
#include sysdev/bestcomm/gen_bd.h
+#include asm/time.h
+#include asm/mpc52xx.h
#include asm/mpc52xx_psc.h
+#include mpc5200_psc_i2s.h
+
MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Freescale MPC5200 PSC in I2S mode ASoC Driver);
MODULE_LICENSE(GPL);
@@ -90,8 +96,10 @@ struct psc_i2s {
struct mpc52xx_psc_fifo __iomem *fifo_regs;
unsigned int irq;
struct device *dev;
+ u32 sicr;
struct snd_soc_cpu_dai dai;
spinlock_t lock;
+ uint sysclk;
/* per-stream data */
struct psc_i2s_stream playback_stream;
@@ -210,9 +218,7 @@ static int psc_i2s_startup(struct
snd_pcm_substream *substream)
out_8(regs-command, 4 4); /* reset error */
/* Default to CODEC8 mode */
- out_be32(regs-sicr,
-MPC52xx_PSC_SICR_DTS1 | MPC52xx_PSC_SICR_I2S |
-MPC52xx_PSC_SICR_CLKPOL | MPC52xx_PSC_SICR_SIM_CODEC_8);
+ out_be32(regs-sicr, psc_i2s-sicr | MPC52xx_PSC_SICR_SIM_CODEC_8);
/* First write: RxRdy (FIFO Alarm) generates receive FIFO interrupt */
/* Second write to mode: register Normal mode for non loopback */
@@ -249,7 +255,7 @@ static int psc_i2s_hw_params(struct
snd_pcm_substream *substream,
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct psc_i2s *psc_i2s = rtd-dai-cpu_dai-private_data;
- u32 sicr;
+ u32 sicr, bits, framesync, bitclk, value;
dev_dbg(psc_i2s-dev, %s(substream=%p) p_size=%i p_bytes=%i
periods=%i buffer_size=%i buffer_bytes=%i\n,
@@ -257,26 +263,46 @@ static int psc_i2s_hw_params(struct
snd_pcm_substream *substream,
params_period_bytes(params), params_periods(params),
params_buffer_size(params), params_buffer_bytes(params));
- sicr = MPC52xx_PSC_SICR_DTS1 |
- MPC52xx_PSC_SICR_I2S | MPC52xx_PSC_SICR_CLKPOL;
+ sicr = psc_i2s-sicr;
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S8:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_8;
+ bits = 8;
break;
case SNDRV_PCM_FORMAT_S16_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_16;
+ bits = 16;
break;
case SNDRV_PCM_FORMAT_S24_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_24;
+ bits = 24;
break;
case SNDRV_PCM_FORMAT_S32_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_32;
+ bits = 32;
break;
default:
dev_dbg(psc_i2s-dev, invalid format\n);
return -EINVAL;
}
out_be32(psc_i2s-psc_regs-sicr, sicr);
+
+ if (psc_i2s-sysclk) {
+ framesync = bits * 2;
+ bitclk = (psc_i2s-sysclk) / (params_rate(params) * framesync);
+
+
latest tree build failure -- cpm uart gpio
can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' make[4]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1 drivers/serial/cpm_uart/cpm_uart_core.c:212: error: 'struct uart_info' has no member named 'tty' make[4]: *** [drivers/serial/cpm_uart/cpm_uart_core.o] Error 1 make[3]: *** [drivers/serial/cpm_uart] Error 2 make[3]: *** [drivers/net/fs_enet] Error 2 make[2]: *** [drivers/net] Error 2 make[2]: *** [drivers/serial] Error 2 make[1]: *** [drivers] Error 2 make: *** [sub-make] Error 2 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: latest tree build failure -- cpm uart gpio
On Tue, 22 Jul 2008 08:54:16 -0500 Kumar Gala [EMAIL PROTECTED] wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' These are not make[4]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1 drivers/serial/cpm_uart/cpm_uart_core.c:212: error: 'struct uart_info' has no member named 'tty' That one is and hasn't been addressed so I wil do it right now. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On Tue, Jul 22, 2008 at 09:38:11AM -0400, Jon Smirl wrote: These drivers are going to get hit with immediate patches. The DMA is not broken out so that AC97 support can be fixed for the Efika. Further updates shouldn't present a problem - if anything, it should be easier easier to review incremental patches. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: radeonfb, dedicate memory to something else
On 7/22/08, Matt Sealey [EMAIL PROTECTED] wrote: Michel Dänzer wrote: On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote: or other graphics drivers can be told please only use the first 32MB and then either manually or automatically, map the rest as ramdisk. You can limit the amount of video RAM used by X using the VideoRam directive in xorg.conf(5). Is it safe to poke around in radeon_identify_vram and maybe supply a kernel argument videomem=32M and let it check, if it's bigger, then limit it, and if not, keep the old size in rinfo-video_ram? Can/could this be moved to all relevant framebuffer drivers? GART doesn't have anything to do with this. I suspect he was thinking of the PCI BARs not covering all video RAM. That's certainly not the case here. Yes, I'm forgetting how graphics work. If you can map all of VRAM into the PCI address space then you don't have to worry about sharing the window with X. Ah okay. So now.. how do we do this for framebuffers? My memory is suspect, but first you would need to make sure all of VRAM is mapped. Then there is a value in fb that says how much of the VRAM it is using. Anything above the max is fair game if X isn't running. Note that the amount of VRAM in use by fbdev is a function of which display mode it is in. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On 7/22/08, Mark Brown [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 09:38:11AM -0400, Jon Smirl wrote: These drivers are going to get hit with immediate patches. The DMA is not broken out so that AC97 support can be fixed for the Efika. Further updates shouldn't present a problem - if anything, it should be easier easier to review incremental patches. I'm just going to ignore 2.6.27 and wait for 2.6.28. This driver only partially implement i2s support and assumes external clocking. There's no way to add a ASOC machine driver. It's not a general purpose driver. Adding the rest of the features probably means device tree changes. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: latest tree build failure -- cpm uart gpio
On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' I think this patch should help: [OF] of_gpio: should use new linux/gpio.h header http://patchwork.ozlabs.org/linuxppc/patch?id=18750 David, can you please Ack it? See Benjamin's mail: http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: going to OLS?
So, There doesn't seem to be an official plan, so I'm making one Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this evening. Anybody that wants to join us welcome. Cheers, Becky On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote: On Mon, 21 Jul 2008 14:15:53 -0600 Grant Likely [EMAIL PROTECTED] wrote: BTW, if anyone else wants to receive the contact phone list, then send me your phone number ASAP. I'll be sending it out this evening. My home phone number is 613-728-1680. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Mikrotik RouterBoard 333
Jerry Van Baren wrote: Scott Wood wrote: On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote: I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than using a bootwrapper for obvious reasons. The u-boot implementation takes the blob as a boot parameter and passes it along to the kernel after doing appropriate (optional) fixups. And if those fixups expect a malformed device tree? Oops, very bad choice of terms on my part. :-( The fixups I referred to are mostly fill in the blank things like setting the various clocks, MAC information, PCI information, etc. to the correct values based on hardware probing or a priori knowledge. U-boot does not (should not / will not!) fix broken device trees. A broken tree w/ the u-boot methodology is fixed by loading a corrected one, not requiring a full rebuild and reload of the firmware. No, I understand what you meant -- I mean cases where u-boot expects the blanks to be somewhere other than where they are. This has happened in the past, with mac-address v. local-mac-address, finding the SOC node, duplicate /chosen nodes, etc. If all else fails, u-boot is GPLed and the user is able to get the source and fix it (well, at least for 3 years after purchasing the hardware). Regardless of that, if all else fails, one can ignore the firmware's tree and use a bootwrapper-provided tree. There are advantages and disadvantages to u-boot and boot-wrapper methods. There are nothing but disadvantages to having the blob physically a part of the firmware (with a double whammy if the firmware source is not readily available). The advantage is that the firmware will be kept in sync with the tree it's trying to patch. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
Jon Smirl wrote: I'm just going to ignore 2.6.27 and wait for 2.6.28. 2.6.28 might have ASoC V2, or at least portions of it. You might want to just port your driver to ASoC V2 like I did and not worry about it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They are not used anymore and can be safely
removed.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
include/linux/fs_enet_pd.h|4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..decc4b5 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
struct fs_mii_bit mdio_dir;
struct fs_mii_bit mdio_dat;
struct fs_mii_bit mdc_dat;
- int mdio_port; /* port bit for MDIO */
- int mdio_bit;
- int mdc_port; /* port bit for MDC */
- int mdc_bit;
int delay; /* delay in us */
int irq[32];/* irqs per phy's */
};
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
Hi Alan, On Tue, 22 Jul 2008 11:44:36 +0100 Alan Cox [EMAIL PROTECTED] wrote: What is your problem with the linux-next tree. The problem was discovered and reported when I first merged the ttydev tree into linux-next on July 1. The fixes were in linux-next on July 2. Yes .. and ? The clashes kept happening despite that when I was doing the merges (and going on holiday for a week and trying to sort it out with limited time and internet access) Sorry I don't follow your line of discussion at all here ? I interpreted your So much for the linux-next tree as saying well, that has been no help. I am sorry if I got that wrong. But my point above is that you had a fix for the current breakage in Linus' tree a couple of weeks before you sent the patches to Linus that broke the powerpc build (i.e. linux-next did its job) and yet you didn't combine the fix with the original patch or send the fix with the original patch. So we end up with a powerpc tree that won't build in the middle of the merge window while more powerpc patches are trying to be tested ... I understand that this could easily happen because of forgetfulness, tiredness or accident. More care was needed. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpIu1UeHtd4t.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cpm2: Rework baud rate generators configuration to support external clocks.
The CPM2 BRG setup functions cpm_setbrg and cpm2_fastbrg don't support external
clocks. This patch adds a new exported __cpm2_setbrg function that takes the
clock rate and clock source as extra parameters, and moves cpm_setbrg and
cpm2_fastbrg to include/asm-powerpc/cpm2.h where they become inline wrappers
around __cpm2_setbrg.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
arch/powerpc/sysdev/cpm2.c | 34 +++
include/asm-powerpc/cpm2.h | 46 +++
2 files changed, 37 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 9311778..f1c3395 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -115,16 +115,10 @@ EXPORT_SYMBOL(cpm_command);
* Baud rate clocks are zero-based in the driver code (as that maps
* to port numbers). Documentation uses 1-based numbering.
*/
-#define BRG_INT_CLK(get_brgfreq())
-#define BRG_UART_CLK (BRG_INT_CLK/16)
-
-/* This function is used by UARTS, or anything else that uses a 16x
- * oversampled clock.
- */
-void
-cpm_setbrg(uint brg, uint rate)
+void __cpm2_setbrg(uint brg, uint rate, uint clk, int div16, int src)
{
u32 __iomem *bp;
+ u32 val;
/* This is good enough to get SMCs running.
*/
@@ -135,34 +129,14 @@ cpm_setbrg(uint brg, uint rate)
brg -= 4;
}
bp += brg;
- out_be32(bp, (((BRG_UART_CLK / rate) - 1) 1) | CPM_BRG_EN);
-
- cpm2_unmap(bp);
-}
-
-/* This function is used to set high speed synchronous baud rate
- * clocks.
- */
-void
-cpm2_fastbrg(uint brg, uint rate, int div16)
-{
- u32 __iomem *bp;
- u32 val;
-
- if (brg 4) {
- bp = cpm2_map_size(im_brgc1, 16);
- } else {
- bp = cpm2_map_size(im_brgc5, 16);
- brg -= 4;
- }
- bp += brg;
- val = ((BRG_INT_CLK / rate) 1) | CPM_BRG_EN;
+ val = (((clk / rate) - 1) 1) | CPM_BRG_EN | src;
if (div16)
val |= CPM_BRG_DIV16;
out_be32(bp, val);
cpm2_unmap(bp);
}
+EXPORT_SYMBOL(__cpm2_setbrg);
int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode)
{
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index 4c85ed9..dab9949 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -12,6 +12,7 @@
#include asm/immap_cpm2.h
#include asm/cpm.h
+#include sysdev/fsl_soc.h
#ifdef CONFIG_PPC_85xx
#define CPM_MAP_ADDR (get_immrbase() + 0x8)
@@ -119,10 +120,40 @@ extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(unsigned long offset);
#endif
-extern void cpm_setbrg(uint brg, uint rate);
-extern void cpm2_fastbrg(uint brg, uint rate, int div16);
extern void cpm2_reset(void);
+/* Baud rate generators.
+*/
+#define CPM_BRG_RST((uint)0x0002)
+#define CPM_BRG_EN ((uint)0x0001)
+#define CPM_BRG_EXTC_INT ((uint)0x)
+#define CPM_BRG_EXTC_CLK3_9((uint)0x4000)
+#define CPM_BRG_EXTC_CLK5_15 ((uint)0x8000)
+#define CPM_BRG_ATB((uint)0x2000)
+#define CPM_BRG_CD_MASK((uint)0x1ffe)
+#define CPM_BRG_DIV16 ((uint)0x0001)
+
+#define CPM2_BRG_INT_CLK (get_brgfreq())
+#define CPM2_BRG_UART_CLK (CPM2_BRG_INT_CLK/16)
+
+extern void __cpm2_setbrg(uint brg, uint rate, uint clk, int div16, int src);
+
+/* This function is used by UARTS, or anything else that uses a 16x
+ * oversampled clock.
+ */
+static inline void cpm_setbrg(uint brg, uint rate)
+{
+ __cpm2_setbrg(brg, rate, CPM2_BRG_UART_CLK, 0, CPM_BRG_EXTC_INT);
+}
+
+/* This function is used to set high speed synchronous baud rate
+ * clocks.
+ */
+static inline void cpm2_fastbrg(uint brg, uint rate, int div16)
+{
+ __cpm2_setbrg(brg, rate, CPM2_BRG_INT_CLK, div16, CPM_BRG_EXTC_INT);
+}
+
/* Function code bits, usually generic to devices.
*/
#define CPMFCR_GBL ((u_char)0x20) /* Set memory snooping */
@@ -221,17 +252,6 @@ typedef struct smc_uart {
#define SMCM_TX((unsigned char)0x02)
#define SMCM_RX((unsigned char)0x01)
-/* Baud rate generators.
-*/
-#define CPM_BRG_RST((uint)0x0002)
-#define CPM_BRG_EN ((uint)0x0001)
-#define CPM_BRG_EXTC_INT ((uint)0x)
-#define CPM_BRG_EXTC_CLK3_9((uint)0x4000)
-#define CPM_BRG_EXTC_CLK5_15 ((uint)0x8000)
-#define CPM_BRG_ATB((uint)0x2000)
-#define CPM_BRG_CD_MASK((uint)0x1ffe)
-#define CPM_BRG_DIV16 ((uint)0x0001)
-
/* SCCs.
*/
#define SCC_GSMRH_IRP ((uint)0x0004)
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: Calling the kernel from a mini-bootloader
Answering to myself to try and provide more background info:
As a follow up to my previous messages, I now have a working kernel and a
working bootloader... but not when they are both together.
Case in point:
- load zImage.elf to DRAM 0x40 with JTAG debugger. Run it. It runs
fine.
- Load Bootloader.elf to BRAM 0x with JTAG debugger. Run it. It
runs fine (but it doesn't do much yet).
- Now load both of the previous ones, and have the bootloader perform a
jump to kernel:
void main() {
typedef void tFunc(void);
((tFunc *)0x40)();
}
Now if the bootloader _only_ contains the above code, the kernel runs
perfectly.
Unfortunately I need to do some things in the bootloader: I use 3 GPIOs to
control a frontal set of LEDs, to get a card number and to load/unload a
serial flash memory. Those operations work. But here is the strange thing
that leads me to believe there are interrupt interferences.
If I just read from a GPIO before launching the kernel, it boots fine, with
a few NFS errors when mounting the rootnfs:
[4.360060] Freeing unused kernel memory: 76k init
[ 11.432269] nfs: server 192.168.1.185 not responding, still trying
[ 11.441186] nfs: server 192.168.1.185 OK
init started: BusyBox v1.10.1 (2008-04-24 12:26:38 CEST)
genepy login:
Now if I also write to a 2nd GPIO, I get a lot more NFS errors.
And if I also access the flash through the 3rd GPIO, the kernel hangs:
loaded at: 0040 004EA19C
board data at: 004E8120 004E819C
relocated to: 0040405C 004040D8
zimage at: 00404E48 004E7A7E
avail ram: 004EB000 0800
Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
Uncompressing Linux...done.
Now booting the kernel
But then it hangs for exactly 3 minutes, nothing on the serial port,
before the bootloader restarts.
Why should the behavior be different whether it's started from the
debugger or from my bootloader ?
Now I've defined my hardware project using interrupts on the GPIOs, which I
don't need and frankly they don't make sense for an output GPIO. I would
like to try to compile a kernel without GPIO interrupts, unfortunately the
compilation fails:
$ make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc-
[...]
CC arch/ppc/syslib/virtex_devices.o
arch/ppc/syslib/virtex_devices.c:535: error: 'XPAR_INTC_0_GPIO_0_VEC_ID'
undeclared here (not in a function)
Question breakdown:
- do I need interrupts for GPIOs ?
- how can I compile the ppc 2.6.25 kernel without them ?
- Why do I have problems running the kernel if the bootloader makes use of
the GPIOs ?
- does the bootloader need to perform some kind of special cleanup before
calling the kernel ?
Thanks a lot for shedding a light on those mysteries.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UIO not working on ppc405 onchip registers
On Tuesday 22 July 2008, [EMAIL PROTECTED] wrote: Hello Uwe, On Tuesday 22 July 2008, Uwe Kleine-König wrote: I don't know powerpc in general nor ppc405ep in detail but IIRC arm has problems if some memory is mapped twice. Might this be the problem here? Maybee, the emac0 (0xef600800) and emac1 (0xef600900) get mapped as well, because AFAIK I have to map a whole pagesize (0x1000). Same problem without emac module loaded. Did anybody tried to reproduce the problem? Regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
I interpreted your So much for the linux-next tree as saying well, that has been no help. I am sorry if I got that wrong. True it didn't help in the merge that much this time. I don't think that is a problem with the linux-next tree but one of the lack of tty maintainer and tty tree letting the confusion occur in the first place - plus a large quantity of first time around ineptness on my part. But my point above is that you had a fix for the current breakage in Linus' tree a couple of weeks before you sent the patches to Linus that broke the powerpc build (i.e. linux-next did its job) and yet you didn't combine the fix with the original patch or send the fix with the original patch. So we end up with a powerpc tree that won't build in the middle of the merge window while more powerpc patches are trying to be tested ... I understand that this could easily happen because of forgetfulness, tiredness or accident. I really expected to get the rest merged within an hour or two, but then it broke, then I was travelling and each time I got wireless access to resync the tree and work on it - it broke again and again and again. Next time I will bump the patch up the pile and get it out earlier when that occurs. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] serial: fix struct uart_info change fallout
Hi Alan, On Tue, 22 Jul 2008 16:59:29 +0100 Alan Cox [EMAIL PROTECTED] wrote: I really expected to get the rest merged within an hour or two, but then it broke, then I was travelling and each time I got wireless access to resync the tree and work on it - it broke again and again and again. Next time I will bump the patch up the pile and get it out earlier when that occurs. Excellent. Just asking: do you have an aversion for merging fixes back into patches? Not a problem, just so I know. Different people work differently. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpTFKSUCYNow.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/22/08, Grant Likely [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
Simple utility layer for creating ASoC machine instances based on data
in the OpenFirmware device tree. OF aware platform drivers and codec
drivers register themselves with this framework and the framework
automatically instantiates a machine driver. At the moment, the driver
is not very capable and it is expected to be extended as more features
are needed for specifying the configuration in the device tree.
This is most likely temporary glue code to work around limitations in
the ASoC v1 framework. When v2 is merged, most of this driver will
need to be reworked.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
include/sound/soc-of-simple.h | 21 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile|3 +
sound/soc/fsl/soc-of-simple.c | 171
+
4 files changed, 198 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
new file mode 100644
index 000..696fc51
--- /dev/null
+++ b/include/sound/soc-of-simple.h
@@ -0,0 +1,21 @@
+/*
+ * OF helpers for ALSA SoC
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#ifndef _INCLUDE_SOC_OF_H_
+#define _INCLUDE_SOC_OF_H_
+
+#include linux/of.h
+#include sound/soc.h
+
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_dai *dai,
+ struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+struct device_node *node,
+struct snd_soc_dai *cpu_dai);
+
This doesn't compile for me. Where is struct snd_soc_dai being defined?
It used to be
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_codec_dai *dai,
+ struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+struct device_node *node,
+struct snd_soc_cpu_dai *cpu_dai);
+#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3368ace..398f002 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,3 +1,6 @@
+config SND_SOC_OF_SIMPLE
+ tristate
+
config SND_SOC_MPC8610
bool ALSA SoC support for the MPC8610 SOC
depends on MPC8610_HPCD
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 62f680a..aa2100b 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -1,3 +1,6 @@
+# Simple machine driver that extracts configuration from the OF device tree
+obj-$(CONFIG_SND_SOC_OF_SIMPLE) += soc-of-simple.o
+
# MPC8610 HPCD Machine Support
obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
new file mode 100644
index 000..0382fda
--- /dev/null
+++ b/sound/soc/fsl/soc-of-simple.c
@@ -0,0 +1,171 @@
+/*
+ * OF helpers for ALSA SoC Layer
+ *
+ * Copyright (C) 2008, Secret Lab Technologies Ltd.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/of.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+#include sound/initval.h
+
+MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(ALSA SoC OpenFirmware bindings);
+
+static DEFINE_MUTEX(of_snd_soc_mutex);
+static LIST_HEAD(of_snd_soc_device_list);
+static int of_snd_soc_next_index;
+
+struct of_snd_soc_device {
+ int id;
+ struct list_head list;
+ struct snd_soc_device device;
+ struct snd_soc_machine machine;
+ struct snd_soc_dai_link dai_link;
+ struct platform_device *pdev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+};
+
+static struct snd_soc_ops of_snd_soc_ops = {
+};
+
+static struct of_snd_soc_device *
+of_snd_soc_get_device(struct device_node *codec_node)
+{
+ struct of_snd_soc_device *of_soc;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ if (of_soc-codec_node == codec_node)
+ return of_soc;
+ }
+
+ of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
+ if (!of_soc)
+ return NULL;
+
+ /* Initialize the structure and add it to the global
Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
All of the variables references through @got translated into relocation type R_PPC64_GOT16_DS entries. All these entries correspond to one of the above entries in the .got section. But none of the entries in .got section are relocated. If that last statement is really true, then that would be an absolute show-stopper, since you're not going to stop the compiler generating loads from the TOC to get addresses of things. However, I don't think it's true. I compiled up a kernel using --emit-relocs on the final link, and with readelf -e I can see a .rela.got section containing a bunch of R_PPC64_ADDR64 relocs for entries in the .got section. So the problem appears to be either just that you are ignoring R_PPC64_ADDR64 relocs, or else that your relocs.c program has a bug and isn't seeing the .rela.got section. I analysed this further. .rela.got does have lots of relocs in it, but _not_ for relocations create with @got in the assembler code. GCC never does this AFAICS, it explicitly creates a TOC entry and uses that. So, the workaround would be to manually create TOC entries in the LOAD_REG_ADDR code as well. I'll work on that, feel free to beat me to it of course. Now I have two options left: 1. Check for R_PPC64_GOT16_DS entries and check whether the contents addressed by r2+offset is relocated or not and apply relocation if its not. 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have already done. I was trying to point out that this can't possibly be a viable solution to the problem, because most of the TOC loads in the binary are generated by the C compiler, and only a few of them come from use of the LOAD_REG_ADDR macro in assembly code. binutils has a problem only with the @gotXXX relocations, where the _linker_ creates the GOT entry (it doesn't emit a reloc for -emit-relocs in that case). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Tue, Jul 22, 2008 at 12:38:30PM -0400, Jon Smirl wrote:
On 7/22/08, Grant Likely [EMAIL PROTECTED] wrote:
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+struct device_node *node,
+struct snd_soc_dai *cpu_dai);
+
This doesn't compile for me. Where is struct snd_soc_dai being defined?
It used to be
In ALSA and ASoC git struct snd_soc_{cpu,codec}_dai have been replaced
by a shared snd_soc_dai defined in soc.h as the previous two were.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
If you built this kernel yourself, you need to do it from a system with an up-to-date binutils (2.18) otherwise, it does this. Note to the linux-ppc guys; is there any changelog entry which reports this requirement somewhere? I didn't find one... That's because there is no such requirement. 2.18 is the latest version, so it's always wise to test with that in case you have some problems; but it wouldn't be nice if the kernel can be built with only one binutils major version. Please try my build patch for a similar problem, it went into BenH's tree today. Would be nice if it was the same problem; if not, send a proper, _detailed_ bug report here and I'll look into it. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
What about the mpc5200b?
+/* Match table for of_platform binding */
+static struct of_device_id psc_i2s_match[] __devinitdata = {
+ { .compatible = fsl,mpc5200-psc-i2s, },
+ {}
+};
+MODULE_DEVICE_TABLE(of, psc_i2s_match);
+
I'm just being grumpy because updating to linus/master made me fix
over a hundred merge conflicts, now I have to test everything again.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On Tue, Jul 22, 2008 at 10:52:20AM -0400, Jon Smirl wrote: I'm just going to ignore 2.6.27 and wait for 2.6.28. This driver only If you want to get changes in for 2.6.28 it's probably best to be working on them now - it's not clear if this driver will be merged for 2.6.27 at all and the sooner the stuff gets in the safer it is for 2.6.28 and the closer the code base will be to 2.6.26. It's up to you obviously but I think it may work best. partially implement i2s support and assumes external clocking. There's no way to add a ASOC machine driver. It's not a general purpose driver. Adding the rest of the features probably means device tree changes. of-soc is a machine driver - other machine drivers should be able to bind to the driver as normal (though I'd expect that users would want to add more configurablilty to the driver prior to using it). Or at least that was the usage I was expecting, anyway. Implementing only partial support for devices is pretty much normal when the driver isn't contributed by the vendor - people tend to only work on the features they're using. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/16 v3] powerpc: Split retrieval of processor entitlement data into a helper routine
Paul Mackerras wrote: Robert Jennings writes: Split the retrieval of processor entitlement data returned in the H_GET_PPP hcall into its own helper routine. This seems to change the value reported for pool_capacity radically: /* report pool_capacity in percentage */ - seq_printf(m, pool_capacity=%ld\n, - ((h_resource 2 * 8) 0x) * 100); + seq_printf(m, pool_capacity=%d\n, ppp_data.group_num * 100); On a Power6 partition here with your patch series applied, I see pool_capacity=3277200 in /proc/ppc64/lparcfg. Without your patches, I get pool_capacity=400 pool_idle_time=0 pool_num_procs=0 This looks like an incompatible user-visible change to me, and we haven't even changed the lparcfg version number at the beginning of the /proc/ppc64/lparcfg output. Why is the pool_capacity so different, and why do the pool_idle_time and pool_num_procs lines disappear? ok, three problems, three new patches. The reporting of pool_capacity was a bug in using the wrong information reported by h_get_ppp in the patch. This is in a new patch 4/16. The failure to report the pool_idle_time and pool_num_procs was due to an update to h_pic where we started checking the return code of the h_call for H_PIC. The values were not reported if the h_call fails, which on my partition it fails with -10 (H_Authority). I have reverted this back to the previous behavior and report the values of pool_idle_time and pool_num_procs regardless of the h_call return code. This is in a new patch 2/16. Yes, the lparcfg version number should have been updated. I missed that. Fixed in a new patch 3/16. -Nathan Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/16 v3] powerpc: Split processor entitlement retrieval and gathering to helper routines
Updated patch to remove checking the return code from the h_call for
H_PIC. This reverts the reporting back to its original state.
Split the retrieval and setting of processor entitlement and weight into
helper routines. This also removes the printing of the raw values
returned from h_get_ppp, the values are already parsed and printed.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 168 ++---
1 file changed, 90 insertions(+), 78 deletions(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c2008-07-22
10:35:13.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-07-22 12:50:47.0
-0500
@@ -167,7 +167,8 @@
return rc;
}
-static void h_pic(unsigned long *pool_idle_time, unsigned long *num_procs)
+static unsigned h_pic(unsigned long *pool_idle_time,
+ unsigned long *num_procs)
{
unsigned long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
@@ -176,6 +177,51 @@
*pool_idle_time = retbuf[0];
*num_procs = retbuf[1];
+
+ return rc;
+}
+
+/*
+ * parse_ppp_data
+ * Parse out the data returned from h_get_ppp and h_pic
+ */
+static void parse_ppp_data(struct seq_file *m)
+{
+ unsigned long h_entitled, h_unallocated;
+ unsigned long h_aggregation, h_resource;
+ int rc;
+
+ rc = h_get_ppp(h_entitled, h_unallocated, h_aggregation,
+ h_resource);
+ if (rc)
+ return;
+
+ seq_printf(m, partition_entitled_capacity=%ld\n, h_entitled);
+ seq_printf(m, group=%ld\n, (h_aggregation 2 * 8) 0x);
+ seq_printf(m, system_active_processors=%ld\n,
+ (h_resource 0 * 8) 0x);
+
+ /* pool related entries are apropriate for shared configs */
+ if (lppaca[0].shared_proc) {
+ unsigned long pool_idle_time, pool_procs;
+
+ seq_printf(m, pool=%ld\n, (h_aggregation 0 * 8) 0x);
+
+ /* report pool_capacity in percentage */
+ seq_printf(m, pool_capacity=%ld\n,
+ ((h_resource 2 * 8) 0x) * 100);
+
+ h_pic(pool_idle_time, pool_procs);
+ seq_printf(m, pool_idle_time=%ld\n, pool_idle_time);
+ seq_printf(m, pool_num_procs=%ld\n, pool_procs);
+ }
+
+ seq_printf(m, unallocated_capacity_weight=%ld\n,
+ (h_resource 4 * 8) 0xFF);
+
+ seq_printf(m, capacity_weight=%ld\n, (h_resource 5 * 8) 0xFF);
+ seq_printf(m, capped=%ld\n, (h_resource 6 * 8) 0x01);
+ seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
}
#define SPLPAR_CHARACTERISTICS_TOKEN 20
@@ -302,60 +348,11 @@
partition_active_processors = lparcfg_count_active_processors();
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
- unsigned long h_entitled, h_unallocated;
- unsigned long h_aggregation, h_resource;
- unsigned long pool_idle_time, pool_procs;
- unsigned long purr;
-
- h_get_ppp(h_entitled, h_unallocated, h_aggregation,
- h_resource);
-
- seq_printf(m, R4=0x%lx\n, h_entitled);
- seq_printf(m, R5=0x%lx\n, h_unallocated);
- seq_printf(m, R6=0x%lx\n, h_aggregation);
- seq_printf(m, R7=0x%lx\n, h_resource);
-
- purr = get_purr();
-
/* this call handles the ibm,get-system-parameter contents */
parse_system_parameter_string(m);
+ parse_ppp_data(m);
- seq_printf(m, partition_entitled_capacity=%ld\n, h_entitled);
-
- seq_printf(m, group=%ld\n, (h_aggregation 2 * 8) 0x);
-
- seq_printf(m, system_active_processors=%ld\n,
- (h_resource 0 * 8) 0x);
-
- /* pool related entries are apropriate for shared configs */
- if (lppaca[0].shared_proc) {
-
- h_pic(pool_idle_time, pool_procs);
-
- seq_printf(m, pool=%ld\n,
- (h_aggregation 0 * 8) 0x);
-
- /* report pool_capacity in percentage */
- seq_printf(m, pool_capacity=%ld\n,
- ((h_resource 2 * 8) 0x) * 100);
-
- seq_printf(m, pool_idle_time=%ld\n, pool_idle_time);
-
- seq_printf(m, pool_num_procs=%ld\n, pool_procs);
- }
-
- seq_printf(m, unallocated_capacity_weight=%ld\n,
- (h_resource 4 * 8) 0xFF);
-
- seq_printf(m, capacity_weight=%ld\n,
- (h_resource 5 * 8) 0xFF);
-
-
Re: [PATCH 03/16 v3] powerpc: Add memory entitlement capabilities to /proc/ppc64/lparcfg
Updated patch, increment the lparcfg module version number.
Update /proc/ppc64/lparcfg to enable displaying of Cooperative Memory
Overcommitment statistics as reported by the H_GET_MPP hcall. This also
updates the lparcfg interface to allow setting memory entitlement and
weight.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 119 ++
include/asm-powerpc/hvcall.h | 18 ++
2 files changed, 136 insertions(+), 1 deletion(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c2008-07-22
12:50:47.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-07-22 13:16:58.0
-0500
@@ -35,7 +35,7 @@
#include asm/prom.h
#include asm/vdso_datapage.h
-#define MODULE_VERS 1.7
+#define MODULE_VERS 1.8
#define MODULE_NAME lparcfg
/* #define LPARCFG_DEBUG */
@@ -129,6 +129,35 @@
/*
* Methods used to fetch LPAR data when running on a pSeries platform.
*/
+/**
+ * h_get_mpp
+ * H_GET_MPP hcall returns info in 7 parms
+ */
+int h_get_mpp(struct hvcall_mpp_data *mpp_data)
+{
+ int rc;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+
+ rc = plpar_hcall9(H_GET_MPP, retbuf);
+
+ mpp_data-entitled_mem = retbuf[0];
+ mpp_data-mapped_mem = retbuf[1];
+
+ mpp_data-group_num = (retbuf[2] 2 * 8) 0x;
+ mpp_data-pool_num = retbuf[2] 0x;
+
+ mpp_data-mem_weight = (retbuf[3] 7 * 8) 0xff;
+ mpp_data-unallocated_mem_weight = (retbuf[3] 6 * 8) 0xff;
+ mpp_data-unallocated_entitlement = retbuf[3] 0x;
+
+ mpp_data-pool_size = retbuf[4];
+ mpp_data-loan_request = retbuf[5];
+ mpp_data-backing_mem = retbuf[6];
+
+ return rc;
+}
+EXPORT_SYMBOL(h_get_mpp);
+
/*
* H_GET_PPP hcall returns info in 4 parms.
* entitled_capacity,unallocated_capacity,
@@ -224,6 +253,44 @@
seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
}
+/**
+ * parse_mpp_data
+ * Parse out data returned from h_get_mpp
+ */
+static void parse_mpp_data(struct seq_file *m)
+{
+ struct hvcall_mpp_data mpp_data;
+ int rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return;
+
+ seq_printf(m, entitled_memory=%ld\n, mpp_data.entitled_mem);
+
+ if (mpp_data.mapped_mem != -1)
+ seq_printf(m, mapped_entitled_memory=%ld\n,
+ mpp_data.mapped_mem);
+
+ seq_printf(m, entitled_memory_group_number=%d\n, mpp_data.group_num);
+ seq_printf(m, entitled_memory_pool_number=%d\n, mpp_data.pool_num);
+
+ seq_printf(m, entitled_memory_weight=%d\n, mpp_data.mem_weight);
+ seq_printf(m, unallocated_entitled_memory_weight=%d\n,
+ mpp_data.unallocated_mem_weight);
+ seq_printf(m, unallocated_io_mapping_entitlement=%ld\n,
+ mpp_data.unallocated_entitlement);
+
+ if (mpp_data.pool_size != -1)
+ seq_printf(m, entitled_memory_pool_size=%ld bytes\n,
+ mpp_data.pool_size);
+
+ seq_printf(m, entitled_memory_loan_request=%ld\n,
+ mpp_data.loan_request);
+
+ seq_printf(m, backing_memory=%ld bytes\n, mpp_data.backing_mem);
+}
+
#define SPLPAR_CHARACTERISTICS_TOKEN 20
#define SPLPAR_MAXLENGTH 1026*(sizeof(char))
@@ -351,6 +418,7 @@
/* this call handles the ibm,get-system-parameter contents */
parse_system_parameter_string(m);
parse_ppp_data(m);
+ parse_mpp_data(m);
seq_printf(m, purr=%ld\n, get_purr());
} else {/* non SPLPAR case */
@@ -414,6 +482,43 @@
return retval;
}
+/**
+ * update_mpp
+ *
+ * Update the memory entitlement and weight for the partition. Caller must
+ * specify either a new entitlement or weight, not both, to be updated
+ * since the h_set_mpp call takes both entitlement and weight as parameters.
+ */
+static ssize_t update_mpp(u64 *entitlement, u8 *weight)
+{
+ struct hvcall_mpp_data mpp_data;
+ u64 new_entitled;
+ u8 new_weight;
+ ssize_t rc;
+
+ rc = h_get_mpp(mpp_data);
+ if (rc)
+ return rc;
+
+ if (entitlement) {
+ new_weight = mpp_data.mem_weight;
+ new_entitled = *entitlement;
+ } else if (weight) {
+ new_weight = *weight;
+ new_entitled = mpp_data.entitled_mem;
+ } else
+ return -EINVAL;
+
+ pr_debug(%s: current_entitled = %lu, current_weight = %u\n,
+__FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+
+ pr_debug(%s: new_entitled = %lu, new_weight = %u\n,
+__FUNCTION__, new_entitled, new_weight);
+
+ rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
+
Re: [PATCH 04/16 v3] powerpc: Split retrieval of processor entitlement data into a helper routine
Updated patch to correct the reporting of pool_capcity.
Split the retrieval of processor entitlement data returned in the H_GET_PPP
hcall into its own helper routine.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c | 80 --
1 file changed, 45 insertions(+), 35 deletions(-)
Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c2008-07-22
13:16:58.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c 2008-07-22 13:17:25.0
-0500
@@ -158,6 +158,18 @@
}
EXPORT_SYMBOL(h_get_mpp);
+struct hvcall_ppp_data {
+ u64 entitlement;
+ u64 unallocated_entitlement;
+ u16 group_num;
+ u16 pool_num;
+ u8 capped;
+ u8 weight;
+ u8 unallocated_weight;
+ u16 active_procs_in_pool;
+ u16 active_system_procs;
+};
+
/*
* H_GET_PPP hcall returns info in 4 parms.
* entitled_capacity,unallocated_capacity,
@@ -178,20 +190,24 @@
* - Active processors in Physical Processor Pool.
* - Processors active on platform.
*/
-static unsigned int h_get_ppp(unsigned long *entitled,
- unsigned long *unallocated,
- unsigned long *aggregation,
- unsigned long *resource)
+static unsigned int h_get_ppp(struct hvcall_ppp_data *ppp_data)
{
unsigned long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
rc = plpar_hcall(H_GET_PPP, retbuf);
- *entitled = retbuf[0];
- *unallocated = retbuf[1];
- *aggregation = retbuf[2];
- *resource = retbuf[3];
+ ppp_data-entitlement = retbuf[0];
+ ppp_data-unallocated_entitlement = retbuf[1];
+
+ ppp_data-group_num = (retbuf[2] 2 * 8) 0x;
+ ppp_data-pool_num = retbuf[2] 0x;
+
+ ppp_data-capped = (retbuf[3] 6 * 8) 0x01;
+ ppp_data-weight = (retbuf[3] 5 * 8) 0xff;
+ ppp_data-unallocated_weight = (retbuf[3] 4 * 8) 0xff;
+ ppp_data-active_procs_in_pool = (retbuf[3] 2 * 8) 0x;
+ ppp_data-active_system_procs = retbuf[3] 0x;
return rc;
}
@@ -216,41 +232,40 @@
*/
static void parse_ppp_data(struct seq_file *m)
{
- unsigned long h_entitled, h_unallocated;
- unsigned long h_aggregation, h_resource;
+ struct hvcall_ppp_data ppp_data;
int rc;
- rc = h_get_ppp(h_entitled, h_unallocated, h_aggregation,
- h_resource);
+ rc = h_get_ppp(ppp_data);
if (rc)
return;
- seq_printf(m, partition_entitled_capacity=%ld\n, h_entitled);
- seq_printf(m, group=%ld\n, (h_aggregation 2 * 8) 0x);
- seq_printf(m, system_active_processors=%ld\n,
- (h_resource 0 * 8) 0x);
+ seq_printf(m, partition_entitled_capacity=%ld\n,
+ ppp_data.entitlement);
+ seq_printf(m, group=%d\n, ppp_data.group_num);
+ seq_printf(m, system_active_processors=%d\n,
+ ppp_data.active_system_procs);
/* pool related entries are apropriate for shared configs */
if (lppaca[0].shared_proc) {
unsigned long pool_idle_time, pool_procs;
- seq_printf(m, pool=%ld\n, (h_aggregation 0 * 8) 0x);
+ seq_printf(m, pool=%d\n, ppp_data.pool_num);
/* report pool_capacity in percentage */
- seq_printf(m, pool_capacity=%ld\n,
- ((h_resource 2 * 8) 0x) * 100);
+ seq_printf(m, pool_capacity=%d\n,
+ ppp_data.active_procs_in_pool * 100);
h_pic(pool_idle_time, pool_procs);
seq_printf(m, pool_idle_time=%ld\n, pool_idle_time);
seq_printf(m, pool_num_procs=%ld\n, pool_procs);
}
- seq_printf(m, unallocated_capacity_weight=%ld\n,
- (h_resource 4 * 8) 0xFF);
-
- seq_printf(m, capacity_weight=%ld\n, (h_resource 5 * 8) 0xFF);
- seq_printf(m, capped=%ld\n, (h_resource 6 * 8) 0x01);
- seq_printf(m, unallocated_capacity=%ld\n, h_unallocated);
+ seq_printf(m, unallocated_capacity_weight=%d\n,
+ ppp_data.unallocated_weight);
+ seq_printf(m, capacity_weight=%d\n, ppp_data.weight);
+ seq_printf(m, capped=%d\n, ppp_data.capped);
+ seq_printf(m, unallocated_capacity=%ld\n,
+ ppp_data.unallocated_entitlement);
}
/**
@@ -449,31 +464,27 @@
static ssize_t update_ppp(u64 *entitlement, u8 *weight)
{
- unsigned long current_entitled;
- unsigned long dummy;
- unsigned long resource;
- u8 current_weight, new_weight;
+ struct hvcall_ppp_data ppp_data;
+ u8 new_weight;
Re: latest tree build failure -- cpm uart gpio
On Tuesday 22 July 2008, Anton Vorontsov wrote: On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' I think this patch should help: [OF] of_gpio: should use new linux/gpio.h header http://patchwork.ozlabs.org/linuxppc/patch?id=18750 Is that confirmed as fixing this, vs just being the Right Thing To Do? David, can you please Ack it? See Benjamin's mail: http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html If you like ... but this is an OF-specific change, making it conform with the interface spec, so I wouldn't expect this to need more approvals than it's already got. Acked-by: David Brownell [EMAIL PROTECTED] -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
netif_schedule and mpc5200_fec
I just updated to linus/master and mpc5200_fec won't boot. Guessing it is this patch but I haven't looked at it yet. commit 263ba3204a434d0ca851e1321b31cd58376b86cb Author: David S. Miller [EMAIL PROTECTED] Date: Tue Jul 15 03:47:41 2008 -0700 netdev: Convert all drivers away from netif_schedule(). They logically all want to trigger a schedule for all device TX queues. Signed-off-by: David S. Miller [EMAIL PROTECTED] Sending DHCP requests .0[ cut here ] Badness at c01da570 [verbose debug info unavailable] NIP: c01da570 LR: c015b31c CTR: c015b234 REGS: c382de70 TRAP: 0700 Not tainted (2.6.26-efika) MSR: 00029032 EE,ME,IR,DR CR: 2282 XER: TASK = c3815000[4] 'events/0' THREAD: c382c000 GPR00: 0001 c382df20 c3815000 c031e468 c38f25a0 GPR08: c382dfb4 c033 c031e468 3181b461 03ffe000 GPR16: 0001 007ffc00 03ff8838 0004 GPR24: c032b46c c033 c38a2e00 0001 c38f2780 c38f2400 NIP [c01da570] __netif_schedule+0x3c/0xac LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194 Call Trace: [c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable) [c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194 [c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0 [c382df80] [c002eb0c] run_workqueue+0xb4/0x148 [c382dfa0] [c002f070] worker_thread+0x9c/0xb8 [c382dfd0] [c0032954] kthread+0x4c/0x88 [c382dff0] [c000f538] kernel_thread+0x44/0x60 Instruction dump: 7c6b1b78 3929e468 7f834800 3922 90010024 38030024 bfa10014 40be0030 3d20c033 80099988 7c34 5400d97e 0f00 2f80 41be0054 3801 PHY: f0003000:00 - Link is Up - 100/Full ., OK -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
Laurent Pinchart wrote:
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They are not used anymore and can be safely
removed.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
include/linux/fs_enet_pd.h|4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..decc4b5 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
struct fs_mii_bit mdio_dir;
struct fs_mii_bit mdio_dat;
struct fs_mii_bit mdc_dat;
- int mdio_port; /* port bit for MDIO */
- int mdio_bit;
- int mdc_port; /* port bit for MDC */
- int mdc_bit;
int delay; /* delay in us */
int irq[32];/* irqs per phy's */
applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigantci pages patches
David Gibson wrote: On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote: Hi all, Could people take one last look at these patches and if there are no issues, please send Ack-bys to Andrew who will push them to Linus for 2.6.27. [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages http://patchwork.ozlabs.org/linuxppc/patch?id=18437 Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages http://patchwork.ozlabs.org/linuxppc/patch?id=18438 Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations http://patchwork.ozlabs.org/linuxppc/patch?id=18439 Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages http://patchwork.ozlabs.org/linuxppc/patch?id=18440 Patch: [PATCH 5/6 v2] check for overflow http://patchwork.ozlabs.org/linuxppc/patch?id=18441 Patch: [PATCH 6/6] powerpc: support multiple huge page sizes http://patchwork.ozlabs.org/linuxppc/patch?id=18442 Sorry, I should have looked at these properly when they went past in May, but obviously I missed them. They mostly look ok. I'm a bit confused on 2/6 though - it seems the new powerpc alloc_bootmem_huge_page() function is specific to the 16G gigantic pages. But can't that function also get called for the normal 16M hugepages depending on how the hugepage pool is initialized. Or am I missing something (wouldn't surprise me given my brain's sluggishness today)? The alloc_bootmem_huge_page() function is only called for pages = MAX_ORDER. The 16M pages are always allocated within the generic hugetlbfs code with alloc_pages_node(). Jon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: latest tree build failure -- cpm uart gpio
On Tue, Jul 22, 2008 at 12:33:16PM -0700, David Brownell wrote: On Tuesday 22 July 2008, Anton Vorontsov wrote: On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' I think this patch should help: [OF] of_gpio: should use new linux/gpio.h header http://patchwork.ozlabs.org/linuxppc/patch?id=18750 Is that confirmed as fixing this, vs just being the Right Thing To Do? Just applied the patch locally and the issue is not reproducible anymore. David, can you please Ack it? See Benjamin's mail: http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html If you like ... but this is an OF-specific change, making it conform with the interface spec, so I wouldn't expect this to need more approvals than it's already got. Acked-by: David Brownell [EMAIL PROTECTED] Thanks. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
* Nate Case | 2008-07-21 17:57:08 [-0500]: On Fri, 2008-07-18 at 14:10 +0200, Sebastian Siewior wrote: Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping] changed the phydev-lock from spinlock into a mutex. Now, the following code path got triggered while NFS was unavailable: [snip] |[ 194.864733] BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87 |[ 194.875529] in_atomic():1, irqs_disabled():0 |[ 194.879805] Call Trace: |[ 194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable) |[ 194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4 |[ 194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c |[ 194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70 |[ 194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4 |[ 194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60 |[ 194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144 Hmm.. I'm not sure what the best solution is to this. Make the stop_gfar() call happen in a workqueue, and make a similar change to ucc_geth, fec_mpc52xx, and fs_enet? Modify phy_stop() to do the work in a workqueue conditionally if in interrupt context? Between these two I'd lean toward the latter. Does anyone have any better ideas? If I look at tg3.c than exactly this is done. Others call it only on close(). I guess this depends very much on driver's logic :) If nobody minds, than I would assume that tg3.c is a good example and I would move the timout path into a workqueu. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote:
I just updated to linus/master and mpc5200_fec won't boot.
It does boot, but this badness looks like it is coming from this
patch. I don't know enough about networking to debug it.
[EMAIL PROTECTED]:~/fs/drivers/net$ git diff
8b9835108f68938a5f7e74fd2c0fc65da2abad92 fec_mpc52xx.c
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 329edd9..ae9ecb7 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,7 +197,7 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
if (priv-link == PHY_DOWN) {
new_state = 1;
priv-link = phydev-link;
- netif_schedule(dev);
+ netif_tx_schedule_all(dev);
netif_carrier_on(dev);
netif_start_queue(dev);
}
[EMAIL PROTECTED]:~/fs/drivers/net$
Guessing it is this patch but I haven't looked at it yet.
commit 263ba3204a434d0ca851e1321b31cd58376b86cb
Author: David S. Miller [EMAIL PROTECTED]
Date: Tue Jul 15 03:47:41 2008 -0700
netdev: Convert all drivers away from netif_schedule().
They logically all want to trigger a schedule for all device
TX queues.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
Sending DHCP requests .0[ cut here ]
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700 Not tainted (2.6.26-efika)
MSR: 00029032 EE,ME,IR,DR CR: 2282 XER:
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 0001 c382df20 c3815000 c031e468 c38f25a0
GPR08: c382dfb4 c033 c031e468 3181b461 03ffe000
GPR16: 0001 007ffc00 03ff8838
0004
GPR24: c032b46c c033 c38a2e00 0001 c38f2780
c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 3922 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c34 5400d97e 0f00 2f80 41be0054 3801
PHY: f0003000:00 - Link is Up - 100/Full
., OK
--
Jon Smirl
[EMAIL PROTECTED]
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: going to OLS?
Sounds good, I'll be there. It will be good to put some faces to names. Cheers, John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Becky Bruce Sent: Tuesday, July 22, 2008 8:55 AM To: Sean MacLennan; [EMAIL PROTECTED]; Wolfgang Denk; Stefan Roese; Geert Uytterhoeven Cc: linuxppc-dev@ozlabs.org Subject: Re: going to OLS? So, There doesn't seem to be an official plan, so I'm making one Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this evening. Anybody that wants to join us welcome. Cheers, Becky On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote: On Mon, 21 Jul 2008 14:15:53 -0600 Grant Likely [EMAIL PROTECTED] wrote: BTW, if anyone else wants to receive the contact phone list, then send me your phone number ASAP. I'll be sending it out this evening. My home phone number is 613-728-1680. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 17:03:32 -0400 On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote: I just updated to linus/master and mpc5200_fec won't boot. It does boot, but this badness looks like it is coming from this patch. I don't know enough about networking to debug it. The driver is doing a netif_wake_queue() when it should not. I'll have a more detailed look at this and try to fix it later. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Tue, Jul 22, 2008 at 12:38:30PM -0400, Jon Smirl wrote: On 7/22/08, Grant Likely [EMAIL PROTECTED] wrote: +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev, + void *codec_data, struct snd_soc_dai *dai, + struct device_node *node); + +int of_snd_soc_register_platform(struct snd_soc_platform *platform, +struct device_node *node, +struct snd_soc_dai *cpu_dai); + This doesn't compile for me. Where is struct snd_soc_dai being defined? It used to be +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev, + void *codec_data, struct snd_soc_codec_dai *dai, + struct device_node *node); + +int of_snd_soc_register_platform(struct snd_soc_platform *platform, + struct device_node *node, + struct snd_soc_cpu_dai *cpu_dai); I had to change it to match what is in Linus' current top of tree. The snd_soc_cpu_dai and snd_soc_codec_dai structures have been merged. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
On Tue, Jul 22, 2008 at 11:09:52AM +0100, Mark Brown wrote: On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote: Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] There's a few issues that were raised on the previous review cycle that still need to be addressed but they should be fixable in incremental patches (and easier to review that way): +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd) + spin_lock_irqsave(psc_i2s-lock, flags); + /* first make sure it is low */ + while ((in_8(regs-ipcr_acr.ipcr) 0x80) != 0) + ; + /* then wait for the transition to high */ + while ((in_8(regs-ipcr_acr.ipcr) 0x80) == 0) + ; These loops should really have some sort of time limit on them, otherwise they'll lock hard if the expected events don't happen. Given that in slave mode they're synchronising with an externally generated clock this is something that might happen in practice and should produce better diagnostics. Yes, I hope to rework these two lines entirely. I'm not happy with the current implementation either. + default: + dev_dbg(psc_i2s-dev, invalid command\n); + return -EINVAL; + } I'd really expect to see the other possible triggers handled, even if the appropriate action is to silently ignore them, rather than having them generate an error message. Okay, I'll do that. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] ASoC: Make OpenFirmware helper include file conditional
On Tue, Jul 22, 2008 at 12:53:07PM +0100, Mark Brown wrote: The OpenFirmware API headers don't build on all platforms so ensure that they are not included unless they are being used. Signed-off-by: Mark Brown [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] I actually fixed this in my tree, but I forgot to roll it into the patch before I emailed it. Thanks. g. --- include/sound/soc-of-simple.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h index 696fc51..a064e19 100644 --- a/include/sound/soc-of-simple.h +++ b/include/sound/soc-of-simple.h @@ -7,6 +7,8 @@ #ifndef _INCLUDE_SOC_OF_H_ #define _INCLUDE_SOC_OF_H_ +#if defined(CONFIG_SND_SOC_OF_SIMPLE) || defined(CONFIG_SND_SOC_OF_SIMPLE_MODULE) + #include linux/of.h #include sound/soc.h @@ -18,4 +20,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform, struct device_node *node, struct snd_soc_dai *cpu_dai); +#endif + #endif /* _INCLUDE_SOC_OF_H_ */ -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] ASoC: Export DAI and codec for TLV320AIC26
On Tue, Jul 22, 2008 at 12:53:08PM +0100, Mark Brown wrote:
This fixes sparse warnings and allows non-OpenFirmware systems to attempt
to bind to the device.
Signed-off-by: Mark Brown [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
sound/soc/codecs/tlv320aic26.c |1 +
sound/soc/codecs/tlv320aic26.h |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
index 4621fda..73b7027 100644
--- a/sound/soc/codecs/tlv320aic26.c
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -383,6 +383,7 @@ struct snd_soc_codec_device aic26_soc_codec_dev = {
.probe = aic26_probe,
.remove = aic26_remove,
};
+EXPORT_SYMBOL_GPL(aic26_soc_codec_dev);
/* -
* SPI device portion of driver: sysfs files for debugging
diff --git a/sound/soc/codecs/tlv320aic26.h b/sound/soc/codecs/tlv320aic26.h
index 62b1f22..786ba16 100644
--- a/sound/soc/codecs/tlv320aic26.h
+++ b/sound/soc/codecs/tlv320aic26.h
@@ -90,4 +90,7 @@ enum aic26_wlen {
AIC26_WLEN_32 = 3 10,
};
+extern struct snd_soc_dai aic26_dai;
+extern struct snd_soc_codec_device aic26_soc_codec_dev;
+
#endif /* _TLV320AIC16_H_ */
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: Staticise keyclick dev_attr in tlv320aic26
On Tue, Jul 22, 2008 at 12:53:09PM +0100, Mark Brown wrote: Signed-off-by: Mark Brown [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- sound/soc/codecs/tlv320aic26.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c index 73b7027..bed8a9e 100644 --- a/sound/soc/codecs/tlv320aic26.c +++ b/sound/soc/codecs/tlv320aic26.c @@ -418,7 +418,7 @@ static ssize_t aic26_keyclick_set(struct device *dev, return count; } -DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set); +static DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set); /* - * SPI device portion of driver: probe and release routines and SPI -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
On Tue, Jul 22, 2008 at 10:26:47AM +0100, Mark Brown wrote: On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote: Here is the latest series for adding MPC5200 I2S and TI AIC26 codec support to ALSA SoC. I believe all the comments are addressed and I hope that this series is now ready to be merged. I would really like to see these ones land in 2.6.27. That might be a bit of a push given how far into the merge window we are and Takashi's holiday this week, though as they are new drivers things could be a bit more relaxed. Takashi, I'll queue these (and other ASoC patches) for submission in bulk once you return. Thanks Mark, I owe you a beer. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: going to OLS?
On Tue, Jul 22, 2008 at 03:09:55PM -0600, John Linn wrote: Becky Bruce wrote: So, There doesn't seem to be an official plan, so I'm making one Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this evening. Anybody that wants to join us welcome. Sounds good, I'll be there. It will be good to put some faces to names. I'll be there. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: latest tree build failure -- cpm uart gpio
On Wed, Jul 23, 2008 at 08:05:09AM +1000, Benjamin Herrenschmidt wrote: On Tue, 2008-07-22 at 18:53 +0400, Anton Vorontsov wrote: On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit declaration of function 'gpio_get_value' include/asm-generic/gpio.h:137: error: implicit declaration of function 'gpio_set_value' I think this patch should help: [OF] of_gpio: should use new linux/gpio.h header http://patchwork.ozlabs.org/linuxppc/patch?id=18750 David, can you please Ack it? See Benjamin's mail: http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html Hrm.. I though I had that one in my latest batch. In fact, I just checked and it got merged. Ah, great. So the issue should be fixed already... I just pulled the Linus' tree, and it is there indeed. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
From: Jon Smirl [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 17:03:32 -0400
On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote:
I just updated to linus/master and mpc5200_fec won't boot.
It does boot, but this badness looks like it is coming from this
patch. I don't know enough about networking to debug it.
I just applied the following patch from Anton Vorontsov which
will fix this.
netdev: bunch of drivers: avoid WARN at net/core/dev.c:1328
The drivers were touching net queue before it has been started, so
without this patch, the drivers will potentially WARN at
net/core/dev.c:1328.
I don't have the hardware for the drivers below, so this patch is
untested, and thus should be carefully peer reviewed.
tc35815.c
au1000_eth.c
bfin_mac.c
macb.c
^ The four drivers are using phylib, they're calling netif_start_queue()
in open() callback. So trivially remove netif_tx_schedule_all().
Phylib will handle netif_carrier_*().
cpmac.c
fec_mpc52xx.c
fs_enet/fs_enet-main.c
sh_eth.c
^ The same as above, but these were also needlessly calling
netif_carrier_*() functions. So removed queue calls and also remove
carrier calls, since phylib will handle it. fs_enet-main.c also didn't
call netif_start_queue() at open(), this is fixed now.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
drivers/net/au1000_eth.c |5 ++---
drivers/net/bfin_mac.c |1 -
drivers/net/cpmac.c|2 --
drivers/net/fec_mpc52xx.c |5 -
drivers/net/fs_enet/fs_enet-main.c |7 ++-
drivers/net/macb.c |4 +---
drivers/net/sh_eth.c |5 -
drivers/net/tc35815.c |1 -
8 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 3ab61e4..cb8be49 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -911,9 +911,8 @@ au1000_adjust_link(struct net_device *dev)
if(phydev-link != aup-old_link) {
// link state changed
- if (phydev-link) // link went up
- netif_tx_schedule_all(dev);
- else { // link went down
+ if (!phydev-link) {
+ /* link went down */
aup-old_speed = 0;
aup-old_duplex = -1;
}
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index a6a3da8..a8ec60e 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -357,7 +357,6 @@ static void bfin_mac_adjust_link(struct net_device *dev)
if (!lp-old_link) {
new_state = 1;
lp-old_link = 1;
- netif_tx_schedule_all(dev);
}
} else if (lp-old_link) {
new_state = 1;
diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index fbd4280..a7800e5 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -945,10 +945,8 @@ static void cpmac_adjust_link(struct net_device *dev)
if (!priv-oldlink) {
new_state = 1;
priv-oldlink = 1;
- netif_tx_schedule_all(dev);
}
} else if (priv-oldlink) {
- netif_tx_stop_all_queues(dev);
new_state = 1;
priv-oldlink = 0;
priv-oldspeed = 0;
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index ae9ecb7..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
if (priv-link == PHY_DOWN) {
new_state = 1;
priv-link = phydev-link;
- netif_tx_schedule_all(dev);
- netif_carrier_on(dev);
- netif_start_queue(dev);
}
} else if (priv-link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
priv-link = PHY_DOWN;
priv-speed = 0;
priv-duplex = -1;
- netif_stop_queue(dev);
- netif_carrier_off(dev);
}
if (new_state netif_msg_link(priv))
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 445763e..5291188 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -738,9 +738,6 @@ static void generic_adjust_link(struct net_device *dev)
if (!fep-oldlink) {
new_state = 1;
fep-oldlink = 1;
- netif_tx_schedule_all(dev);
- netif_carrier_on(dev);
- netif_start_queue(dev);
}
if (new_state)
@@ -750,8 +747,6 @@ static void
Re: netif_schedule and mpc5200_fec
On 7/22/08, David Miller [EMAIL PROTECTED] wrote:
From: Jon Smirl [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 17:03:32 -0400
On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote:
I just updated to linus/master and mpc5200_fec won't boot.
It does boot, but this badness looks like it is coming from this
patch. I don't know enough about networking to debug it.
I just applied the following patch from Anton Vorontsov which
will fix this.
I applied this piece and still have the same error.
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index b487d6f..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
if (priv-link == PHY_DOWN) {
new_state = 1;
priv-link = phydev-link;
-// netif_tx_schedule_all(dev);
-// netif_carrier_on(dev);
-// netif_start_queue(dev);
}
} else if (priv-link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
priv-link = PHY_DOWN;
priv-speed = 0;
priv-duplex = -1;
-// netif_stop_queue(dev);
-// netif_carrier_off(dev);
}
if (new_state netif_msg_link(priv))
[EMAIL PROTECTED]:~/fs$
net eth0: attached phy 0 to driver Generic PHY
Sending DHCP requests .0[ cut here ]
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700 Not tainted (2.6.26-efika)
MSR: 00029032 EE,ME,IR,DR CR: 2282 XER:
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 0001 c382df20 c3815000 c031e468 c38f25a0
GPR08: c382dfb4 c033 c031e468 2f762097 03ffe000
GPR16: 0001 007ffc00 03ff8838 0004
GPR24: c032b46c c033 c38a2e00 0001 c38f2780 c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 3922 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c34 5400d97e 0f00 2f80 41be0054 3801
PHY: f0003000:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.11
IP-Config: Complete:
device=eth0, addr=192.168.1.11, mask=255.255.255.0, gw=192.168.1.1,
host=Phytec, domain=, nis-domain=(none),
bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath=
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 18:54:18 -0400 On 7/22/08, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 17:03:32 -0400 On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote: I just updated to linus/master and mpc5200_fec won't boot. It does boot, but this badness looks like it is coming from this patch. I don't know enough about networking to debug it. I just applied the following patch from Anton Vorontsov which will fix this. I applied this piece and still have the same error. There are no calls to functions in mpc52xx_fec_adjust_link that can lead to __netif_schedule() any more. Therefore I can't see how your backtrace is even possible. Please double check that you've really applied the patch and that mpc52xx_fec_adjust_link lacks any calls to netif_*_queue() and *netif_schedule(). Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
On 7/22/08, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 18:54:18 -0400 On 7/22/08, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 17:03:32 -0400 On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote: I just updated to linus/master and mpc5200_fec won't boot. It does boot, but this badness looks like it is coming from this patch. I don't know enough about networking to debug it. I just applied the following patch from Anton Vorontsov which will fix this. I applied this piece and still have the same error. There are no calls to functions in mpc52xx_fec_adjust_link that can lead to __netif_schedule() any more. Therefore I can't see how your backtrace is even possible. Please double check that you've really applied the patch and that mpc52xx_fec_adjust_link lacks any calls to netif_*_queue() and *netif_schedule(). You're right. That patch fixes it. Another thing I brought down made my image file not get generated and I was using an old image. Thanks. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: netif_schedule and mpc5200_fec
From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 19:33:13 -0400 On 7/22/08, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 18:54:18 -0400 On 7/22/08, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 22 Jul 2008 17:03:32 -0400 On 7/22/08, Jon Smirl [EMAIL PROTECTED] wrote: I just updated to linus/master and mpc5200_fec won't boot. It does boot, but this badness looks like it is coming from this patch. I don't know enough about networking to debug it. I just applied the following patch from Anton Vorontsov which will fix this. I applied this piece and still have the same error. There are no calls to functions in mpc52xx_fec_adjust_link that can lead to __netif_schedule() any more. Therefore I can't see how your backtrace is even possible. Please double check that you've really applied the patch and that mpc52xx_fec_adjust_link lacks any calls to netif_*_queue() and *netif_schedule(). You're right. That patch fixes it. Another thing I brought down made my image file not get generated and I was using an old image. Thanks for confirming this Jon. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] Support internal I2S clock sources on MPC5200
Support internal I2S clock sources on MPC5200
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
sound/soc/fsl/mpc5200_psc_i2s.c | 58 ++-
sound/soc/fsl/mpc5200_psc_i2s.h | 13 +
2 files changed, 64 insertions(+), 7 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index 8692329..f028f61 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -23,8 +23,12 @@
#include sysdev/bestcomm/bestcomm.h
#include sysdev/bestcomm/gen_bd.h
+#include asm/time.h
+#include asm/mpc52xx.h
#include asm/mpc52xx_psc.h
+#include mpc5200_psc_i2s.h
+
MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Freescale MPC5200 PSC in I2S mode ASoC Driver);
MODULE_LICENSE(GPL);
@@ -93,6 +97,7 @@ struct psc_i2s {
struct snd_soc_dai dai;
spinlock_t lock;
u32 sicr;
+ uint sysclk;
/* per-stream data */
struct psc_i2s_stream playback;
@@ -224,6 +229,7 @@ static int psc_i2s_hw_params(struct snd_pcm_substream
*substream,
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct psc_i2s *psc_i2s = rtd-dai-cpu_dai-private_data;
+ uint bits, framesync, bitclk, value;
u32 mode;
dev_dbg(psc_i2s-dev, %s(substream=%p) p_size=%i p_bytes=%i
@@ -235,15 +241,19 @@ static int psc_i2s_hw_params(struct snd_pcm_substream
*substream,
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S8:
mode = MPC52xx_PSC_SICR_SIM_CODEC_8;
+ bits = 8;
break;
case SNDRV_PCM_FORMAT_S16_BE:
mode = MPC52xx_PSC_SICR_SIM_CODEC_16;
+ bits = 16;
break;
case SNDRV_PCM_FORMAT_S24_BE:
mode = MPC52xx_PSC_SICR_SIM_CODEC_24;
+ bits = 24;
break;
case SNDRV_PCM_FORMAT_S32_BE:
mode = MPC52xx_PSC_SICR_SIM_CODEC_32;
+ bits = 32;
break;
default:
dev_dbg(psc_i2s-dev, invalid format\n);
@@ -251,7 +261,24 @@ static int psc_i2s_hw_params(struct snd_pcm_substream
*substream,
}
out_be32(psc_i2s-psc_regs-sicr, psc_i2s-sicr | mode);
- snd_pcm_set_runtime_buffer(substream, substream-dma_buffer);
+ if (psc_i2s-sysclk) {
+ framesync = bits * 2;
+ bitclk = (psc_i2s-sysclk) / (params_rate(params) * framesync);
+
+ /* bitclk field is byte swapped due to mpc5200/b compatibility
*/
+ value = ((framesync - 1) 24) |
+ (((bitclk - 1) 0xFF) 16) | ((bitclk - 1) 0xFF00);
+
+ dev_dbg(psc_i2s-dev, %s(substream=%p) rate=%i sysclk=%i
+framesync=%i bitclk=%i reg=%X\n,
+ __FUNCTION__, substream, params_rate(params),
psc_i2s-sysclk,
+ framesync, bitclk, value);
+
+ out_be32(psc_i2s-psc_regs-ccr, value);
+ out_8(psc_i2s-psc_regs-ctur, bits - 1);
+ }
+
+ snd_pcm_set_runtime_buffer(substream, substream-dma_buffer);
return 0;
}
@@ -429,9 +456,29 @@ static int psc_i2s_set_sysclk(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq, int dir)
{
struct psc_i2s *psc_i2s = cpu_dai-private_data;
- dev_dbg(psc_i2s-dev, psc_i2s_set_sysclk(cpu_dai=%p, dir=%i)\n,
- cpu_dai, dir);
- return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL;
+ int clkdiv, err;
+ dev_dbg(psc_i2s-dev, psc_i2s_set_sysclk(cpu_dai=%p, freq=%u,
dir=%i)\n,
+ cpu_dai, freq, dir);
+ if (dir == SND_SOC_CLOCK_OUT) {
+ psc_i2s-sysclk = freq;
+ if (clk_id == MPC52xx_CLK_CELLSLAVE) {
+ psc_i2s-sicr |= MPC52xx_PSC_SICR_CELLSLAVE |
MPC52xx_PSC_SICR_GENCLK;
+ } else { /* MPC52xx_CLK_INTERNAL */
+ psc_i2s-sicr = ~MPC52xx_PSC_SICR_CELLSLAVE;
+ psc_i2s-sicr |= MPC52xx_PSC_SICR_GENCLK;
+
+ clkdiv = ppc_proc_freq / freq;
+ err = ppc_proc_freq % freq;
+ if (err freq / 2)
+ clkdiv++;
+
+ dev_dbg(psc_i2s-dev, psc_i2s_set_sysclk(clkdiv %d
freq error=%ldHz)\n,
+ clkdiv, (ppc_proc_freq / clkdiv -
freq));
+
+ return mpc52xx_set_psc_clkdiv(psc_i2s-dai.id + 1,
clkdiv);
+ }
+ }
+ return 0;
}
/**
@@ -784,9 +831,6 @@ static int __devinit psc_i2s_of_probe(struct of_device *op,
/* Configure the serial interface mode; defaulting to CODEC8 mode */
psc_i2s-sicr =
[PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
Allow a custom ASOC machine driver with soc-of-simple
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
include/sound/soc-of-simple.h |2 ++
sound/soc/fsl/soc-of-simple.c | 26 +-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
index 696fc51..1e83f2f 100644
--- a/include/sound/soc-of-simple.h
+++ b/include/sound/soc-of-simple.h
@@ -18,4 +18,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform
*platform,
struct device_node *node,
struct snd_soc_dai *cpu_dai);
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops);
+
#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
index 0382fda..dd2fa23 100644
--- a/sound/soc/fsl/soc-of-simple.c
+++ b/sound/soc/fsl/soc-of-simple.c
@@ -38,8 +38,8 @@ struct of_snd_soc_device {
struct device_node *codec_node;
};
-static struct snd_soc_ops of_snd_soc_ops = {
-};
+static struct snd_soc_ops *machine_ops = NULL;
+static char *machine_name = NULL;
static struct of_snd_soc_device *
of_snd_soc_get_device(struct device_node *codec_node)
@@ -61,7 +61,7 @@ of_snd_soc_get_device(struct device_node *codec_node)
of_soc-machine.dai_link = of_soc-dai_link;
of_soc-machine.num_links = 1;
of_soc-device.machine = of_soc-machine;
- of_soc-dai_link.ops = of_snd_soc_ops;
+ of_soc-dai_link.ops = machine_ops;
list_add(of_soc-list, of_snd_soc_device_list);
return of_soc;
@@ -74,7 +74,7 @@ static void of_snd_soc_register_device(struct
of_snd_soc_device *of_soc)
/* Only register the device if both the codec and platform have
* been registered */
- if ((!of_soc-device.codec_data) || (!of_soc-platform_node))
+ if ((!of_soc-device.codec_data) || (!of_soc-platform_node) ||
!machine_name)
return;
pr_info(platform--codec match achieved; registering machine\n);
@@ -159,7 +159,7 @@ int of_snd_soc_register_platform(struct snd_soc_platform
*platform,
of_soc-platform_node = node;
of_soc-dai_link.cpu_dai = cpu_dai;
of_soc-device.platform = platform;
- of_soc-machine.name = of_soc-dai_link.cpu_dai-name;
+ of_soc-machine.name = machine_name;
/* Now try to register the SoC device */
of_snd_soc_register_device(of_soc);
@@ -169,3 +169,19 @@ int of_snd_soc_register_platform(struct snd_soc_platform
*platform,
return rc;
}
EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
+
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops)
+{
+ struct of_snd_soc_device *of_soc;
+
+ machine_name = name;
+ machine_ops = ops;
+
+ list_for_each_entry(of_soc, of_snd_soc_device_list, list) {
+ of_soc-dai_link.ops = machine_ops;
+ of_soc-machine.name = machine_name;
+ of_snd_soc_register_device(of_soc);
+ }
+
+}
+EXPORT_SYMBOL_GPL(of_snd_soc_register_machine);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fallout from sysdev API changes
A struct sysdev_attribute * parameter was added to the show routine by
commit 4a0b2b4dbe1335b8b9886ba3dc85a145d5d938ed sysdev: Pass the
attribute to the low level sysdev show/store function.
This eliminates a warning:
arch/powerpc/kernel/sysfs.c:538: warning: initialization from incompatible
pointer type
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/kernel/sysfs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Greg, probably easiest for this to go via the powerpc tree - an Ack would
be nice, though.
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index aba0ba9..800e5e9 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -529,7 +529,8 @@ static void register_nodes(void)
#endif
/* Only valid if CPU is present. */
-static ssize_t show_physical_id(struct sys_device *dev, char *buf)
+static ssize_t show_physical_id(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
{
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
--
1.5.6.3
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
Hi,
That, or adding a small function to move the bits to the appropriate
registers (set_dbcr or set_dac_events).
Do you think it's worth to support this facility on 405's processors? If
so, i'll gladly work on a solution to it.
I would think so. There's really no difference from a userspace
perspective, so gdb watchpoints could be valuable there too. I'll
leave it up to you though.
As the 440 support is ready and the 405 needs additional tweaking due to
the use of DBCR1 instead of DBCR0 and due to a different position scheme
of the DAC1R/DAC1W flags inside DBCR1, i'd say we should include this
code and handle the 405 case later.
We might have to handle it anyway if we're going to pursue the hardware
breakpoint interface work in the future.
I've fixed some formatting problems. Tested on a 440 Taishan board and
on a PPC970. Both worked as they should. Ok?
Signed-off-by: Luis Machado [EMAIL PROTECTED]
Index: linux-2.6.26/arch/powerpc/kernel/process.c
===
--- linux-2.6.26.orig/arch/powerpc/kernel/process.c 2008-07-20
16:56:57.0 -0700
+++ linux-2.6.26/arch/powerpc/kernel/process.c 2008-07-22 16:46:36.0
-0700
@@ -47,6 +47,8 @@
#ifdef CONFIG_PPC64
#include asm/firmware.h
#endif
+#include linux/kprobes.h
+#include linux/kdebug.h
extern unsigned long _get_SP(void);
@@ -239,6 +241,36 @@
}
#endif /* CONFIG_SMP */
+void do_dabr(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code)
+{
+ siginfo_t info;
+
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+ if (notify_die(DIE_DABR_MATCH, dabr_match, regs, error_code,
+ 11, SIGSEGV) == NOTIFY_STOP)
+ return;
+
+ if (debugger_dabr_match(regs))
+ return;
+
+ /* Clear the DAC and struct entries. One shot trigger. */
+#else /* (defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) ~(DBSR_DAC1R | DBSR_DAC1W
+ | DBCR0_IDM));
+#endif
+
+ /* Clear the DABR */
+ set_dabr(0);
+
+ /* Deliver the signal to userspace */
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGTRAP, info, current);
+}
+
static DEFINE_PER_CPU(unsigned long, current_dabr);
int set_dabr(unsigned long dabr)
@@ -254,6 +286,11 @@
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
mtspr(SPRN_DABR, dabr);
#endif
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ mtspr(SPRN_DAC1, dabr);
+#endif
+
return 0;
}
@@ -337,6 +374,12 @@
if (unlikely(__get_cpu_var(current_dabr) != new-thread.dabr))
set_dabr(new-thread.dabr);
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /* If new thread DAC (HW breakpoint) is the same then leave it. */
+ if (new-thread.dabr)
+ set_dabr(new-thread.dabr);
+#endif
+
new_thread = new-thread;
old_thread = current-thread;
@@ -525,6 +568,10 @@
if (current-thread.dabr) {
current-thread.dabr = 0;
set_dabr(0);
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ current-thread.dbcr0 = ~(DBSR_DAC1R | DBSR_DAC1W);
+#endif
}
}
Index: linux-2.6.26/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6.26.orig/arch/powerpc/kernel/ptrace.c 2008-07-20
16:56:57.0 -0700
+++ linux-2.6.26/arch/powerpc/kernel/ptrace.c 2008-07-22 16:41:24.0
-0700
@@ -703,7 +703,7 @@
if (regs != NULL) {
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- task-thread.dbcr0 = DBCR0_IDM | DBCR0_IC;
+ task-thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
regs-msr |= MSR_DE;
#else
regs-msr |= MSR_SE;
@@ -716,9 +716,16 @@
{
struct pt_regs *regs = task-thread.regs;
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /* If DAC then do not single step, skip. */
+ if (task-thread.dabr)
+ return;
+#endif
+
if (regs != NULL) {
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- task-thread.dbcr0 = 0;
+ task-thread.dbcr0 = ~(DBCR0_IC | DBCR0_IDM);
regs-msr = ~MSR_DE;
#else
regs-msr = ~MSR_SE;
@@ -727,22 +734,71 @@
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
+int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
- /* We only support one DABR and no IABRS at the moment */
+ /* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
+ For embedded processors we support one DAC and
Re: netif_schedule and mpc5200_fec
On Tue, Jul 22, 2008 at 7:36 PM, David Miller [EMAIL PROTECTED] wrote: From: Jon Smirl [EMAIL PROTECTED] You're right. That patch fixes it. Another thing I brought down made my image file not get generated and I was using an old image. Thanks for confirming this Jon. Thanks for fixing it! Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple
Hi John, On Tue, 22 Jul 2008 19:53:51 -0400 Jon Smirl [EMAIL PROTECTED] wrote: +static struct snd_soc_ops *machine_ops = NULL; +static char *machine_name = NULL; You don't need these initialisations. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpptmA40zs0w.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
