* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Michael Ellerman @ 2009-04-09 4:38 UTC (permalink / raw)
To: Kumar Gala
Cc: Tejun Heo, linux-ide, Timur Tabi, Jeff Garzik,
Linux PPC Development
In-Reply-To: <E7CD85E9-BB6E-4598-A734-8D0E67090789@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
> On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
>
> > On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
> >> On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo <tj@kernel.org> wrote:
> >>> Hmmm... for now,
> >>> I think it would be best to revert the original change. Jeff, can
> >>> you
> >>> please do that?
> >>
> >> Actually, give me a few days before you do that. A colleague gave me
> >> some suggestions to debug this.
> >
> > What device did you say it was? A "ULI M1575" ?
> >
> > Is that this one?
> >
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
> > hpcd_quirk_uli1575);
> >
> > static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
> > {
> > u32 temp32;
> >
> > if (!machine_is(mpc86xx_hpcd))
> > return;
> >
> > /* Disable INTx */
> > pci_read_config_dword(dev, 0x48, &temp32);
> > pci_write_config_dword(dev, 0x48, (temp32 | 1<<26));
> > ..
>
> It is the odd thing is the board he's running on is a mpc86xx_hpcd so
> he shouldn't be hitting the code that actually disables INTx.
Sorry Kumar that's not parsing :)
He is running an mpc86xx_hpcd, so he _should_ be hitting the code that
disables INTX?
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Kumar Gala @ 2009-04-09 4:23 UTC (permalink / raw)
To: michael
Cc: Tejun Heo, linux-ide, Timur Tabi, Jeff Garzik,
Linux PPC Development
In-Reply-To: <1239234793.6214.5.camel@localhost>
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
> On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
>> On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo <tj@kernel.org> wrote:
>>> Hmmm... for now,
>>> I think it would be best to revert the original change. Jeff, can
>>> you
>>> please do that?
>>
>> Actually, give me a few days before you do that. A colleague gave me
>> some suggestions to debug this.
>
> What device did you say it was? A "ULI M1575" ?
>
> Is that this one?
>
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
> hpcd_quirk_uli1575);
>
> static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
> {
> u32 temp32;
>
> if (!machine_is(mpc86xx_hpcd))
> return;
>
> /* Disable INTx */
> pci_read_config_dword(dev, 0x48, &temp32);
> pci_write_config_dword(dev, 0x48, (temp32 | 1<<26));
> ..
It is the odd thing is the board he's running on is a mpc86xx_hpcd so
he shouldn't be hitting the code that actually disables INTx.
- k
^ permalink raw reply
* Re: [PATCH] mpic_find() was overloaded to do two things introduce mpic_is_ipi() and simplify mpic_find()
From: Michael Ellerman @ 2009-04-09 3:00 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <8a6c1abce00c6f85d9714269d11bc3fac73a5402.1239164732.git.tony@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Wed, 2009-04-08 at 14:26 +1000, Tony Breeds wrote:
> Also silences the warning:
> arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
> arch/powerpc/sysdev/mpic.c:1382: warning: 'is_ipi' may be used uninitialized in this function
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> Only compile tested.
Not even compile tested, but looks good.
Acked-by: Michael Ellerman <michael@ellerman.id.au>
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: Stephen Rothwell @ 2009-04-09 1:51 UTC (permalink / raw)
To: John Linn
Cc: linux-fbdev-devel, adaplas, Suneel, linuxppc-dev, Suneel,
akonovalov
In-Reply-To: <20090408211521.D0EF411B8054@mail214-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Hi John,
On Wed, 8 Apr 2009 15:11:25 -0600 John Linn <john.linn@xilinx.com> wrote:
>
> * 2002-2007 (c) MontaVista Software, Inc.
> * 2007 (c) Secret Lab Technologies, Ltd.
> + * 2009 (c) Xilinx Inc.
> *
> - * This file is licensed under the terms of the GNU General Public License
> - * version 2. This program is licensed "as is" without any warranty of any
> - * kind, whether express or implied.
> + * This program is free software; you can redistribute it
> + * and/or modify it under the terms of the GNU General Public
> + * License as published by the Free Software Foundation;
> + * either version 2 of the License, or (at your option) any
> + * later version.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; if not, write to the Free
> + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
> + * 02139, USA.
This changes the license for this file (from "GPLv2" to "GPLv2 or
later"). Have you asked the other copyright owners about that?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
From: Tony Breeds @ 2009-04-09 0:01 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20090408134736.682bd56d@manatee.lan>
On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote:
> I think I had some reason for doing it this way, but I'm drawing a
> blank right now.
>
> In the meantime, can someone post the warnings that gcc emits for
> cacheinfo.c, as well as the gcc version? I can't reproduce them with
> 4.3.2 on Fedora.
---
[tony@thor ~]$ egrep cacheinfo tmp/build.log
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'associativity_show':
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562: warning: 'associativity' may be used uninitialized in this function
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'size_show':
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:513: warning: 'size_kb' may be used uninitialized in this function
tony@Sprygo:~/scratch$ /opt/crosstool/gcc-4.4.0-20090216-nolibc/powerpc-linux/bin/powerpc-linux-gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/crosstool/gcc-4.4.0-20090216-nolibc/powerpc-linux --program-prefix=powerpc-linux- --disable-bootstrap --with-mpfr=/usr --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release
Thread model: single
gcc version 4.4.0 20090216 (experimental) (GCC)
tony@Sprygo:~/scratch$
---
That's the compiler in rawhide
Yours Tony
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Michael Ellerman @ 2009-04-08 23:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: Tejun Heo, linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <ed82fe3e0904081515k6e53de00g7d5256f9b61a03da@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
> On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo <tj@kernel.org> wrote:
> > Hmmm... for now,
> > I think it would be best to revert the original change. Jeff, can you
> > please do that?
>
> Actually, give me a few days before you do that. A colleague gave me
> some suggestions to debug this.
What device did you say it was? A "ULI M1575" ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, &temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 1<<26));
..
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Timur Tabi @ 2009-04-08 22:15 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <49DD17C3.7040607@kernel.org>
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo <tj@kernel.org> wrote:
> Hmmm... for now,
> I think it would be best to revert the original change. =A0Jeff, can you
> please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: tracking of PCI address space
From: Ira Snyder @ 2009-04-08 21:49 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-pci, Benjamin Herrenschmidt, Linux Kernel Mailing List,
Jesse Barnes, Linux/PPC Development
In-Reply-To: <E942C580-7C39-44AB-B207-C65CDE0B5292@kernel.crashing.org>
On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
> I was wondering if we have anything that tracks regions associated with
> the "inbound" side of a pci_bus.
>
> What I mean is on embedded PPC we have window/mapping registers for both
> inbound (accessing memory on the SoC) and outbound (access PCI device
> MMIO, IO etc). The combination of the inbound & outbound convey what
> exists in the PCI address space vs CPU physical address space (and how to
> map from one to the other). Today in the PPC land we only attach
> outbound windows to the pci_bus. So technically the inbound side
> information (like what subset of physical memory is visible on the PCI
> bus) seems to be lost.
>
To the best of my knowledge there is no API to set inbound windows in
Linux. I've been implementing a virtio-over-PCI driver which needs the
inbound windows. I set them up myself during driver probe, using
get_immrbase() to get the IMMR registers. This board is a PCI Slave /
Agent, it doesn't even have PCI support compiled into the kernel.
Ira
^ permalink raw reply
* Xilinx board and NPTL support lockup
From: khollan @ 2009-04-08 22:04 UTC (permalink / raw)
To: linuxppc-dev
Hi everyone,
I have a board similar to the ml410, its been running a linux kernel happily
for about a year now, but now the firmware guys want NPTL threading instead
of the linuxthread library.
I recompiled my gcc 4.0.2 and glibc 2.3.6 library with the NPTL support, and
recompiled my kernel with the new tools.
Now my kernel gets stuck at the infamous "Now Booting the Kernel" message.
Any thoughts on why this might be happening, or how to verify that my glibc
and gcc are functional other than trying to compile things with them (I know
this works).
Thanks
Kevin
--
View this message in context: http://www.nabble.com/Xilinx-board-and-NPTL-support-lockup-tp22960621p22960621.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: tracking of PCI address space
From: Kumar Gala @ 2009-04-08 21:53 UTC (permalink / raw)
To: Ira Snyder
Cc: linux-pci, Benjamin Herrenschmidt, Linux Kernel Mailing List,
Jesse Barnes, Linux/PPC Development
In-Reply-To: <20090408214932.GA31970@ovro.caltech.edu>
On Apr 8, 2009, at 4:49 PM, Ira Snyder wrote:
> On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
>> I was wondering if we have anything that tracks regions associated
>> with
>> the "inbound" side of a pci_bus.
>>
>> What I mean is on embedded PPC we have window/mapping registers for
>> both
>> inbound (accessing memory on the SoC) and outbound (access PCI device
>> MMIO, IO etc). The combination of the inbound & outbound convey what
>> exists in the PCI address space vs CPU physical address space (and
>> how to
>> map from one to the other). Today in the PPC land we only attach
>> outbound windows to the pci_bus. So technically the inbound side
>> information (like what subset of physical memory is visible on the
>> PCI
>> bus) seems to be lost.
>>
>
> To the best of my knowledge there is no API to set inbound windows in
> Linux. I've been implementing a virtio-over-PCI driver which needs the
> inbound windows. I set them up myself during driver probe, using
> get_immrbase() to get the IMMR registers. This board is a PCI Slave /
> Agent, it doesn't even have PCI support compiled into the kernel.
I'm not concerned explicitly about setting up inbound windows, its
more about have a consistent view of the PCI address space which may
be different from the CPU physical address space.
I'm working on code to actually setup the inbound windows on 85xx/86xx
class devices (based on dma-ranges property in the device tree). As I
was thinking about this I realized that the send of ranges/dma-ranges
in the .dts and what we map to outbound vs inbound changes if we an
agent or host.
- k
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Tejun Heo @ 2009-04-08 21:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <49DD1465.6070001@freescale.com>
Timur Tabi wrote:
> Tejun Heo wrote:
>
>> Yeah, right. The following patch should do the trick then.
>
> Thanks, I appreciate it. I get this output:
>
> XXX PCI_COMMAND=0x407
^
Yeah, that's INTX disable. Strange that the controller has the bit
set on boot. I'm curious where this is from, the controller reset,
firmware or the PCI init (in decreasing likelihood). Hmmm... for now,
I think it would be best to revert the original change. Jeff, can you
please do that?
Thanks.
--
tejun
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Timur Tabi @ 2009-04-08 21:17 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <49DD1375.8030400@kernel.org>
Tejun Heo wrote:
> Yeah, right. The following patch should do the trick then.
Thanks, I appreciate it. I get this output:
XXX PCI_COMMAND=0x407
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: John Linn @ 2009-04-08 21:11 UTC (permalink / raw)
To: grant.likely, jwboyer, linuxppc-dev, linux-fbdev-devel,
akonovalov, adaplas
Cc: Suneel, Suneel, John Linn
From: Suneel <[mailto:suneel.garapati@xilinx.com]>
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel <suneelg@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/video/xilinxfb.c | 227 ++++++++++++++++++++++++++++++++--------------
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* source@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * This program is free software; you can redistribute it
+ * and/or modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
/*
@@ -31,27 +38,31 @@
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/dma-mapping.h>
-#if defined(CONFIG_OF)
#include <linux/of_device.h>
#include <linux/of_platform.h>
-#endif
-#include <asm/io.h>
+#include <linux/io.h>
#include <linux/xilinxfb.h>
#include <asm/dcr.h>
#define DRIVER_NAME "xilinxfb"
-#define DRIVER_DESCRIPTION "Xilinx TFT LCD frame buffer driver"
+
/*
* Xilinx calls it "PLB TFT LCD Controller" though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned int dcr_start;
unsigned int dcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys; /* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u32 dcr_splb_slave_if;
+ /* True, if control interface is
+ connected through plb */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata->dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata->dcr_splb_slave_if == 1)
+ out_be32(drvdata->regs + (offset << 2), val);
+ else
+ dcr_write(drvdata->dcr_host, offset, val);
+
+}
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
@@ -175,7 +200,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
switch (blank_mode) {
case FB_BLANK_UNBLANK:
/* turn on panel */
- xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata->reg_ctrl_default);
break;
case FB_BLANK_NORMAL:
@@ -191,8 +217,7 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
return 0; /* success */
}
-static struct fb_ops xilinxfb_ops =
-{
+static struct fb_ops xilinxfb_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = xilinx_fb_setcolreg,
.fb_blank = xilinx_fb_blank,
@@ -205,25 +230,35 @@ static struct fb_ops xilinxfb_ops =
* Bus independent setup/teardown
*/
-static int xilinxfb_assign(struct device *dev, dcr_host_t dcr_host,
- unsigned int dcr_start, unsigned int dcr_len,
+static int xilinxfb_assign(struct device *dev,
+ struct xilinxfb_drvdata *drvdata,
+ unsigned long physaddr,
struct xilinxfb_platform_data *pdata)
{
- struct xilinxfb_drvdata *drvdata;
int rc;
int fbsize = pdata->xvirt * pdata->yvirt * BYTES_PER_PIXEL;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(dev, "Couldn't allocate device private record\n");
- return -ENOMEM;
+ if (drvdata->dcr_splb_slave_if) {
+ /*
+ * Map the control registers in if the controller
+ * is on direct PLB interface.
+ */
+ if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
+ dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+ physaddr);
+ rc = -ENODEV;
+ goto err_region;
+ }
+
+ drvdata->regs_phys = physaddr;
+ drvdata->regs = ioremap(physaddr, 8);
+ if (!drvdata->regs) {
+ dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+ physaddr);
+ rc = -ENODEV;
+ goto err_map;
+ }
}
- dev_set_drvdata(dev, drvdata);
-
- drvdata->dcr_start = dcr_start;
- drvdata->dcr_len = dcr_len;
- drvdata->dcr_host = dcr_host;
/* Allocate the framebuffer memory */
if (pdata->fb_phys) {
@@ -238,7 +273,10 @@ static int xilinxfb_assign(struct device *dev, dcr_host_t dcr_host,
if (!drvdata->fb_virt) {
dev_err(dev, "Could not allocate frame buffer memory\n");
rc = -ENOMEM;
- goto err_region;
+ if (drvdata->dcr_splb_slave_if)
+ goto err_fbmem;
+ else
+ goto err_region;
}
/* Clear (turn to black) the framebuffer */
@@ -251,7 +289,8 @@ static int xilinxfb_assign(struct device *dev, dcr_host_t dcr_host,
drvdata->reg_ctrl_default = REG_CTRL_ENABLE;
if (pdata->rotate_screen)
drvdata->reg_ctrl_default |= REG_CTRL_ROTATE;
- xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata->reg_ctrl_default);
/* Fill struct fb_info */
drvdata->info.device = dev;
@@ -287,9 +326,14 @@ static int xilinxfb_assign(struct device *dev, dcr_host_t dcr_host,
goto err_regfb;
}
+ if (drvdata->dcr_splb_slave_if) {
+ /* Put a banner in the log (for DEBUG) */
+ dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr,
+ drvdata->regs);
+ }
/* Put a banner in the log (for DEBUG) */
dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
- (void*)drvdata->fb_phys, drvdata->fb_virt, fbsize);
+ (void *)drvdata->fb_phys, drvdata->fb_virt, fbsize);
return 0; /* success */
@@ -300,9 +344,20 @@ err_cmap:
if (drvdata->fb_alloced)
dma_free_coherent(dev, PAGE_ALIGN(fbsize), drvdata->fb_virt,
drvdata->fb_phys);
+ else
+ iounmap(drvdata->fb_virt);
+
/* Turn off the display */
xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+err_fbmem:
+ if (drvdata->dcr_splb_slave_if)
+ iounmap(drvdata->regs);
+
+err_map:
+ if (drvdata->dcr_splb_slave_if)
+ release_mem_region(physaddr, 8);
+
err_region:
kfree(drvdata);
dev_set_drvdata(dev, NULL);
@@ -325,11 +380,18 @@ static int xilinxfb_release(struct device *dev)
if (drvdata->fb_alloced)
dma_free_coherent(dev, PAGE_ALIGN(drvdata->info.fix.smem_len),
drvdata->fb_virt, drvdata->fb_phys);
+ else
+ iounmap(drvdata->fb_virt);
/* Turn off the display */
xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
- dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
+ /* Release the resources, as allocated based on interface */
+ if (drvdata->dcr_splb_slave_if) {
+ iounmap(drvdata->regs);
+ release_mem_region(drvdata->regs_phys, 8);
+ } else
+ dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
kfree(drvdata);
dev_set_drvdata(dev, NULL);
@@ -341,27 +403,54 @@ static int xilinxfb_release(struct device *dev)
* OF bus binding
*/
-#if defined(CONFIG_OF)
static int __devinit
xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
{
const u32 *prop;
+ u32 *p;
+ u32 tft_access;
struct xilinxfb_platform_data pdata;
+ struct resource res;
int size, rc;
- int start, len;
+ int start = 0, len = 0;
dcr_host_t dcr_host;
+ struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
pdata = xilinx_fb_default_pdata;
dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
- start = dcr_resource_start(op->node, 0);
- len = dcr_resource_len(op->node, 0);
- dcr_host = dcr_map(op->node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(&op->dev, "invalid address\n");
- return -ENODEV;
+ /*
+ * To check whether the core is connected directly to DCR or PLB
+ * interface and initialize the tft_access accordingly.
+ */
+ p = (u32 *)of_get_property(op->node, "xlnx,dcr-splb-slave-if", NULL);
+
+ if (p)
+ tft_access = *p;
+ else
+ tft_access = 0; /* For backward compatibility */
+
+ /*
+ * Fill the resource structure if its direct PLB interface
+ * otherwise fill the dcr_host structure.
+ */
+ if (tft_access) {
+ rc = of_address_to_resource(op->node, 0, &res);
+ if (rc) {
+ dev_err(&op->dev, "invalid address\n");
+ return -ENODEV;
+ }
+
+ } else {
+ start = dcr_resource_start(op->node, 0);
+ len = dcr_resource_len(op->node, 0);
+ dcr_host = dcr_map(op->node, start, len);
+ if (!DCR_MAP_OK(dcr_host)) {
+ dev_err(&op->dev, "invalid address\n");
+ return -ENODEV;
+ }
}
prop = of_get_property(op->node, "phys-size", &size);
@@ -385,7 +474,26 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
if (of_find_property(op->node, "rotate-display", NULL))
pdata.rotate_screen = 1;
- return xilinxfb_assign(&op->dev, dcr_host, start, len, &pdata);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(&op->dev, "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+ dev_set_drvdata(&op->dev, drvdata);
+
+ /* Store the tft_access value into the driverdata structure member */
+ drvdata->dcr_splb_slave_if = tft_access;
+
+ /* Arguments are passed based on the interface */
+ if (drvdata->dcr_splb_slave_if == 1) {
+ return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
+ } else {
+ drvdata->dcr_start = start;
+ drvdata->dcr_len = len;
+ drvdata->dcr_host = dcr_host;
+ return xilinxfb_assign(&op->dev, drvdata, 0, &pdata);
+ }
}
static int __devexit xilinxfb_of_remove(struct of_device *op)
@@ -395,6 +503,7 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
/* Match table for of_platform binding */
static struct of_device_id xilinxfb_of_match[] __devinitdata = {
+ { .compatible = "xlnx,xps-tft-1.00.a", },
{ .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
{ .compatible = "xlnx,plb-dvi-cntlr-ref-1.00.c", },
{},
@@ -412,22 +521,6 @@ static struct of_platform_driver xilinxfb_of_driver = {
},
};
-/* Registration helpers to keep the number of #ifdefs to a minimum */
-static inline int __init xilinxfb_of_register(void)
-{
- pr_debug("xilinxfb: calling of_register_platform_driver()\n");
- return of_register_platform_driver(&xilinxfb_of_driver);
-}
-
-static inline void __exit xilinxfb_of_unregister(void)
-{
- of_unregister_platform_driver(&xilinxfb_of_driver);
-}
-#else /* CONFIG_OF */
-/* CONFIG_OF not enabled; do nothing helpers */
-static inline int __init xilinxfb_of_register(void) { return 0; }
-static inline void __exit xilinxfb_of_unregister(void) { }
-#endif /* CONFIG_OF */
/* ---------------------------------------------------------------------
* Module setup and teardown
@@ -436,18 +529,18 @@ static inline void __exit xilinxfb_of_unregister(void) { }
static int __init
xilinxfb_init(void)
{
- return xilinxfb_of_register();
+ return of_register_platform_driver(&xilinxfb_of_driver);
}
static void __exit
xilinxfb_cleanup(void)
{
- xilinxfb_of_unregister();
+ of_unregister_platform_driver(&xilinxfb_of_driver);
}
module_init(xilinxfb_init);
module_exit(xilinxfb_cleanup);
-MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
-MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_AUTHOR("Xilinx Inc.");
+MODULE_DESCRIPTION("Xilinx TFT frame buffer driver");
MODULE_LICENSE("GPL");
--
1.6.2.1
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.
^ permalink raw reply related
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Tejun Heo @ 2009-04-08 21:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <49DD11D1.7060105@freescale.com>
Timur Tabi wrote:
> Tejun Heo wrote:
>
>> Running "lspci -nnvvvxxx" before loading the driver should be enough.
>
> That might be difficult. My root file system is on my SATA drive.
> It'll be a while before I can build an NFS rootfs.
>
Yeah, right. The following patch should do the trick then.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 788bba2..b3f4df7 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -2606,6 +2606,12 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!printed_version++)
dev_printk(KERN_DEBUG, &pdev->dev, "version " DRV_VERSION "\n");
+ {
+ u16 cmd;
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ printk("XXX PCI_COMMAND=0x%x\n", cmd);
+ }
+
/* The AHCI driver can only drive the SATA ports, the PATA driver
can drive them all so if both drivers are selected make sure
AHCI stays out of the way */
--
tejun
^ permalink raw reply related
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Timur Tabi @ 2009-04-08 21:06 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <49DD1154.3040106@kernel.org>
Tejun Heo wrote:
> Running "lspci -nnvvvxxx" before loading the driver should be enough.
That might be difficult. My root file system is on my SATA drive.
It'll be a while before I can build an NFS rootfs.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Tejun Heo @ 2009-04-08 21:04 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <ed82fe3e0904080440w130b5dc5of6d5ed3051ed04e2@mail.gmail.com>
Timur Tabi wrote:
> On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman <michael@ellerman.id.au> wrote:
>
>> Have you confirmed that INTX is disabled before that call?
>
> How do I do that?
Running "lspci -nnvvvxxx" before loading the driver should be enough.
--
tejun
^ permalink raw reply
* tracking of PCI address space
From: Kumar Gala @ 2009-04-08 20:53 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-pci, Benjamin Herrenschmidt, Linux Kernel Mailing List,
Linux/PPC Development
I was wondering if we have anything that tracks regions associated
with the "inbound" side of a pci_bus.
What I mean is on embedded PPC we have window/mapping registers for
both inbound (accessing memory on the SoC) and outbound (access PCI
device MMIO, IO etc). The combination of the inbound & outbound
convey what exists in the PCI address space vs CPU physical address
space (and how to map from one to the other). Today in the PPC land
we only attach outbound windows to the pci_bus. So technically the
inbound side information (like what subset of physical memory is
visible on the PCI bus) seems to be lost.
- k
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-08 20:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: Benjamin, linuxppc-dev, alsa-devel, Takashi Iwai
In-Reply-To: <1239205899.16477.32.camel@johannes.local>
Hi Johannes,
Thanks for the fast answer.
On Wed, 08 Apr 2009 17:51:39 +0200, Johannes Berg wrote:
> > Basically the idea is to move the I2C device instantiation from the
> > codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.)
> > This follows the Linux device driver model, requires slightly less
> > code, runs faster and and lets the required chip drivers be loaded by
> > udev or similar automatically.
>
> Sounds weird -- how do you handle codecs that could be on different
> buses? This seems to imply that any probing may potentially need to be
> duplicated across any bus driver they could possibly connected to. But
> that's not really relevant to this patch.
Yes, "probing" would be duplicated if we had to support more than one
bus. But as far as I can see, the onyx and tas devices can only be
found on i2c-powermac buses, so this shouldn't be an issue. And there
isn't really any probing going on, it's really only a matter of walking
a small subset of the device tree (the children of the I2C bus) and
instantiating I2C devices.
Out of curiosity, are there systems with more than one system I2C buses
(supported by i2c-powermac)?
If there were a significant amount of duplicated code, it could
certainly be addressed one way or another, but it wasn't my top
priority, and actually didn't seem that necessary. As a matter of fact,
my patch removes (slightly) more code than it adds.
> > The last driver to convert, keywest, is a mystery to me. I have a hard
> > time understanding how it interacts with tumbler and daca. I have the
> > feeling that it is essentially a glue module to workaround the legacy
> > i2c model limitations, so probably it could go away entirely now, but
> > I'm not sure how to do that in practice. Maybe tumbler and daca would
> > be made separate i2c drivers, I'm not sure.
>
> Sorry, I'm not familiar with this code.
>
> > One thing in particular which I find strange is that tumbler has
> > references to the TAS3004 device, much like the tas codec driver. It is
> > unclear to me whether tas is a replacement for tumbler, or if both
> > drivers work together, or if they are for separate hardware. I would
> > appreciate clarifications about this.
>
> Well... tumbler also drives the very similar tas3001 codec.
>
> However, I need to start with a little more background.
>
> Apple machines can contain various codecs, for example the tas3004,
> which has various outputs. Due to the way Apple wires up the codec, you
> need platform fabric to identify which outputs are connected where, cf.
> sound/aoa/fabrics/layout.c. Note all machines have line-in for instance.
>
> The aoa driver, which I wrote, currently supports only i2s buses for
> actually transferring data, but I think there are some other ways to get
> data to the codec -- I'm not too familiar with the old machines.
>
> Now, aoa will currently automatically load from the layout fabric
> module, and then pull in the modules for the codecs it _knows_ to be
> present on the bus. Therefore, it seems that your patch makes things
> less efficient because you probe for all those codecs, and there's no
> machine that has all of them. The aoa fabric only loads the modules for
> those it knows to be present, and they then probe (and in reality the
> probing never fails because they really are there).
Can you please point me to the layout fabric / aoa fabric? I'd like to
understand how it works. Then I may be able to rewrite my patch
completely differently.
There are basically two ways to instantiate I2C devices in the new
model. The first method is to declare the I2C devices as platform data
and let i2c-core instantiate them. The second method is to have the i2c
bus driver instantiate the clients. My patch uses the second method
because I didn't know how to use the first method. However using the
first method would solve the issues you raised. But I need some help
from someone more familiar with the powermac platform initialization
code to get it right.
> Now, since aoa needs information on how the entire system is glued
> together (the fabric I was talking about with the line-in example), it
> has to infer that from platform data, in this case the device tree.
> Because I do not have any older machines, am lazy and snd-powermac works
> for the old machines, snd-powermac with its "tumbler" is a driver for
> the same tas3004 codec, but on a different, older, fabric.
I think I've found that one by now (snd_pmac_detect in
sound/ppc/pmac.c, right?), thanks for the clarification.
BTW, that code doesn't seem significantly different from what my patch
is adding to i2c-powermac.
> Once upon a time the plan was to get rid of snd-powermac entirely and
> port all its functionality into subdrivers of aoa, but that clearly
> never happened. No fairy-tale happy ending here, quite obviously.
>
> Now, looking at your patch, I think it will break snd-powermac. See, if
> snd_aoa_codec_tas is automatically loaded on a system with an _old_
> fabric that aoa knows nothing about, snd-powermac can no longer be
> loaded. (Incidentally, snd-powermac cannot be auto-loaded at all
> currently, while aoa can via the fabric driver's device-tree binding)
Hmm, OK, I expected the code I moved from the aoa drivers to
i2c-powermac to only match the subset of machines actually supported by
aoa. If that's not the case then indeed it is incorrect.
> Therefore, probing the codecs in i2c-powermac and automatically loading
> the corresponding aoa module will break sound on old machines.
Does this mean that manually loading snd_aoa_codec_tas today on an old
system with a TAS would break sound too?
> I would think that if you removed the MODULE_DEVICE_TABLE from your
> patch, it may continue to work because the aoa fabric driver loads the
> modules as before, and on old machines nothing loads automatically and
> snd-powermac can be loaded manually.
>
> However, it will still be less efficient because you will be probing
> _all_ those codecs, notably the tas family, even on machines that are
> known to not have it (machines that have onyx). Putting that mutual
> exclusion information into i2c-powermac would be misplaced, imho.
>
> Note also that there's one more codec (topaz) which isn't currently
> supported.
>
> In conclusion, I think that the old/existing/legacy i2c binding model
> was much better suited to platform knowledge about the way machines are
> put together, and the new code is, as far as I can tell, less efficient
> -- contrary to your assertion.
My comment about efficiency was related to the fact that the sound chip
detection code would run only on the i2c-power mac bus, rather than all
I2C buses on the system. Admittedly I had missed the larger picture of
all detections running on all powermac systems, which wasn't the case
so far.
Anyway, the key point of my patch is to get rid of the legacy i2c
binding model, not efficiency.
> Since I'm away from all machines I could test this with I have no data
> on any that or the module device table thing I pointed out for now.
>
> Anyway, some more technical comments on your patch:
> * I realise you just copied things around but it would be nice to clean
> up the coding style, especially comment style, a little while at it.
> (yeah, it's my fault)
I can fix anything you like, just tell me what :)
> * aoa_codec_* is the module name, I see no reason to use that as the
> i2c name, that should be the codec's name instead (aka pcm3052 etc)
The names are totally arbitrary and we can change them if you like.
Keep in mind though that we should avoid using mere chip names for
non-generic drivers. The aoa drivers are powermac-specific, we don't
want the names we pick to collide with another driver, that's why I
chose to keep the aoa prefix.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-08 19:55 UTC (permalink / raw)
To: Kumar Gala
Cc: Linux/PPC Development, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <E9E24C93-F147-49F0-9FBE-FCE4883D11BF@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>
>>> So I'm a bit concerned with the output we now get:
>>>
>>> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
>>>
>>> why 0? is that right?
>>
>> This is the backward compatibility mode using hard-coded FDR values. The
>> output is missleading, I agree.
>>
>> Wolfgang.
>
> Can the output be fixed. 0 Hz seemed bad to me.
Of course. No info message will be printed for the legacy case
like it was with the old driver version. I just realized a bug in the
MPC52xx part. Will send patches tomorrow, after some more thorough testing.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
From: Wolfgang Grandegger @ 2009-04-08 18:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <C3323B74-40FE-41BC-A49C-C94D7DB3FF5A@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 8, 2009, at 1:27 PM, Wolfgang Grandegger wrote:
>
>> Grant Likely wrote:
>>> On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger
>>> <wg@grandegger.com> wrote:
>>>> Grant Likely wrote:
>>>>> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger
>>>>> <wg@grandegger.com> wrote:
>>>>>> Preserve I2C clock settings for the Socrates MPC8544 board.
>>>>> I had thought that the preserve-clocking property was intended for
>>>>> older boards that don't currently have any method of getting the clock
>>>>> setting out of u-boot. Since Socrates is a new board, U-Boot should
>>>>> probably be made to fill in the real clock rate setting.
>>>> I'm not sure if I understand what you mean. If an old version of U-Boot
>>>> on an old board sets the I2C clock, it can be used (inherited) by Linux
>>>> using the property "preserve-clocking".
>>>>
>>>> It is actually the customers choice to set the I2C clock in U-Boot and
>>>> re-use it by Linux.
>>>
>>> Setting it in the register != recording the value in the device tree.
>>> I'm saying that since Socrates is a new board it should not use the
>>> preserve-clocking dirty trick (and it is a dirty trick) because the
>>> correct clocking data can be passed via the device tree.
>>
>> Why should an old board then use it. "fsl, preserve-clocking" is a new
>> feature, like using "clock-frequency" and you have the choice to
>> explicitly set the clocking via device tree or inherit it from the boot
>> loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the
>> registers by Linux.
>
> I think Grant's point is socrates is a new board with a new u-boot.
> That u-boot should be able to set the clock-frequency property in i2c.
> One assumes if you a clock-frequency property you wouldn't use
> "fsl,preserve-clocking". (However -- its feasible they are mutually
> exclusive).
OK, now it makes more sense to me even if I never thought that way. My
intention was to allow Linux to use a *different* frequency as the
bootloader by specifying the "clock-frequency" property. This would not
be possible with a fixup by the bootloader.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
From: Nathan Lynch @ 2009-04-08 18:47 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1239173283.10104.38.camel@localhost>
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
> > On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
> >
> > > The getter routines in here could really multiplex their return values
> > > with a negative error code, which I generally prefer, but this works I
> > > guess.
> >
> > I was hoping someone would notice and suggest it. tag you're it!
>
> I meant we /could/ change them, but we could also leave them, it's a bit
> of a coin-flip which is better. Nathan might have an opinion?
I think I had some reason for doing it this way, but I'm drawing a
blank right now.
In the meantime, can someone post the warnings that gcc emits for
cacheinfo.c, as well as the gcc version? I can't reproduce them with
4.3.2 on Fedora.
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
From: Kumar Gala @ 2009-04-08 18:43 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <49DCEC80.2050507@grandegger.com>
On Apr 8, 2009, at 1:27 PM, Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger <wg@grandegger.com
>> > wrote:
>>> Grant Likely wrote:
>>>> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger <wg@grandegger.com
>>>> > wrote:
>>>>> Preserve I2C clock settings for the Socrates MPC8544 board.
>>>> I had thought that the preserve-clocking property was intended for
>>>> older boards that don't currently have any method of getting the
>>>> clock
>>>> setting out of u-boot. Since Socrates is a new board, U-Boot
>>>> should
>>>> probably be made to fill in the real clock rate setting.
>>> I'm not sure if I understand what you mean. If an old version of U-
>>> Boot
>>> on an old board sets the I2C clock, it can be used (inherited) by
>>> Linux
>>> using the property "preserve-clocking".
>>>
>>> It is actually the customers choice to set the I2C clock in U-Boot
>>> and
>>> re-use it by Linux.
>>
>> Setting it in the register != recording the value in the device tree.
>> I'm saying that since Socrates is a new board it should not use the
>> preserve-clocking dirty trick (and it is a dirty trick) because the
>> correct clocking data can be passed via the device tree.
>
> Why should an old board then use it. "fsl, preserve-clocking" is a new
> feature, like using "clock-frequency" and you have the choice to
> explicitly set the clocking via device tree or inherit it from the
> boot
> loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the
> registers by Linux.
I think Grant's point is socrates is a new board with a new u-boot.
That u-boot should be able to set the clock-frequency property in
i2c. One assumes if you a clock-frequency property you wouldn't use
"fsl,preserve-clocking". (However -- its feasible they are mutually
exclusive).
- k
^ permalink raw reply
* Re: AMCC 440EP phy detection
From: Eddie Dawydiuk @ 2009-04-08 18:35 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200904082019.06889.sr@denx.de>
Stefan,
> Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is
> using a custom bootloader.
Correct, I'll put this code in the platform initialization. Thanks for the
suggestions everyone.
> Eddie, btw: Why are you not using U-Boot?
At Technologic Systems, one of our design goals for all of our products is to
achieve a very quick boot time(under 2 seconds to a shell prompt). We then
provide a user space utility to boot another linux kernel, this allows our
customers to use Linux as a bootloader. We boot to an initial ramdisk then use a
linuxrc script as a replacement for a typical bootloader(e.g. U-Boot). In the
background we can then mount a large filesystem with Debian installed. In my
opinion it works out quite nicely in that one can use our boards as more of an
appliance(apply power and it's on, rather than waiting for a computer to boot).
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
From: Wolfgang Grandegger @ 2009-04-08 18:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <fa686aa40904080753p2b282338r9ba463c47f897fb@mail.gmail.com>
Grant Likely wrote:
> On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Grant Likely wrote:
>>> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>>> Preserve I2C clock settings for the Socrates MPC8544 board.
>>> I had thought that the preserve-clocking property was intended for
>>> older boards that don't currently have any method of getting the clock
>>> setting out of u-boot. Since Socrates is a new board, U-Boot should
>>> probably be made to fill in the real clock rate setting.
>> I'm not sure if I understand what you mean. If an old version of U-Boot
>> on an old board sets the I2C clock, it can be used (inherited) by Linux
>> using the property "preserve-clocking".
>>
>> It is actually the customers choice to set the I2C clock in U-Boot and
>> re-use it by Linux.
>
> Setting it in the register != recording the value in the device tree.
> I'm saying that since Socrates is a new board it should not use the
> preserve-clocking dirty trick (and it is a dirty trick) because the
> correct clocking data can be passed via the device tree.
Why should an old board then use it. "fsl, preserve-clocking" is a new
feature, like using "clock-frequency" and you have the choice to
explicitly set the clocking via device tree or inherit it from the boot
loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the
registers by Linux.
Wolfgang.
^ permalink raw reply
* Re: AMCC 440EP phy detection
From: Stefan Roese @ 2009-04-08 18:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eddie Dawydiuk
In-Reply-To: <fa686aa40904081000x2dbdd417y149fe442b9fc55bf@mail.gmail.com>
On Wednesday 08 April 2009, Grant Likely wrote:
> >> I would like to eventually submit our changes for upstream support.
> >> Based on this would you recommend ensuring tx enable is configured
> >> properly in the initialization of the ibm_newemac driver or the platform
> >> initialization?
> >
> > This GPIO multiplexing configuration does not belong into the ibm_newemac
> > driver since it is very platform/board specific. The platform code is
> > definitely a better place.
>
> Even better is the platform specific boot code (firmware or equivalent)
Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is
using a custom bootloader.
Eddie, btw: Why are you not using U-Boot?
Best regards,
Stefan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox