* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Grant Likely @ 2010-12-16 17:06 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <4D0A446E.5020600@freescale.com>
On Thu, Dec 16, 2010 at 9:55 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>> This is for devices which don't have an i2c edid channel.
>
> So are we expecting board-specific code in U-Boot to add the data to the device
> tree?
No. It is a static property of the board/machine. It is expected it
to be encoded into the board's .dts file.
g.
^ permalink raw reply
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-12-16 17:07 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101214125427.GA2443@in.ibm.com>
"K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> How about the revised patch below? It is only compile-tested; have you
> got a quick test case that I can run?
It crashes the kernel when running the watch-vfork test.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Timur Tabi @ 2010-12-16 17:28 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <AANLkTinOf__X0p3_5G90KkYS9PXpB2j0_06MFhFcZzqO@mail.gmail.com>
Grant Likely wrote:
> No. It is a static property of the board/machine. It is expected it
> to be encoded into the board's .dts file.
Ok, but that only makes sense if the monitor is hard-wired to the board itself.
If a user can attach any monitor he wants, then the EDID data can't be known at
compile time.
I guess it's no different than using hard-coded memory controller programming
instead of SPD. You can safely avoid SPD only if the DDR chips are soldered on
the board.
It looks like I need to add board-specific EDID reading to the DIU driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Anatolij Gustschin @ 2010-12-16 17:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-fbdev, devicetree-discuss
In-Reply-To: <AANLkTin-TL5_TKnyHYtZdixosfqpkPNoarSTC+K4tTUb@mail.gmail.com>
On Thu, 16 Dec 2010 10:47:53 -0600
Timur Tabi <timur@freescale.com> wrote:
> On Fri, Jul 23, 2010 at 9:00 AM, Anatolij Gustschin <agust@denx.de> wrote:
> > Adds support for encoding display mode information
> > in the device tree using verbatim EDID block.
> >
> > If the EDID entry in the DIU node is present, the
> > driver will build mode database using EDID data
> > and allow setting the display modes from this database.
> > Otherwise display mode will be set using mode
> > entries from driver's internal database as usual.
> >
> > This patch also updates device tree bindings.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
> > Acked-by: Timur Tabi <timur@freescale.com>
> > Cc: devicetree-discuss@lists.ozlabs.org
>
> Anatolij,
>
> I know this patch is old, but I'm now getting back to working on the
> DIU driver. One question I have: why are you reading the EDID data
> from the device tree? Why not just read it directly from the device
> using I2C? Who is supposed to put the EDID data into the device tree
> in the first place?
Many embedded boards only hard-wire a panel which does not provide
an i2c edid channel. For such boards the EDID data can be inserted
by the bootloader or encoded in the board's .dts. Look at pdm360ng
U-Boot board code, it inserts the EDID data into device tree using
fdt_add_edid().
Anatolij
^ permalink raw reply
* Re: [PATCH v4 5/5] fsl-diu-fb: Support setting display mode using EDID
From: Grant Likely @ 2010-12-16 17:42 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, linux-fbdev, Anatolij Gustschin, devicetree-discuss
In-Reply-To: <4D0A4C38.3010105@freescale.com>
On Thu, Dec 16, 2010 at 10:28 AM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>> No. =A0It is a static property of the board/machine. =A0It is expected i=
t
>> to be encoded into the board's .dts file.
>
> Ok, but that only makes sense if the monitor is hard-wired to the board i=
tself.
> =A0If a user can attach any monitor he wants, then the EDID data can't be=
known at
> compile time.
>
> I guess it's no different than using hard-coded memory controller program=
ming
> instead of SPD. =A0You can safely avoid SPD only if the DDR chips are sol=
dered on
> the board.
Correct, if a real EDID i2c channel exists, then an edid property
should *not* be specified in the device tree.
g.
^ permalink raw reply
* [PATCH V2] powerpc/pseries: Fix VPHN build errors on non-SMP systems
From: Jesse Larrew @ 2010-12-18 8:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: markn, tbreeds, lkessler, Jesse Larrew, mjwolf
From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
The header asm/hvcall.h was previously included indirectly via
smp.h. On non-SMP systems, however, these declarations are excluded
and the build breaks. This is easily fixed by including asm/hvcall.h
directly.
The VPHN feature is only meaningful on NUMA systems that implement
the SPLPAR option, so exclude the VPHN code on systems without
SPLPAR enabled.
Also, expose unmap_cpu_from_node() on systems with SPLPAR enabled,
even if CONFIG_HOTPLUG_CPU is disabled.
Lastly, map_cpu_to_node() is now needed by VPHN to manipulate the
node masks after boot time, so remove the __cpuinit annotation to
fix a section mismatch.
Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/topology.h | 20 +++++++++++---------
arch/powerpc/mm/numa.c | 9 ++++++---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index aed188b..fbfcfd0 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -93,9 +93,20 @@ extern void __init dump_numa_cpu_topology(void);
extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
+#ifdef CONFIG_PPC_SPLPAR
extern int start_topology_update(void);
extern int stop_topology_update(void);
#else
+static inline int start_topology_update(void)
+{
+ return 0;
+}
+static inline int stop_topology_update(void)
+{
+ return 0;
+}
+#endif /* CONFIG_PPC_SPLPAR */
+#else
static inline void dump_numa_cpu_topology(void) {}
@@ -108,15 +119,6 @@ static inline void sysfs_remove_device_from_node(struct sys_device *dev,
int nid)
{
}
-
-static inline int start_topology_update(void)
-{
- return 0;
-}
-static inline int stop_topology_update(void)
-{
- return 0;
-}
#endif /* CONFIG_NUMA */
#include <asm-generic/topology.h>
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 42aa7d1..8f8845e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -28,6 +28,7 @@
#include <asm/smp.h>
#include <asm/firmware.h>
#include <asm/paca.h>
+#include <asm/hvcall.h>
static int numa_enabled = 1;
@@ -167,7 +168,7 @@ static void __init get_node_active_region(unsigned long start_pfn,
work_with_active_regions(nid, get_active_region_work_fn, node_ar);
}
-static void __cpuinit map_cpu_to_node(int cpu, int node)
+static void map_cpu_to_node(int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
@@ -177,7 +178,7 @@ static void __cpuinit map_cpu_to_node(int cpu, int node)
cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
}
-#ifdef CONFIG_HOTPLUG_CPU
+#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PPC_SPLPAR)
static void unmap_cpu_from_node(unsigned long cpu)
{
int node = numa_cpu_lookup_table[cpu];
@@ -191,7 +192,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
cpu, node);
}
}
-#endif /* CONFIG_HOTPLUG_CPU */
+#endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
/* must hold reference to node during call */
static const int *of_get_associativity(struct device_node *dev)
@@ -1263,6 +1264,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
#endif /* CONFIG_MEMORY_HOTPLUG */
/* Vrtual Processor Home Node (VPHN) support */
+#ifdef CONFIG_PPC_SPLPAR
#define VPHN_NR_CHANGE_CTRS (8)
static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
static cpumask_t cpu_associativity_changes_mask;
@@ -1505,3 +1507,4 @@ int stop_topology_update(void)
vphn_enabled = 0;
return del_timer_sync(&topology_timer);
}
+#endif /* CONFIG_PPC_SPLPAR */
--
1.7.2.3
^ permalink raw reply related
* Re: Oops in trace_hardirqs_on (powerpc)
From: Jörg Sommer @ 2010-12-19 13:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <1285639094.2989.1.camel@frodo>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
Hi Steven,
Steven Rostedt hat am Mon 27. Sep, 21:58 (-0400) geschrieben:
> On Mon, 2010-09-27 at 14:50 +0200, Jörg Sommer wrote:
> > Hello Steven,
> >
> > Steven Rostedt hat am Wed 22. Sep, 15:44 (-0400) geschrieben:
> > > Sorry for the late reply, but I was on vacation when you sent this, and
> > > I missed it while going through email.
> > >
> > > Do you still have this issue?
> >
> > No. I've rebuild my kernel without TRACE_IRQFLAGS and the problem
> > vanished, as expected. The problem is, that in some cases the stack is
> > only two frames deep, which causes the macro CALLER_ADDR1 makes an
> > invalid access. Someone told me, there a workaround for the problem on
> > i386, too.
> >
> > % sed -n 2p arch/x86/lib/thunk_32.S
> > * Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)
>
> Yes, I remember that problem. When I get back from Tokyo, I'll tried to
> remember to fix it.
Did you've fixed this problem? The bug report is still marked as open.
https://bugzilla.kernel.org/show_bug.cgi?id=16573
Regards, Jörg.
--
Begebenheit aus dem wahren Leben:
Mediziner: ICEs sind die weißen Züge.
Mathematiker: Das ist falsch. Jeder ICE ist zwar weiß, aber nicht alle
weißen Züge sind ICEs.
[-- Attachment #2: Digital signature http://en.wikipedia.org/wiki/OpenPGP --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] I2C: Add support for 64bit system.
From: Xulei @ 2010-12-20 7:37 UTC (permalink / raw)
To: linux-i2c; +Cc: linuxppc-dev, Xulei
Currently I2C_MPC supports 32bit system only, then this
modification makes it support 32bit and 64bit system both.
Signed-off-by: Xulei <B33228@freescale.com>
---
drivers/i2c/busses/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 9c6170c..3392f4b 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -422,7 +422,7 @@ config I2C_IXP2000
config I2C_MPC
tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
- depends on PPC32
+ depends on PPC32 || PPC64
help
If you say yes to this option, support will be included for the
built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] I2C: Add support for 64bit system.
From: Ben Dooks @ 2010-12-20 14:59 UTC (permalink / raw)
To: Xulei; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <1292830654-7056-1-git-send-email-B33228@freescale.com>
On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
> Currently I2C_MPC supports 32bit system only, then this
> modification makes it support 32bit and 64bit system both.
>
> Signed-off-by: Xulei <B33228@freescale.com>
This been build or run tested?
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 9c6170c..3392f4b 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -422,7 +422,7 @@ config I2C_IXP2000
>
> config I2C_MPC
> tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
> - depends on PPC32
> + depends on PPC32 || PPC64
> help
> If you say yes to this option, support will be included for the
> built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
> --
> 1.7.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* P2020 with BCM53115
From: Dry, Craig @ 2010-12-20 18:08 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
I am trying to bring up a P2020 board which uses the Broadcom BCM53115 switch in unmanaged mode. The board is patterned after the P2020RDB, except the Vitesse switch has been replaced with a BCM53115. There is no MDIO connection to the switch, but there is an SPI connection available if needed.
When running Uboot, the BCM53115 works just fine, as I am able to download the Linux Kernel and P2020RDB.dtb across the network without issue. But as Linux is booting up, I get the message:
mdio_bus mdio@ffe24520: error probing PHY at address 0
mdio_bus mdio@ffe24520: error probing PHY at address 1
I expect these errors occur because the P2020RDB.dts file has these entries.
I'm not sure what to try next to get Linux to use the BCM53115 switch in unmanaged mode.
Any help is appreciated,
Thanks,
Craig
This message is intended only for the designated recipient(s) and may contain confidential or proprietary information of Mercury Computer Systems, Inc. This message is solely intended to facilitate business discussions and does not constitute an express or implied offer to sell or purchase any products, services, or support. Any commitments must be made in writing and signed by duly authorized representatives of each party.
[-- Attachment #2: Type: text/html, Size: 6181 bytes --]
^ permalink raw reply
* Re: P2020 with BCM53115
From: Scott Wood @ 2010-12-20 18:49 UTC (permalink / raw)
To: Dry, Craig; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <690FFE9537DC4C47854ABD6C16FA141945A2AC3D5F@CHM-MBX1.ad.mc.com>
On Mon, 20 Dec 2010 13:08:55 -0500
"Dry, Craig" <cdry@mc.com> wrote:
> I am trying to bring up a P2020 board which uses the Broadcom BCM53115 switch in unmanaged mode. The board is patterned after the P2020RDB, except the Vitesse switch has been replaced with a BCM53115. There is no MDIO connection to the switch, but there is an SPI connection available if needed.
>
> When running Uboot, the BCM53115 works just fine, as I am able to download the Linux Kernel and P2020RDB.dtb across the network without issue. But as Linux is booting up, I get the message:
>
> mdio_bus mdio@ffe24520: error probing PHY at address 0
> mdio_bus mdio@ffe24520: error probing PHY at address 1
>
> I expect these errors occur because the P2020RDB.dts file has these entries.
>
> I'm not sure what to try next to get Linux to use the BCM53115 switch in unmanaged mode.
See the fixed-link property in
Documentation/powerpc/dts-bindings/fsl/tsec.txt
-Scott
^ permalink raw reply
* Re: Oops in trace_hardirqs_on (powerpc)
From: Steven Rostedt @ 2010-12-20 20:43 UTC (permalink / raw)
To: Jörg Sommer
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <20101219132705.GE6615@alea.gnuu.de>
On Sun, 2010-12-19 at 14:27 +0100, Jörg Sommer wrote:
> Hi Steven,
>
> Steven Rostedt hat am Mon 27. Sep, 21:58 (-0400) geschrieben:
> > On Mon, 2010-09-27 at 14:50 +0200, Jörg Sommer wrote:
> > > Hello Steven,
> > >
> > > Steven Rostedt hat am Wed 22. Sep, 15:44 (-0400) geschrieben:
> > > > Sorry for the late reply, but I was on vacation when you sent this, and
> > > > I missed it while going through email.
> > > >
> > > > Do you still have this issue?
> > >
> > > No. I've rebuild my kernel without TRACE_IRQFLAGS and the problem
> > > vanished, as expected. The problem is, that in some cases the stack is
> > > only two frames deep, which causes the macro CALLER_ADDR1 makes an
> > > invalid access. Someone told me, there a workaround for the problem on
> > > i386, too.
> > >
> > > % sed -n 2p arch/x86/lib/thunk_32.S
> > > * Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)
> >
> > Yes, I remember that problem. When I get back from Tokyo, I'll tried to
> > remember to fix it.
>
> Did you've fixed this problem? The bug report is still marked as open.
> https://bugzilla.kernel.org/show_bug.cgi?id=16573
>
Ah, this email got lost in the hundreds I had when I got back from
Tokyo, sorry about that again :-(
Anyway, it looks like this only affects 32 bit PPC as I can't reproduce
it with my 64 bit one. And also, unfortunately, my 32bit ppc got taken
from me by my kids, so I can't test it on that either.
I'll look to see if I can write up a patch. Perhaps you could test it
for me.
Thanks,
-- Steve
^ permalink raw reply
* Re: Oops in trace_hardirqs_on (powerpc)
From: Steven Rostedt @ 2010-12-20 21:12 UTC (permalink / raw)
To: Jörg Sommer
Cc: Frederic Weisbecker, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <1292877806.22905.62.camel@gandalf.stny.rr.com>
On Mon, 2010-12-20 at 15:43 -0500, Steven Rostedt wrote:
> Anyway, it looks like this only affects 32 bit PPC as I can't reproduce
> it with my 64 bit one. And also, unfortunately, my 32bit ppc got taken
> from me by my kids, so I can't test it on that either.
Spoke too soon, I just triggered it on 64bit.
I'll look into it. Thanks!
-- Steve
^ permalink raw reply
* [PATCH 1/2] eSPI: change the read behavior of the SPIRF
From: Mingkai Hu @ 2010-12-21 1:26 UTC (permalink / raw)
To: linuxppc-dev, spi-devel-general; +Cc: kumar.gala, Mingkai Hu
The user must read N bytes of SPIRF (1 <= N <= 4) that do not exceed the
amount of data in the receive FIFO, so read the SPIRF byte by byte when
the data in receive FIFO is less than 4 bytes.
On Simics, when read N bytes that exceed the amout of data in receive
FIFO, we can't read the data out, that is we can't clear the rx FIFO,
then the CPU will loop on the espi rx interrupt.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
The patch 2/2 is againsted on this patch, so I resent this patch again
for convience which sent several weeks ago.
drivers/spi/spi_fsl_espi.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
index e3b4f64..ae78926 100644
--- a/drivers/spi/spi_fsl_espi.c
+++ b/drivers/spi/spi_fsl_espi.c
@@ -507,16 +507,29 @@ void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)
/* We need handle RX first */
if (events & SPIE_NE) {
- u32 rx_data;
+ u32 rx_data, tmp;
+ u8 rx_data_8;
/* Spin until RX is done */
while (SPIE_RXCNT(events) < min(4, mspi->len)) {
cpu_relax();
events = mpc8xxx_spi_read_reg(®_base->event);
}
- mspi->len -= 4;
- rx_data = mpc8xxx_spi_read_reg(®_base->receive);
+ if (mspi->len >= 4) {
+ rx_data = mpc8xxx_spi_read_reg(®_base->receive);
+ } else {
+ tmp = mspi->len;
+ rx_data = 0;
+ while (tmp--) {
+ rx_data_8 = in_8((u8 *)®_base->receive);
+ rx_data |= (rx_data_8 << (tmp * 8));
+ }
+
+ rx_data <<= (4 - mspi->len) * 8;
+ }
+
+ mspi->len -= 4;
if (mspi->rx)
mspi->get_rx(rx_data, mspi);
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] eSPI: fix wrong setting of the address in the command buffer
From: Mingkai Hu @ 2010-12-21 1:27 UTC (permalink / raw)
To: linuxppc-dev, spi-devel-general; +Cc: kumar.gala, Mingkai Hu
Or else we cann't operate on the right address when the trans length
is greater than 65535.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
drivers/spi/spi_fsl_espi.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
index ae78926..a99e233 100644
--- a/drivers/spi/spi_fsl_espi.c
+++ b/drivers/spi/spi_fsl_espi.c
@@ -258,18 +258,18 @@ static int fsl_espi_bufs(struct spi_device *spi, struct spi_transfer *t)
return mpc8xxx_spi->count;
}
-static void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
+static inline void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
{
- if (cmd[1] && cmd[2] && cmd[3]) {
+ if (cmd) {
cmd[1] = (u8)(addr >> 16);
cmd[2] = (u8)(addr >> 8);
cmd[3] = (u8)(addr >> 0);
}
}
-static unsigned int fsl_espi_cmd2addr(u8 *cmd)
+static inline unsigned int fsl_espi_cmd2addr(u8 *cmd)
{
- if (cmd[1] && cmd[2] && cmd[3])
+ if (cmd)
return cmd[1] << 16 | cmd[2] << 8 | cmd[3] << 0;
return 0;
@@ -395,9 +395,11 @@ static void fsl_espi_rw_trans(struct spi_message *m,
}
}
- addr = fsl_espi_cmd2addr(local_buf);
- addr += pos;
- fsl_espi_addr2cmd(addr, local_buf);
+ if (pos > 0) {
+ addr = fsl_espi_cmd2addr(local_buf);
+ addr += pos;
+ fsl_espi_addr2cmd(addr, local_buf);
+ }
espi_trans->n_tx = n_tx;
espi_trans->n_rx = trans_len;
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] I2C: Add support for 64bit system.
From: xulei @ 2010-12-21 7:32 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20101220145954.GA1126@trinity.fluff.org>
yes, it has been built and could access the RTC well.
On =E4=B8=80, 2010-12-20 at 14:59 +0000, Ben Dooks wrote:
> On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote:
> > Currently I2C_MPC supports 32bit system only, then this
> > modification makes it support 32bit and 64bit system both.
> >=20
> > Signed-off-by: Xulei <B33228@freescale.com>
>=20
> This been build or run tested?
>=20
> > ---
> > drivers/i2c/busses/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >=20
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9c6170c..3392f4b 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -422,7 +422,7 @@ config I2C_IXP2000
> > =20
> > config I2C_MPC
> > tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
> > - depends on PPC32
> > + depends on PPC32 || PPC64
> > help
> > If you say yes to this option, support will be included for the
> > built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
> > --=20
> > 1.7.0.4
> >=20
> >=20
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-i2c" =
in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>=20
^ permalink raw reply
* Re: [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: Michal Marek @ 2010-12-21 14:19 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <abe67e5689fef1d94e57be68ec5ef47a8f13bf8e.1291820034.git.dirk.brandewie@gmail.com>
On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds linking device tree blob into vmlinux. DTB's are
> added by adding the blob object name to list of objects to be linked
> into the image.
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> arch/x86/platform/ce4100/Makefile | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
> index 91fc929..e5f3b7b 100644
> --- a/arch/x86/platform/ce4100/Makefile
> +++ b/arch/x86/platform/ce4100/Makefile
> @@ -1 +1,11 @@
> obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
> +clean-files := *dtb.S
> +
> +ifdef CONFIG_X86_OF
> +###
> +# device tree blob
> +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
> +
> +$(obj)/%.dtb: $(src)/%.dts
> + $(call cmd,dtc)
> +endif
Hi,
CONFIG_X86_OF should be defined in some Kconfig file and there is no
ce4100.dts??
Michal
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Michal Marek @ 2010-12-21 14:24 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <99ff131ecbee621f0d3178d6d3896d6f39207d6f.1291820034.git.dirk.brandewie@gmail.com>
On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
> +quiet_cmd_dt_S_dtb= DTB $@
> +quiet_cmd_dtc = DTC $@
Hi,
just an aesthetic remark: The target name should start at the 9th
column, so there should be 5 spaces after both "DTB" and "DTC".
Michal
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Dirk Brandewie @ 2010-12-21 17:52 UTC (permalink / raw)
To: Michal Marek
Cc: linux-arch, microblaze-uclinux, devicetree-discuss, linux-kernel,
sodaville, linuxppc-dev
In-Reply-To: <4D10B8AA.3070500@suse.cz>
On 12/21/2010 06:24 AM, Michal Marek wrote:
> On 8.12.2010 16:01, dirk.brandewie@gmail.com wrote:
>> +quiet_cmd_dt_S_dtb= DTB $@
>
>> +quiet_cmd_dtc = DTC $@
>
> Hi,
>
> just an aesthetic remark: The target name should start at the 9th
> column, so there should be 5 spaces after both "DTB" and "DTC".
>
> Michal
Thanks I will fix this.
--Dirk
^ permalink raw reply
* [PATCH RESEND 2] mpc52xx: gpt: include fs.h
From: Wolfram Sang @ 2010-12-22 15:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton
Fix build errors like these (from a randconfig and my defconfig for a custom board):
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs
...
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
rc7 is out and we still have this build-failure. Please apply.
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index fea833e..e0d703c 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -63,6 +63,7 @@
#include <linux/of_gpio.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/fs.h>
#include <linux/watchdog.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
--
1.7.2.3
^ permalink raw reply related
* [PATCH RESEND] pata_mpc52xx: driver needs BMDMA
From: Wolfram Sang @ 2010-12-22 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide, Andrew Morton, Jeff Garzik, linux-kernel
Found by this build-error if BMDMA is disabled:
drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
...
Move the Kconfig entry to the proper location as needed since
9a7780c9acb821fe1c2b6fc53f74cc2556ff5364 (libata-sff: make BMDMA optional)
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
This is a build-failure, so fixing it before 2.6.37 would be great.
drivers/ata/Kconfig | 20 ++++++++++----------
drivers/ata/Makefile | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
If unsure, say N.
-config PATA_MPC52xx
- tristate "Freescale MPC52xx SoC internal IDE"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_ATA
- help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
config PATA_OCTEON_CF
tristate "OCTEON Boot Bus Compact Flash support"
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx && PPC_BESTCOMM
+ select PPC_BESTCOMM_ATA
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index c501af5..2b67c90 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
-obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o
obj-$(CONFIG_SATA_QSTOR) += sata_qstor.o
obj-$(CONFIG_SATA_SX4) += sata_sx4.o
@@ -52,6 +51,7 @@ obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_MACIO) += pata_macio.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NINJA32) += pata_ninja32.o
obj-$(CONFIG_PATA_NS87415) += pata_ns87415.o
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Changes from V2:
Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
suggested implementation.
Rules in architecture specific Makefiles changed to use the cmd
function instead of the if_changed function.
Changes from V3:
Cosmetic fix of DTC quiet command
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 12 +++---------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
6 files changed, 65 insertions(+), 16 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..86e3cd0 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..05cbad0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..7df8eb5 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+quiet_cmd_dt_S_dtb= DTB $@
+cmd_dt_S_dtb= \
+( \
+ echo '\#include <asm-generic/vmlinux.lds.h>'; \
+ echo '.section .dtb.init.rodata,"a"'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+ echo '.global __dtb_$(*F)_begin'; \
+ echo '__dtb_$(*F)_begin:'; \
+ echo '.incbin "$<" '; \
+ echo '__dtb_$(*F)_end:'; \
+ echo '.global __dtb_$(*F)_end'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+) > $@
+
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ $(call cmd,dt_S_dtb)
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..e5f3b7b 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-22 19:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, linux-kbuild, microblaze-uclinux,
devicetree-discuss, dirk.brandewie, linuxppc-dev
In-Reply-To: <1293047849-26078-1-git-send-email-dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..96deec6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call cmd,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox